From: Alberto Torres <kungfoobar@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite nodes
Date: Mon, 18 Jun 2012 00:46:47 +0200 [thread overview]
Message-ID: <CAE98tO2PcxKdz670ptHB=3Pc9JvV_+Wjdt1117M4SA2hANKH+w@mail.gmail.com> (raw)
In-Reply-To: <20120617190511.GA26047@savin>
Hi,
I did describe a very similar thing back in January (also illustrated,
and, if I'm not mistaken, more simple and efficient to recalculate),
and I wanted to do a prototype, but I have been very busy with other
projects since then.
https://en.bitcoin.it/wiki/User:DiThi/MTUT
I just saw Gavin left a comment in the talk page, I'm sorry I haven't
seen it earlier.
I think armory is the perfect client to implement such an idea. I sort
of waited it to be able to run in my laptop with 2 GB of RAM before
being sucked into other projects. I even lost track of its
development.
I hope this gets developed. I will be able to help after summer if
this is still not done.
DiThi
P.S: Sorry Peter, I've sent you the message privately by mistake.
Also, I don't quite understand your concern of "unbalancing" the tree.
2012/6/17 Peter Todd <pete@petertodd•org>:
> 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
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
next prev parent reply other threads:[~2012-06-17 22:47 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
2012-06-17 22:46 ` Alberto Torres [this message]
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='CAE98tO2PcxKdz670ptHB=3Pc9JvV_+Wjdt1117M4SA2hANKH+w@mail.gmail.com' \
--to=kungfoobar@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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