Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

From: "Jorge Timón" <jtimon@jtimon•cc>
To: "Rune Kjær Svendsen" <runesvend@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hash of UTXO set as consensus-critical
Date: Fri, 18 Sep 2015 22:38:06 +0200	[thread overview]
Message-ID: <CABm2gDp-=Z0UHQ=7BnC8P_XJ3XCpU4n_L6kx6tfVovRmsGjFaw@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDrQm8-vQi6YBx9xh4GanJi-ZfiJpSW8nghvGeoLsuDVsw@mail.gmail.com>

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

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
>>
>

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