From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Gregory Maxwell <greg@xiph•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Rolling UTXO set hashes
Date: Mon, 15 May 2017 20:15:58 -0400 [thread overview]
Message-ID: <w4I6vriYS1XX4wAqk9LxneKCxEyPs4qy7Yhp8RaLazGNdgtkphKx8b95jZmaWL-NVnvdzBjgtwNiEm-0EosBuJ0tjND5lYkpmag_wREAFfs=@protonmail.com> (raw)
In-Reply-To: <CAAS2fgTif+Y6VzFG+w7W+CY1+D_roCqGyy392qB2KcDPGpVeiw@mail.gmail.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 --]
next prev parent reply other threads:[~2017-05-16 0:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-15 20:01 Pieter Wuille
2017-05-15 20:53 ` Peter R
2017-05-15 23:04 ` ZmnSCPxj
2017-05-15 23:59 ` Gregory Maxwell
2017-05-16 0:15 ` ZmnSCPxj [this message]
2017-05-16 11:01 ` Peter Todd
2017-05-16 18:17 ` Pieter Wuille
2017-05-16 18:20 ` Gregory Maxwell
2017-05-23 4:47 ` Rusty Russell
2017-05-23 20:43 ` Pieter Wuille
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='w4I6vriYS1XX4wAqk9LxneKCxEyPs4qy7Yhp8RaLazGNdgtkphKx8b95jZmaWL-NVnvdzBjgtwNiEm-0EosBuJ0tjND5lYkpmag_wREAFfs=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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