Re: [bitcoin-dev] Rolling UTXO set hashes

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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

>On Mon, May 15, 2017 at 11:04 PM, ZmnSCPxj via bitcoin-dev
><bitcoin-dev@lists.linuxfoundation.org> 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

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