📅 Original date posted:2013-05-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> - what about if a pool could lock the reward (rather than receive it or
> destroy it) eg some kind of merkle root instead of a public key hash in
> the reward recipient address field in the coinbase.
Sorry I don't have time for a full reply due to some other commitments, but you
remind me of an idea bouncing around to use a Merkle Sum tree as a way to split
one sacrifice among an arbitrarily large set of users. Credit goes to Gregory
Maxwell (according to the wiki) and the idea is to have the roots of the tree
be account "numbers" (pubkeys here) and account amounts. He proposed it for
off-chain transaction account ledgers, but the idea works equally well here to
split some initial sacrifice into lots of little bits. For instance a on-chain
sacrifice to an anyone-can-pay output could be split into enough parts to make
it useful even when tx fees become large.
Incidentally all this stuff about rivest paywords is probably silly, why not
just commit your sacrifice to a pubkey and make signatures saying what your new
balance is for each message and how much you intended to spend? This allows for
easy fraud proof creation, and gives you a choice of either lying to some
nodes, and getting poor propagation, or being honest and spending the amount
you should have.
For DoS protection it seems to me that mostly trusting nodes to give accurate
balances, enforced with a fraud proof system to halt double-spending, is
perfectly adequate. But no sense implementing so much complexity right at the
start of the effort! Just a thought for where things can go in the future.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRkaGUAAoJEEWCsU4mNhiPKsoH/1zhTBS/rINhF8oxxFoScD6i
0ybiUarIQEmmpAr3i46oMcSrw0SiOoiUzj6zvJorA21ddoErkTDVpMWI18RnKFos
bTC4NVzvcegLdnbYb+76XKOCMc1dchFXq+WEGRdu/WKzOL7ODUUKAl/hG2Fk4lPU
3x8mHq0k2pqMAYX5/TX0w0pDnS227L+V1O3EoZD86MjR/CliHsZyBnXIqyqV4rY8
354JswKQ/XWb85gwZwFq1WXsFIZAep+eRVqmOluu3Ol97c5G85utNYDkg2hALURy
gfpwmXKPFGm8h2lE1cMaOxkvQHOOPH8v7WdoBx08/ojhsyQNMpND4xej5FP/e5c=
=vrFC
-----END PGP SIGNATURE-----
John Dillon [ARCHIVE] /
npub15z…kn0zr
2023-06-07 15:01:47
in reply to nevent1q…va5p
Author Public Key
npub15z6e9t07ugx267aj3s3c487pln852ydytzlgu0vkkqxfznyvx4jq4kn0zrPublished at
2023-06-07 15:01:47Event JSON
{
"id": "c03cca4e9b0c76db8f1639805ac77a6521d4204289c5effd121dd4feb59bda68",
"pubkey": "a0b592adfee20cad7bb28c238a9fc1fccf4511a458be8e3d96b00c914c8c3564",
"created_at": 1686150107,
"kind": 1,
"tags": [
[
"e",
"3d231ffbf2b23d1e927eb23a9615f524e90075cdb16538107339b1567211693b",
"",
"root"
],
[
"e",
"84a64f28edc74602f0f54cf3fb97baf535b7a3357eecd00f4729e5c4268d9b91",
"",
"reply"
],
[
"p",
"ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a"
]
],
"content": "📅 Original date posted:2013-05-13\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\n\u003e - what about if a pool could lock the reward (rather than receive it or\n\u003e destroy it) eg some kind of merkle root instead of a public key hash in\n\u003e the reward recipient address field in the coinbase.\n\nSorry I don't have time for a full reply due to some other commitments, but you\nremind me of an idea bouncing around to use a Merkle Sum tree as a way to split\none sacrifice among an arbitrarily large set of users. Credit goes to Gregory\nMaxwell (according to the wiki) and the idea is to have the roots of the tree\nbe account \"numbers\" (pubkeys here) and account amounts. He proposed it for\noff-chain transaction account ledgers, but the idea works equally well here to\nsplit some initial sacrifice into lots of little bits. For instance a on-chain\nsacrifice to an anyone-can-pay output could be split into enough parts to make\nit useful even when tx fees become large.\n\nIncidentally all this stuff about rivest paywords is probably silly, why not\njust commit your sacrifice to a pubkey and make signatures saying what your new\nbalance is for each message and how much you intended to spend? This allows for\neasy fraud proof creation, and gives you a choice of either lying to some\nnodes, and getting poor propagation, or being honest and spending the amount\nyou should have.\n\nFor DoS protection it seems to me that mostly trusting nodes to give accurate\nbalances, enforced with a fraud proof system to halt double-spending, is\nperfectly adequate. But no sense implementing so much complexity right at the\nstart of the effort! Just a thought for where things can go in the future.\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.11 (GNU/Linux)\n\niQEcBAEBCAAGBQJRkaGUAAoJEEWCsU4mNhiPKsoH/1zhTBS/rINhF8oxxFoScD6i\n0ybiUarIQEmmpAr3i46oMcSrw0SiOoiUzj6zvJorA21ddoErkTDVpMWI18RnKFos\nbTC4NVzvcegLdnbYb+76XKOCMc1dchFXq+WEGRdu/WKzOL7ODUUKAl/hG2Fk4lPU\n3x8mHq0k2pqMAYX5/TX0w0pDnS227L+V1O3EoZD86MjR/CliHsZyBnXIqyqV4rY8\n354JswKQ/XWb85gwZwFq1WXsFIZAep+eRVqmOluu3Ol97c5G85utNYDkg2hALURy\ngfpwmXKPFGm8h2lE1cMaOxkvQHOOPH8v7WdoBx08/ojhsyQNMpND4xej5FP/e5c=\n=vrFC\n-----END PGP SIGNATURE-----",
"sig": "108462dac05972b43931424b3432e5b3fd4f0e728b0b67c95739b4278e92801fd86913a5ee4d28193cf381b0dca14ac8eda4919833eff358ec5b4f297171ef12"
}