From: Peter Todd <pete@petertodd•org>
To: Mark Friedenbach <mark@monetize•io>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees
Date: Fri, 20 Dec 2013 08:17:31 -0500 [thread overview]
Message-ID: <20131220131731.GC21148@savin> (raw)
In-Reply-To: <52B42842.6000306@monetize.io>
[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]
On Fri, Dec 20, 2013 at 03:21:38AM -0800, Mark Friedenbach wrote:
> Hi Jeremy, Let's give a preview of the application-oriented BIPs I
> mentioned:
>
> Stateless validation and mining involves prefixing transaction and
> block messages with proofs of their UTxO state changes. These are the
> "operational proofs" I describe in the draft, and they work on prefix
> trees whose root hashes committed to the coinbase in a soft-fork
> upgrade of the validation rules.
>
> "Ultimate blockchain compression" involves consensus over an address
> index, which can be queried over the p2p network by lightweight nodes.
> The structure of the index is an authenticated prefix tree, and the
> results of such a query is an an inclusion proof.
I've thought about this for awhile and come to the conclusion that UTXO
commitments are a really bad idea. I myself wanted to see them
implemented about a year ago for fidelity bonded banks, but I've changed
my mind and I hope you do too.
They force miners and every full node with SPV clients to store the
entire UTXO set in perpetuity. This is bad by itself, but then they make
it even worse by making Bitcoin really useful and convenient to use as a
decentralized database; UTXO commitments make it easy and convenient to
implement systems like Namecoin on top of Bitcoin, yet we don't have the
UTXO expiration that might make such uses reasonable. Right now the UTXO
set is reasonable small - ~300MB - but that can and will change if we
make it an attractive way to store data. UTXO commitments do exactly
that.
You're also *not* giving users what they actually want: the transactions
associated with their wallets. Even though Electrum could easily work
via a pure UTXO database they implemented transaction lookup instead;
Electrum servers cough up every transaction associated with a user's
wallet. If you're going to do that, it's just as easy to do per-block
lookup trees which don't force the UTXO set to be stored.
There's also a more subtle issue: the security model of UTXO commitments
sucks. It encourages wallets to essentially trust single confirmations
because it's unlikely that nodes will want to store the multiple copies
of the UTXO set required to provide proof of multiple confirmations.
Basically the issue is when you start your wallet you get a proof of
UTXO set for the most recent block; that's just one confirmation. To get
more confirmations you have to wait for subsequent blocks, checking the
set on each block. Per block indexes on the other hand naturally lead
wallets to count confirmations properly.
IMO you should take this technology to Namecoin instead. For them the
fast lookups are probably worth the trade-offs, and they expire domains
so the total set size doesn't grow unbounded.
--
'peter'[:-1]@petertodd.org
00000000000000028fd077fb1e33e942e3e875aa29cec134fed89d650242c577
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 681 bytes --]
next prev parent reply other threads:[~2013-12-20 13:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-20 1:47 Mark Friedenbach
2013-12-20 6:48 ` Jeremy Spilman
2013-12-20 11:21 ` Mark Friedenbach
2013-12-20 13:17 ` Peter Todd [this message]
2013-12-20 18:41 ` Mark Friedenbach
2013-12-20 10:48 ` Peter Todd
[not found] ` <52B425BA.6060304@monetize.io>
2013-12-20 12:47 ` Peter Todd
2013-12-20 19:48 ` Gregory Maxwell
2013-12-20 22:04 ` Mark Friedenbach
2014-01-05 18:43 ` Thomas Voegtlin
2014-01-06 18:13 ` Peter Todd
2014-01-07 0:21 ` Mark Friedenbach
2014-01-07 6:31 ` Thomas Voegtlin
2014-01-08 1:04 ` Mark Friedenbach
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=20131220131731.GC21148@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mark@monetize$(echo .)io \
/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