From: Peter Todd <pete@petertodd•org>
To: Alan Reiner <etotheipi@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite nodes
Date: Sun, 17 Jun 2012 15:05:11 -0400 [thread overview]
Message-ID: <20120617190511.GA26047@savin> (raw)
In-Reply-To: <4FDE2460.5080301@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]
On Sun, Jun 17, 2012 at 02:39:28PM -0400, Alan Reiner wrote:
> All,
>
> With the flurry of discussion about blockchain compression, I
> thought it was time to put forward my final, most-advanced idea,
> into a single, well-thought-out, *illustrated*, forum post.
> Please check it out: https://bitcointalk.org/index.php?topic=88208.0
>
> This is a huge undertaking, but it has some pretty huge benefits.
> And it's actually feasible because it can be implemented without
> disrupting the main network. I'm sure there's lots of issues with
> it, but I'm putting it out there to see how it might be improved and
> actually executed.
>
> ----
> *Summary:
>
> */Use a special tree data structure to organize all unspent-TxOuts
> on the network, and use the root of this tree to communicate its
> "signature" between nodes. The leaves of this tree actually
> correspond to addresses/scripts, and the data at the leaf is
> actually a root of the unspent-TxOut list for that address/script.
> To maintain security of the tree signatures, it will be included in
> the header of an alternate blockchain, which will be secured by
> merged mining.
>
> This provides the same compression as the simpler unspent-TxOut
> merkle tree, but also gives nodes a way to download just the
> unspent-TxOut list for each address in their wallet, and verify that
> list directly against the blockheaders. Therefore, even lightweight
> nodes can get full address information, from any untrusted peer, and
> with only a tiny amount of downloaded data (a few kB). /*
How are you going to prevent people from delibrately unbalancing the
tree with addresses with chosen hashes?
One idea that comes to mind, which unfortunately would make for a
pseudo-network rule, is to simply say that any *new* address whose hash
happens to be deeper in the tree than, say, 10*log(n), indicating it was
probably chosen to be unbalanced, gets discarded. The "new address" part
of the rule would be required, or else you could use the rule to get
other people's addresses discarded.
Having said that, such a rule just means that anyone playing games will
find they can't spend *their* money, and only with pruning clients.
Unrelated people will not be effected. The coins can also always be
spent with a non-pruning client to an acceptable address, which can
later re-spend on a pruning client.
It also comes to mind is that with the popularity of firstbits it may be
a good idea to use a comparison function that works last bit first...
It's merkles all the way down...
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2012-06-17 20:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-17 18:39 Alan Reiner
2012-06-17 19:05 ` Peter Todd [this message]
2012-06-17 22:46 ` Alberto Torres
2012-06-17 23:17 ` Alan Reiner
2012-06-18 10:14 ` Peter Todd
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=20120617190511.GA26047@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=etotheipi@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