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.wui...@gmail.comwrote:
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
--
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
