📅 Original date posted:2013-05-20
📝 Original message:This is exactly what I was planning to do with the inappropriately-named
"Ultimate Blockchain Compression
<https://bitcointalk.org/index.php?topic=88208.0>";. I wanted to
reorganize the blockchain data into an authenticated tree, indexed by
TxOut script (address), instead of tx-hash. Much like a regular merkle
tree, you can store the root in the block header, and communicate
branches of that tree to nodes, to prove inclusion (and exclusion!) of
TxOuts for any given script/address. Additionally, you can include at
each node, the sum of BTC in all nodes below it, which offers some other
nice benefits.
I think this idea is has epic upside-potential for bitcoin if it works
-- even "SPV" nodes could query their unspent TxOut list for their
wallet from any untrusted peer and compare the result directly to the
blockheaders/POW. Given nothing but the headers, you can verify the
balance of 100 addresses with 250 kB. But also epic failure-potential
in terms of feasibility and cost-to-benefit for miners. For it to
really work, it's gotta be part of the mainnet validation rules, but no
way it can be evaluated realistically without some kind of "staging".
Therefore, I had proposed that this be merge-mined on a "meta-chain"
first...get a bunch of miners on board to agree to merge mine and see it
in action. It seemed like a perfectly non-disruptive way to prove out a
particular idea before we actually consider making a protocol change
that significant. Even if it stayed on its own meta chain, as long as
there is some significant amount of hashpower working on it, it can
still be a useful tool.
Unfortunately, my experience with merged mining is minimal, so I'm still
not clear how feasible/reliable it is as an alternative to direct
blockchain integration. That's a discussion I'd like to have.
-Alan
On 5/19/2013 11:08 AM, Peter Vessenes wrote:
> I think this is a very interesting idea. As Bitcoiners, we often stuff
> things into the 'alt chain' bucket in our heads; I wonder if this idea
> works better as a curing period, essentially an extended version of
> the current 100 block wait for mined coins.
>
> An alternate setup comes to mind; I can imagine this working as a sort
> of gift economy; people pay real BTC for merge-mined "beta BTC" as a
> way to support development. There is no doubt a more elegant and
> practical solution that might have different economic and crypto
> characteristics.
>
>
>
> On Sun, May 19, 2013 at 6:23 AM, Adam Back <adam at cypherspace.org
> <mailto:adam at cypherspace.org>> wrote:
>
> Is there a way to experiment with new features - eg committed
> coins - that
> doesnt involve an altcoin in the conventional sense, and also
> doesnt impose
> a big testing burden on bitcoin main which is a security and
> testing risk?
>
> eg lets say some form of merged mine where an alt-coin lets call it
> bitcoin-staging? where the coins are the same coins as on
> bitcoin, the
> mining power goes to bitcoin main, so some aspect of merged
> mining, but no
> native mining. and ability to use bitcoins by locking them on
> bitcoin to
> move them to bitcoin-staging and vice versa (ie exchange them 1:1
> cryptographically, no exchange).
>
> Did anyone figure anything like that out? Seems vaguely doable and
> maybe productive. The only people with coins at risk of defects
> in a new
> feature, or insufficiently well tested novel feature are people
> with coins
> on bitcoin-staging.
>
> Yes I know about bitcoin-test this is not it. I mean a real live
> system,
> with live value, but that is intentionally wanting to avoid
> forking bitcoins
> parameters, nor value, nor mindshare dillution. In this way something
> potentially interesting could move forward faster, and be les
> risky to the
> main bitcoin network. eg particularly defenses against
>
> It might also be a more real world test test (after bitcoin-test)
> because
> some parameters are different on test, and some issues may not
> manifest
> without more real activity.
>
> Then also bitcoin could cherry pick interesting patches and merge
> them after
> extensive real-world validation with real-money at stake (by early
> adopters).
>
> Adam
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers
> complete
> security visibility with the essential security capabilities.
> Easily and
> efficiently configure, manage, and operate all of your security
> controls
> from a single console and one unified framework. Download a free
> trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> --
> Are you coming to Bitcoin2013 <http://bitcoin2013.com>; in San Jose In
> May?
> ------------------------------------------------------------------------
>
> CoinLab LogoPETER VESSENES
> CEO
>
> *peter at coinlab.com <mailto:peter at coinlab.com> * / 206.486.6856 /
> SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104
>
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130520/93b18b19/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 15:02:07
in reply to nevent1q…8fns
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 15:02:07Event JSON
{
"id": "1d51ff7f59b7a9fb637fe001e34e21764816ebdc613449a8c996dbda9e3a2d27",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686150127,
"kind": 1,
"tags": [
[
"e",
"dfac3b8c3d4b4aefee08c49b225b3bcc1ae2479739ace82710f9382ddc46465a",
"",
"root"
],
[
"e",
"bd0af31fd540102c7c4b38bdcd4d2c7fca05ae0d4970999d915948aff1227b77",
"",
"reply"
],
[
"p",
"c8914ab5f1efb93771e9c5b7fe20dcff2c343f46f4846ae6689a0c9478b04e01"
]
],
"content": "📅 Original date posted:2013-05-20\n📝 Original message:This is exactly what I was planning to do with the inappropriately-named \n\"Ultimate Blockchain Compression \n\u003chttps://bitcointalk.org/index.php?topic=88208.0\u003e\". I wanted to \nreorganize the blockchain data into an authenticated tree, indexed by \nTxOut script (address), instead of tx-hash. Much like a regular merkle \ntree, you can store the root in the block header, and communicate \nbranches of that tree to nodes, to prove inclusion (and exclusion!) of \nTxOuts for any given script/address. Additionally, you can include at \neach node, the sum of BTC in all nodes below it, which offers some other \nnice benefits.\n\nI think this idea is has epic upside-potential for bitcoin if it works \n-- even \"SPV\" nodes could query their unspent TxOut list for their \nwallet from any untrusted peer and compare the result directly to the \nblockheaders/POW. Given nothing but the headers, you can verify the \nbalance of 100 addresses with 250 kB. But also epic failure-potential \nin terms of feasibility and cost-to-benefit for miners. For it to \nreally work, it's gotta be part of the mainnet validation rules, but no \nway it can be evaluated realistically without some kind of \"staging\". \nTherefore, I had proposed that this be merge-mined on a \"meta-chain\" \nfirst...get a bunch of miners on board to agree to merge mine and see it \nin action. It seemed like a perfectly non-disruptive way to prove out a \nparticular idea before we actually consider making a protocol change \nthat significant. Even if it stayed on its own meta chain, as long as \nthere is some significant amount of hashpower working on it, it can \nstill be a useful tool.\n\nUnfortunately, my experience with merged mining is minimal, so I'm still \nnot clear how feasible/reliable it is as an alternative to direct \nblockchain integration. That's a discussion I'd like to have.\n\n-Alan\n\n\nOn 5/19/2013 11:08 AM, Peter Vessenes wrote:\n\u003e I think this is a very interesting idea. As Bitcoiners, we often stuff \n\u003e things into the 'alt chain' bucket in our heads; I wonder if this idea \n\u003e works better as a curing period, essentially an extended version of \n\u003e the current 100 block wait for mined coins.\n\u003e\n\u003e An alternate setup comes to mind; I can imagine this working as a sort \n\u003e of gift economy; people pay real BTC for merge-mined \"beta BTC\" as a \n\u003e way to support development. There is no doubt a more elegant and \n\u003e practical solution that might have different economic and crypto \n\u003e characteristics.\n\u003e\n\u003e\n\u003e\n\u003e On Sun, May 19, 2013 at 6:23 AM, Adam Back \u003cadam at cypherspace.org \n\u003e \u003cmailto:adam at cypherspace.org\u003e\u003e wrote:\n\u003e\n\u003e Is there a way to experiment with new features - eg committed\n\u003e coins - that\n\u003e doesnt involve an altcoin in the conventional sense, and also\n\u003e doesnt impose\n\u003e a big testing burden on bitcoin main which is a security and\n\u003e testing risk?\n\u003e\n\u003e eg lets say some form of merged mine where an alt-coin lets call it\n\u003e bitcoin-staging? where the coins are the same coins as on\n\u003e bitcoin, the\n\u003e mining power goes to bitcoin main, so some aspect of merged\n\u003e mining, but no\n\u003e native mining. and ability to use bitcoins by locking them on\n\u003e bitcoin to\n\u003e move them to bitcoin-staging and vice versa (ie exchange them 1:1\n\u003e cryptographically, no exchange).\n\u003e\n\u003e Did anyone figure anything like that out? Seems vaguely doable and\n\u003e maybe productive. The only people with coins at risk of defects\n\u003e in a new\n\u003e feature, or insufficiently well tested novel feature are people\n\u003e with coins\n\u003e on bitcoin-staging.\n\u003e\n\u003e Yes I know about bitcoin-test this is not it. I mean a real live\n\u003e system,\n\u003e with live value, but that is intentionally wanting to avoid\n\u003e forking bitcoins\n\u003e parameters, nor value, nor mindshare dillution. In this way something\n\u003e potentially interesting could move forward faster, and be les\n\u003e risky to the\n\u003e main bitcoin network. eg particularly defenses against\n\u003e\n\u003e It might also be a more real world test test (after bitcoin-test)\n\u003e because\n\u003e some parameters are different on test, and some issues may not\n\u003e manifest\n\u003e without more real activity.\n\u003e\n\u003e Then also bitcoin could cherry pick interesting patches and merge\n\u003e them after\n\u003e extensive real-world validation with real-money at stake (by early\n\u003e adopters).\n\u003e\n\u003e Adam\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e AlienVault Unified Security Management (USM) platform delivers\n\u003e complete\n\u003e security visibility with the essential security capabilities.\n\u003e Easily and\n\u003e efficiently configure, manage, and operate all of your security\n\u003e controls\n\u003e from a single console and one unified framework. Download a free\n\u003e trial.\n\u003e http://p.sf.net/sfu/alienvault_d2d\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003cmailto:Bitcoin-development at lists.sourceforge.net\u003e\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e -- \n\u003e Are you coming to Bitcoin2013 \u003chttp://bitcoin2013.com\u003e in San Jose In \n\u003e May?\n\u003e ------------------------------------------------------------------------\n\u003e\n\u003e CoinLab LogoPETER VESSENES\n\u003e CEO\n\u003e\n\u003e *peter at coinlab.com \u003cmailto:peter at coinlab.com\u003e * / 206.486.6856 / \n\u003e SKYPE: vessenes\n\u003e 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e AlienVault Unified Security Management (USM) platform delivers complete\n\u003e security visibility with the essential security capabilities. Easily and\n\u003e efficiently configure, manage, and operate all of your security controls\n\u003e from a single console and one unified framework. Download a free trial.\n\u003e http://p.sf.net/sfu/alienvault_d2d\n\u003e\n\u003e\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130520/93b18b19/attachment.html\u003e",
"sig": "a2c82979ccef666c37e72951fae7ba628ee23ab1d0ddc83433c347bc871c41243d2f2e233ef2d6d2e4b72e953e35e7d0d7c0ae3ace3dfce79cc38b0dd73c85d8"
}