From: Paul Rabahy <prabahy@gmail•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Chain pruning
Date: Thu, 10 Apr 2014 14:19:05 -0400 [thread overview]
Message-ID: <CADu7o8PD4Wkgx_X_aOHXHe8UA-OE9v5YZ4boMrX7LDVu6agfpQ@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBg88Q1Ddwsvuk3-17wO=0DF7L1wtxx4mWUoiV1=cWKhEQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3876 bytes --]
You say UTXO commitments is "a strict reduction in security". If UTXO
commitments were rolled in as a soft fork, I do not see any new attacks
that could happen to a person trusting the committed UTXO + any remaining
blocks to catch up to the head.
I would imagine the soft fork to proceed similar to the following.
1. Miners begin including UTXO commitments.
2. Miners begin rejecting blocks with invalid UTXO commitments.
3. Miners begin rejecting blocks with no UTXO commitments.
To start up a fresh client it would follow the following.
1. Sync headers.
2. Pick a committed UTXO that is deep enough to not get orphaned.
3. Sync blocks from commitment to head.
I would argue that a client following this methodology is strictly more
secure than SPV, and I don't see any attacks that make it less secure than
a full client. It is obviously still susceptible to a 51% attack, but so is
the traditional block chain. I also do not see any sybil attacks that are
strengthened by this change because it is not modifying the networking code.
I guess if the soft fork happened, then miners began to not include the
UTXO commitment anymore, it would lower the overall network hash rate, but
this would be self-harming to the miners so they have an incentive to not
do it.
Please let me know if I have missed something.
On Thu, Apr 10, 2014 at 12:59 PM, Pieter Wuille <pieter.wuille@gmail•com>wrote:
>
> As this is a suggestion that I think I've seen come up once a month
> for the past 3 years, let's try to answer it thoroughly.
>
> The actual "state" of the blockchain is the UTXO set (stored in
> chainstate/ by the reference client). It's the set of all unspent
> transaction outputs at the currently active point in the block chain.
> It is all you need for validating future blocks.
>
> The problem is, you can't just give someone the UTXO set and expect
> them to trust it, as there is no way to prove that it was the result
> of processing the actual blocks.
>
> As Bitcoin's full node uses a "zero trust" model, where (apart from
> one detail: the order of otherwise valid transactions) it never
> assumes any data received from the outside it valid, it HAS to see the
> previous blocks in order to establish the validity of the current UTXO
> set. This is what initial block syncing does. Nothing but the actual
> blocks can provide this data, and it is why the actual blocks need to
> be available. It does not require everyone to have all blocks, though
> - they just need to have seen them during processing.
>
> A related, but not identical evolution is merkle UTXO commitments.
> This means that we shape the UTXO set as a merkle tree, compute its
> root after every block, and require that the block commits to this
> root hash (by putting it in the coinbase, for example). This means a
> full node can copy the chain state from someone else, and check that
> its hash matches what the block chain commits to. It's important to
> note that this is a strict reduction in security: we're now trusting
> that the longest chain (with most proof of work) commits to a valid
> UTXO set (at some point in the past).
>
> In essence, combining both ideas means you get "superblocks" (the UTXO
> set is essentially the summary of the result of all past blocks), in a
> way that is less-than-currently-but-perhaps-still-acceptably-validated.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 4975 bytes --]
next prev parent reply other threads:[~2014-04-10 18:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 11:37 Mike Hearn
2014-04-10 11:57 ` Wladimir
2014-04-10 12:10 ` Gregory Maxwell
2014-04-10 14:19 ` Wladimir
2014-04-10 16:23 ` Brian Hoffman
2014-04-10 16:28 ` Mike Hearn
2014-04-10 16:47 ` Brian Hoffman
2014-04-10 16:54 ` Ricardo Filipe
2014-04-10 16:56 ` Brian Hoffman
2014-04-10 16:59 ` Pieter Wuille
2014-04-10 17:06 ` Brian Hoffman
2014-04-10 18:19 ` Paul Rabahy [this message]
2014-04-10 18:32 ` Pieter Wuille
2014-04-10 20:12 ` Tier Nolan
2014-04-10 20:29 ` Pieter Wuille
2014-04-10 19:36 ` Mark Friedenbach
2014-04-10 21:34 ` Jesus Cea
2014-04-10 22:15 ` Mark Friedenbach
2014-04-10 22:24 ` Jesus Cea
2014-04-10 22:33 ` Gregory Maxwell
2014-04-10 16:52 ` Ricardo Filipe
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=CADu7o8PD4Wkgx_X_aOHXHe8UA-OE9v5YZ4boMrX7LDVu6agfpQ@mail.gmail.com \
--to=prabahy@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/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