Jorge TimĂłn [ARCHIVE] on Nostr: đź“… Original date posted:2015-09-18 đź“ť Original message:Well, with utxo ...
đź“… Original date posted:2015-09-18
đź“ť Original message: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 at 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 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
>
> _______________________________________________
> 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/a57078f8/attachment-0001.html>;
đź“ť Original message: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 at 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 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
>
> _______________________________________________
> 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/a57078f8/attachment-0001.html>;