📅 Original date posted:2015-09-18
📝 Original message:I guess I always assumed that UTXO set commitments were an alternative
security model (between SPV and full-node), not that they would cause the
existing security model to be deprecated.
On Fri, Sep 18, 2015 at 3:43 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Full nodes using UTXO set commitments is a change to the bitcoin
> security model.
>
> Currently an attacker with >50% of the network hashrate can rewrite
> history.
>
> If full nodes rely on UTXO set commitments such an attacker could create
> an infinite number of bitcoins (as in many times more than the current
> 21 million bitcoin limit).
>
> Before we consider mechanisms for UTXO set commitments, we should
> seriously discuss whether the security model reduction is reasonable.
>
> On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
> > Currently, when a new node wants to join the network, it needs to
> retrieve the entire blockchain history, starting from January 2009 and up
> until now, in order to derive a UTXO set that it can verify new
> blocks/transactions against. With a blockchain size of 40GB and a UTXO size
> of around 1GB, the extra bandwidth required is significant, and will keep
> increasing indefinitely. If a newly mined block were to include the UTXO
> set hash of the chain up until the previous block — the hash of the UTXO
> set on top of which this block builds — then new nodes, who want to know
> whether a transaction is valid, would be able to acquire the UTXO set in a
> trustless manner, by only verifying proof-of-work headers, and knowing that
> a block with an invalid UTXO set hash would be rejected.
> >
> > I’m not talking about calculating a complicated tree structure from the
> UTXO set, which would put further burden on already burdened Bitcoin Core
> nodes. We simply include the hash of the current UTXO set in a newly
> created block, such that the transactions in the new block build *on top*
> of the UTXO set whose hash is specified. This actually alleviates Bitcoin
> Core nodes, as it will now become possible for nodes without the entire
> blockchain to answer SPV queries (by retrieving the UTXO set trustlessly
> and using this to answer queries). It also saves bandwidth for Bitcore Core
> nodes, who only need to send roughly 1GB of data, in order to synchronise a
> node, rather than 40GB+. I will continue to run a full Bitcoin Core node,
> saving the entire blockchain history, but it shouldn’t be a requirement to
> hold the entire transaction history in order to start verifying new
> transactions.
> >
> > As far as I can see, this also forces miners to actually maintain an
> UTXO set, rather than just build on top of the chain with the most
> proof-of-work. Producing a UTXO set and verifying a block against a chain
> is the same thing, so by including the hash of the UTXO set we force miners
> to verify the block that they want to build on top of.
> >
> > Am I missing something obvious, because as far as I can see, this solves
> the problem of quadratic time complexity for initial sync:
> http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s
> >
> > The only added step to verifying a block is to hash the UTXO set. So it
> does require additional computation, but most modern CPUs have a SHA256
> throughput of around 500 MB/s, which means it takes only two seconds to
> hash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s).
> A small sacrifice for the added ease of initial syncing, in my opinion.
> >
> > /Rune
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/b0e1a5b4/attachment-0001.html>;
Alex Morcos [ARCHIVE] /
npub10z…3xfzw
2023-06-07 17:40:55
in reply to nevent1q…r6kc
Author Public Key
npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzwSeen on
wss://relay.nostr.bandPublished at
2023-06-07 17:40:55Event JSON
{
"id": "82bbd52294eb2428017640f44cbd5dd618ef9cbf5db0e56d2b5a489d8a647c45",
"pubkey": "78aa6925095b629d95a9e79aed6ed9da0973239bc6eedf11af42240f0e1d755c",
"created_at": 1686159655,
"kind": 1,
"tags": [
[
"e",
"7fadb5378c1c44e78cc5de59daa2e951bce7b919506a3d6cff2bcf05fa79c75d",
"",
"root"
],
[
"e",
"b5d16f9175d8932bfb09aeab16c99d26222dfbe94b8231c0e89c6ac6c5eded5d",
"",
"reply"
],
[
"p",
"fc7892eea47289e31dc49660ebe7f00108707eb2ee3b59909accdf0afaa4eb61"
]
],
"content": "📅 Original date posted:2015-09-18\n📝 Original message:I guess I always assumed that UTXO set commitments were an alternative\nsecurity model (between SPV and full-node), not that they would cause the\nexisting security model to be deprecated.\n\n\nOn Fri, Sep 18, 2015 at 3:43 PM, Patrick Strateman via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Full nodes using UTXO set commitments is a change to the bitcoin\n\u003e security model.\n\u003e\n\u003e Currently an attacker with \u003e50% of the network hashrate can rewrite\n\u003e history.\n\u003e\n\u003e If full nodes rely on UTXO set commitments such an attacker could create\n\u003e an infinite number of bitcoins (as in many times more than the current\n\u003e 21 million bitcoin limit).\n\u003e\n\u003e Before we consider mechanisms for UTXO set commitments, we should\n\u003e seriously discuss whether the security model reduction is reasonable.\n\u003e\n\u003e On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:\n\u003e \u003e Currently, when a new node wants to join the network, it needs to\n\u003e retrieve the entire blockchain history, starting from January 2009 and up\n\u003e until now, in order to derive a UTXO set that it can verify new\n\u003e blocks/transactions against. With a blockchain size of 40GB and a UTXO size\n\u003e of around 1GB, the extra bandwidth required is significant, and will keep\n\u003e increasing indefinitely. If a newly mined block were to include the UTXO\n\u003e set hash of the chain up until the previous block — the hash of the UTXO\n\u003e set on top of which this block builds — then new nodes, who want to know\n\u003e whether a transaction is valid, would be able to acquire the UTXO set in a\n\u003e trustless manner, by only verifying proof-of-work headers, and knowing that\n\u003e a block with an invalid UTXO set hash would be rejected.\n\u003e \u003e\n\u003e \u003e I’m not talking about calculating a complicated tree structure from the\n\u003e UTXO set, which would put further burden on already burdened Bitcoin Core\n\u003e nodes. We simply include the hash of the current UTXO set in a newly\n\u003e created block, such that the transactions in the new block build *on top*\n\u003e of the UTXO set whose hash is specified. This actually alleviates Bitcoin\n\u003e Core nodes, as it will now become possible for nodes without the entire\n\u003e blockchain to answer SPV queries (by retrieving the UTXO set trustlessly\n\u003e and using this to answer queries). It also saves bandwidth for Bitcore Core\n\u003e nodes, who only need to send roughly 1GB of data, in order to synchronise a\n\u003e node, rather than 40GB+. I will continue to run a full Bitcoin Core node,\n\u003e saving the entire blockchain history, but it shouldn’t be a requirement to\n\u003e hold the entire transaction history in order to start verifying new\n\u003e transactions.\n\u003e \u003e\n\u003e \u003e As far as I can see, this also forces miners to actually maintain an\n\u003e UTXO set, rather than just build on top of the chain with the most\n\u003e proof-of-work. Producing a UTXO set and verifying a block against a chain\n\u003e is the same thing, so by including the hash of the UTXO set we force miners\n\u003e to verify the block that they want to build on top of.\n\u003e \u003e\n\u003e \u003e Am I missing something obvious, because as far as I can see, this solves\n\u003e the problem of quadratic time complexity for initial sync:\n\u003e http://www.youtube.com/watch?v=TgjrS-BPWDQ\u0026t=2h02m12s\n\u003e \u003e\n\u003e \u003e The only added step to verifying a block is to hash the UTXO set. So it\n\u003e does require additional computation, but most modern CPUs have a SHA256\n\u003e throughput of around 500 MB/s, which means it takes only two seconds to\n\u003e hash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s).\n\u003e A small sacrifice for the added ease of initial syncing, in my opinion.\n\u003e \u003e\n\u003e \u003e /Rune\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/b0e1a5b4/attachment-0001.html\u003e",
"sig": "d44326de9c4535654b8507619119e0ad00a9737f9bba156d13f6de9fcbca5c3ffeb74ddf5df3f272af8252619cb26f75d7339c8de99b1c45bbbcb4f8f43e0ced"
}