Re: [bitcoin-dev] Rolling UTXO set hashes
On Mon, May 15, 2017 at 11:59:58PM +, Gregory Maxwell via bitcoin-dev wrote: > On Mon, May 15, 2017 at 11:04 PM, ZmnSCPxj via bitcoin-dev > wrote: > > transactions is in the header, which would let lite nodes download a UTXO > > set from any full node and verify it by verifying only block headers > > starting from genesis. > > Ya, lite nodes with UTXO sets are one of the the oldest observed > advantages of a commitment to the UTXO data: > > https://bitcointalk.org/index.php?topic=21995.0 > > But it requires a commitment. And for most of the arguments for those > you really want compact membership proofs. The recent rise in > interest in full block lite clients (for privacy reasons), perhaps > complements the membership proofless usage. > > Pieter describes some uses for doing something like this without a > commitment. In my view, it's more interesting to first gain > experience with an operation without committing to it (which is a > consensus change and requires more care and consideration, which are > easier if people have implementation experience). To be clear, *none* of the previous (U)TXO commitment schemes require *miners* to participate in generating a commitment. While that was previously thought to be true by many, I've seen no counter-arguments to the argument I published I few months ago(1) that (U)TXO commitments did not require a soft-fork to deploy. 1) "[bitcoin-dev] TXO commitments do not need a soft-fork to be useful", Peter Todd, Feb 23 2017, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] TXO commitments do not need a soft-fork to be useful
> Something I've recently realised is that TXO commitments do not need to be > implemented as a consensus protocol change to be useful. You're slow, Peter. I figured this out back in 2013: https://bitcointalk.org/index.php?topic=153662.10 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] TXO commitments do not need a soft-fork to be useful
On Tue, May 16, 2017 at 03:15:17PM +0300, Alex Mizrahi via bitcoin-dev wrote: > > Something I've recently realised is that TXO commitments do not need to be > > implemented as a consensus protocol change to be useful. > > > You're slow, Peter. I figured this out back in 2013: > > https://bitcointalk.org/index.php?topic=153662.10 Lol, good job! And you even figured out that lovely "distributed file system" explanation first. Though, it does look like I'm still the person who made it 100% *clear* the first time - you're explanation is easy to read the wrong way, particularly when you say: "Next time I will teach you how to implement a blockchain-based cryptocurrency in such a way that new miners can start mining right away without downloading whole blockchain, stay tuned..." After all, at the time UTXO commitments had been already discussed. Also, talking about a DHT in relation to this stuff probably made the explanation get missed by some people. Unfortunately, I think this is a good example of how important coming up with good explanations and analogies is. :/ -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Rolling UTXO set hashes
On Tue, May 16, 2017 at 4:01 AM, Peter Todd via bitcoin-dev wrote: > To be clear, *none* of the previous (U)TXO commitment schemes require *miners* > to participate in generating a commitment. While that was previously thought > to > be true by many, I've seen no counter-arguments to the argument I published I > few months ago(1) that (U)TXO commitments did not require a soft-fork to > deploy. > > 1) "[bitcoin-dev] TXO commitments do not need a soft-fork to be useful", >Peter Todd, Feb 23 2017, > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html I'm aware, I agree, and I even referenced that mail in my original post. However, all of those approaches still require a network wide choice to be useful. A validating node that does not maintain a UTXO X must get a proof of its unspentness from somewhere for at least the block which contains a spend of X. In a world where such a model is deployed network-wide, that proof information is generated by the wallet and relayed wherever needed. In a partial deployment however, you need nodes that can produce the proof for other nodes, and the ability to produce a proof is significantly more expensive than running either an old or a new full node. This ability to produce proofs becomes even harder when there are different models deployed at once. Even just having a different criterion for which UTXOs need a proof (eg. "only outputs created more than 1000 blocks ago") may already cause compatibility issues. Combine that with the multitude of ideas about this (insertion-ordered TXO trees, txid-ordered UTXO Patricia tries, AVL+ trees, append-only bitfield, ...) with different trade-offs (in CPU, RAM for validators, complexity for wallets/index services, ...), I don't think we're quite ready to make that choice. To be clear: I'm very much in favor of moving to a model where the responsibilities of full nodes are reduced in the long term. But before that can happen there will need to be implementations, experiments, analysis, ... Because of that, I think it is worthwhile to investigate solutions to the "how can we efficiently compare UTXO sets" problem separately from the "how do we reduce full node costs by sending proofs instead of it maintaining the data". And rolling UTXO set hashes are a solution for just the first - and one that has very low costs and no normative datastructures at all. -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Rolling UTXO set hashes
>On Mon, May 15, 2017 at 11:04 PM, ZmnSCPxj via bitcoin-dev > wrote: >> transactions is in the header, which would let lite nodes download a UTXO >> set from any full node and verify it by verifying only block headers >> starting from genesis. > >Ya, lite nodes with UTXO sets are one of the the oldest observed >advantages of a commitment to the UTXO data: > >https://bitcointalk.org/index.php?topic=21995.0 > >But it requires a commitment. And for most of the arguments for those >you really want compact membership proofs. The recent rise in >interest in full block lite clients (for privacy reasons), perhaps >complements the membership proofless usage. > >Pieter describes some uses for doing something like this without a >commitment. In my view, it's more interesting to first gain >experience with an operation without committing to it (which is a >consensus change and requires more care and consideration, which are >easier if people have implementation experience). I understand. Thank you for your explanation. >> rather than merkle tree root of transactions is in the header, > >For audibility and engineering reasons it would need to be be in >addition to rather than rather than, because the proof of work needs >to commit to the witness data (in that kind of flip, the transactions >themselves become witnesses for UTXO deltas) or you get trivial DOS >attacks where people provide malleated blocks that have invalid >witnesses. Another thought I have, is that instead of committing to the UTXO of the block, to commit to the UTXO of the previous block, and the merkle tree root of the transactions in the current block. My thought is that this would help reduce SPV mining, as a miner would need to actually scan any received new blocks in order to create the UTXO set of the previous block. An empty block would make things easier for the next block's miner, not the current block's miner. However, I'm not sure if my understanding is correct, or if there is some subtlety I missed in this regard. Regards, ZmnSCPxj___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Rolling UTXO set hashes
On Tue, May 16, 2017 at 6:17 PM, Pieter Wuille wrote: > just the first - and one that has very low costs and no normative > datastructures at all. The serialization of the txout itself is normative, but very minimal. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
