📅 Original date posted:2012-06-17
📝 Original message: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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Alberto Torres [ARCHIVE] /
npub1y5…ee2jx
2023-06-07 10:17:13
in reply to nevent1q…tk28
Author Public Key
npub1y5ah9ju4pe76tdqnv3xas2a8zffvphpxfs7zqqrjyk0fdra6j8hsqee2jxSeen on
wss://relay.nostr.bandPublished at
2023-06-07 10:17:13Event JSON
{
"id": "47e726976bb34005cec86c82b731d6592d2b94b865bc13137949379ea8e57d02",
"pubkey": "253b72cb950e7da5b413644dd82ba71252c0dc264c3c200072259e968fba91ef",
"created_at": 1686133033,
"kind": 1,
"tags": [
[
"e",
"466ce9b7acdc00249506eef38171b0c7d92706a2dd94a8113834a81b187f898e",
"",
"root"
],
[
"e",
"b2683847613f9b6cf02b613d9a9299aebcf548eb0444be8439b049ab399f356f",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2012-06-17\n📝 Original message:Hi,\n\nI did describe a very similar thing back in January (also illustrated,\nand, if I'm not mistaken, more simple and efficient to recalculate),\nand I wanted to do a prototype, but I have been very busy with other\nprojects since then.\n\nhttps://en.bitcoin.it/wiki/User:DiThi/MTUT\n\nI just saw Gavin left a comment in the talk page, I'm sorry I haven't\nseen it earlier.\n\nI think armory is the perfect client to implement such an idea. I sort\nof waited it to be able to run in my laptop with 2 GB of RAM before\nbeing sucked into other projects. I even lost track of its\ndevelopment.\n\nI hope this gets developed. I will be able to help after summer if\nthis is still not done.\n\nDiThi\n\nP.S: Sorry Peter, I've sent you the message privately by mistake.\nAlso, I don't quite understand your concern of \"unbalancing\" the tree.\n\n2012/6/17 Peter Todd \u003cpete at petertodd.org\u003e:\n\u003e On Sun, Jun 17, 2012 at 02:39:28PM -0400, Alan Reiner wrote:\n\u003e\u003e All,\n\u003e\u003e\n\u003e\u003e With the flurry of discussion about blockchain compression, I\n\u003e\u003e thought it was time to put forward my final, most-advanced idea,\n\u003e\u003e into a single, well-thought-out, *illustrated*, forum post.\n\u003e\u003e Please check it out: https://bitcointalk.org/index.php?topic=88208.0\n\u003e\u003e\n\u003e\u003e This is a huge undertaking, but it has some pretty huge benefits.\n\u003e\u003e And it's actually feasible because it can be implemented without\n\u003e\u003e disrupting the main network. I'm sure there's lots of issues with\n\u003e\u003e it, but I'm putting it out there to see how it might be improved and\n\u003e\u003e actually executed.\n\u003e\u003e\n\u003e\u003e ----\n\u003e\u003e *Summary:\n\u003e\u003e\n\u003e\u003e */Use a special tree data structure to organize all unspent-TxOuts\n\u003e\u003e on the network, and use the root of this tree to communicate its\n\u003e\u003e \"signature\" between nodes. The leaves of this tree actually\n\u003e\u003e correspond to addresses/scripts, and the data at the leaf is\n\u003e\u003e actually a root of the unspent-TxOut list for that address/script.\n\u003e\u003e To maintain security of the tree signatures, it will be included in\n\u003e\u003e the header of an alternate blockchain, which will be secured by\n\u003e\u003e merged mining.\n\u003e\u003e\n\u003e\u003e This provides the same compression as the simpler unspent-TxOut\n\u003e\u003e merkle tree, but also gives nodes a way to download just the\n\u003e\u003e unspent-TxOut list for each address in their wallet, and verify that\n\u003e\u003e list directly against the blockheaders. Therefore, even lightweight\n\u003e\u003e nodes can get full address information, from any untrusted peer, and\n\u003e\u003e with only a tiny amount of downloaded data (a few kB). /*\n\u003e\n\u003e How are you going to prevent people from delibrately unbalancing the\n\u003e tree with addresses with chosen hashes?\n\u003e\n\u003e One idea that comes to mind, which unfortunately would make for a\n\u003e pseudo-network rule, is to simply say that any *new* address whose hash\n\u003e happens to be deeper in the tree than, say, 10*log(n), indicating it was\n\u003e probably chosen to be unbalanced, gets discarded. The \"new address\" part\n\u003e of the rule would be required, or else you could use the rule to get\n\u003e other people's addresses discarded.\n\u003e\n\u003e Having said that, such a rule just means that anyone playing games will\n\u003e find they can't spend *their* money, and only with pruning clients.\n\u003e Unrelated people will not be effected. The coins can also always be\n\u003e spent with a non-pruning client to an acceptable address, which can\n\u003e later re-spend on a pruning client.\n\u003e\n\u003e\n\u003e It also comes to mind is that with the popularity of firstbits it may be\n\u003e a good idea to use a comparison function that works last bit first...\n\u003e\n\u003e\n\u003e It's merkles all the way down...\n\u003e\n\u003e --\n\u003e 'peter'[:-1]@petertodd.org\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Live Security Virtual Conference\n\u003e Exclusive live event will cover all the ways today's security and\n\u003e threat landscape has changed and how IT managers can respond. Discussions\n\u003e will include endpoint security, mobile security and the latest in malware\n\u003e threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e",
"sig": "f0463e2e8bdfd0ff6f09a6509be2526b74d00de038e5a3c7ed87866a2548e2ea2f4c6fe2eb61f454294127d78cdbe60c0b77fdbf7e764016d9a065d57332d4a4"
}