public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Vincent Truong <vincent.truong@procabiak.com>
To: "Jorge Timón" <jtimon@jtimon.cc>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Hash of UTXO set as consensus-critical
Date: Sat, 19 Sep 2015 08:22:35 +1000	[thread overview]
Message-ID: <CACrzPemS5x4pXBjsXJJU2Te9a=t7fOZmepV41Boy73pod_6PmQ@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDp-=Z0UHQ=7BnC8P_XJ3XCpU4n_L6kx6tfVovRmsGjFaw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 9009 bytes --]

This way lets us protect from 51% overwrites for a whole year:

1. Hash utxo set as is today, H1, and store it in a block.
2. At the same time, store a copy of the utxo set for H1 on disk, D1
3. After 1 year, create D2, then wait for H2 (if a fork happens then
recreate D2 and see which wins)
4. The block with H2 must hash on top of H1
4. Blocks before H1 can be safely pruned by the network, only keeping D1
for reference/validation, plus blocks the node wants to keep (data/colored
coins)
5. After 1 year, repeat for H3.
7. D1 can also be dropped after a few days once D3 is up, since the H1
securing D1 would have been pruned with H3's usage of D2 by then.

This reduces the security model from 'always secure' to 'secure, as of last
year'. An attacker will need to have hidden hashing power to overwrite a
years worth of blocks. Which I think would be hard enough.

The attacker can also try to undo a freshly built Hn, but because we can
build Dn first and wait for Hn, the nodes should be expecting the same
hash. They also serve as automated checkpoints to prevent them from
overwriting all of it.
On Sep 19, 2015 6:38 AM, "Jorge Timón" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> s/move the genesis block forward/move your genesis checkpoint forward/
> On Sep 18, 2015 4:37 PM, "Jorge Timón" <jtimon@jtimon.cc> wrote:
>
>> Well, with utxo commitments at some point maybe is enough to validate the
>> full headers history but only the last 5 years of ttansaction history
>> (assuming utxo commitments are buried 5 years worth of blocks in the past).
>> This scales much better than validating the full history and if we get a 5
>> year reorg something is going really wrong anyway...
>> Maybe after validating the last 5 years you also want to validate the
>> rest of the history backards to get the "fully-full node" security.
>> Of course 5 years it's just an arbitrary number: 2 or maybe even 1 would
>> probably be secure enough for most people. I've referred to this idea as
>> "hard checkpoints" or "moving the genesis block forward" in the past.
>> On Sep 18, 2015 4:18 PM, "Rune Kjær Svendsen" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> There are a couple of points I’d like to address.
>>>
>>> Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not
>>> function if the majority of mining power is dishonest. There is no way
>>> around that. It’s how proof-of-work functions. And if we lose
>>> proof-of-work, we lose Bitcoin.
>>>
>>> Secondly, I’m not suggesting that UTXO set hashes *replace* block
>>> hashes, or even that it should be in the block header (probably in the
>>> coinbase somewhere). I suggest it as an *addition* to the existing
>>> consensus rules. Full nodes can still verify the chain with the added step
>>> of hashing the UTXO set for every block. Of course, this can easily be
>>> deferred to after proof-of-work has been verified already, such that no
>>> work is wasted. Unless a 51% attack is in effect. But I argue that this is
>>> a moot point, since Bitcoin is useless anyway under such circumstances.
>>>
>>> Lastly, I’m not suggesting miners discard the blockchain history. A
>>> miner has an incentive to be absolutely sure that the chain he’s building
>>> on is the right one. If he’s wrong, he loses money/income. There’s simply
>>> no reason for a professional miner *not* to do the full initial sync, which
>>> only needs to be done once. Non-miners, who just want to check the balance
>>> of their wallet, however, really don’t need to retrieve information about
>>> Hal Finney sending bitcoins to Satoshi in 2010. In any case, this practice
>>> isn’t sustainable.
>>>
>>> In the end, it isn’t possible to control whether a miner verifies the
>>> entire blockchain anyway (anyone can send the UTXO set over the wire). Not
>>> letting the proof-of-work cover the UTXO hash doesn’t solve this problem,
>>> it only makes it impossible to know whether a given UTXO set is the one
>>> that the majority is mining on without retrieving the entire blockchain,
>>> and doing the verification yourself. People can choose to skip that
>>> regardless of what we do.
>>>
>>> Furthermore, all nodes have the option of deciding which level of
>>> security they want. We’re not lessening security of the protocol, we’re
>>> strengthening the security of something that’s already possible to do
>>> (build on top of an unverified blockchain), but we’d rather want that
>>> people not do.
>>>
>>> /Rune
>>>
>>>
>>> > On 18 Sep 2015, at 21:43, Patrick Strateman via bitcoin-dev <
>>> bitcoin-dev@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@lists.linuxfoundation.org
>>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 10593 bytes --]

  reply	other threads:[~2015-09-18 22:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-18 19:05 [bitcoin-dev] Hash of UTXO set as consensus-critical Rune Kjær Svendsen
2015-09-18 19:43 ` Patrick Strateman
2015-09-18 20:07   ` Alex Morcos
2015-09-18 20:11     ` Matt Corallo
2015-09-18 20:17   ` Rune Kjær Svendsen
2015-09-18 20:37     ` Jorge Timón
2015-09-18 20:38       ` Jorge Timón
2015-09-18 22:22         ` Vincent Truong [this message]
2015-09-19  2:30     ` Justus Ranvier
2015-09-19 15:45       ` Rune Kjær Svendsen
2015-09-19 17:19         ` Justus Ranvier
2015-09-19 20:11           ` Rune K. Svendsen
2015-09-20  0:48             ` Dave Scotese
2015-09-21 17:15             ` Justus Ranvier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACrzPemS5x4pXBjsXJJU2Te9a=t7fOZmepV41Boy73pod_6PmQ@mail.gmail.com' \
    --to=vincent.truong@procabiak.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jtimon@jtimon.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox