📅 Original date posted:2013-05-06
📝 Original message:On Mon, May 06, 2013 at 09:50:03PM +0200, Adam Back wrote:
> Of course you'd probably need zerocoin to stand much chance of proving an
> address private key of an unlinked coin was in the double-spend disclosed
> attribute in the first place, and as we know zerocoin is not that efficient.
Sounds like a lot of research potential with many far off possiblities. :)
> >Make the node identity expensive to obtain. For instance, construct PoW's
> >including the node pubkey somehow,
>
> that could be easily done with the work of creating a vanity address. eg
> address containing many leading 0s.
Bitcoin is interesting because it provides a nice way to determine the
value of a proof-of-work. Lets suppose you have a digest D and want to
create a proof of work for that digest.
1) Select a block B1 that is reasonably deep in the blockchain. (You
don't want it getting re-orged out of existence) Six blocks deep is
probably plenty.
2) Construct an invalid block header, BP, with SHA256(B1 | D) as the
previous block hash. All other fields can be set to whatever is required
by your hashing unit. (the merkle root would be an option too, but many
hashing setups can't put arbitrary data into it)
3) Hash until you have found the PoW with the difficulty you want.
4) Timestamp BP in the blockchain, resulting in a merkle path M leading to
a subsequent block B2. (1)
Now determining the value of D has a nice compact proof: B1, BP and M
and B2. Taking the minimum of the difficulties of B1 and B2 (in case
they cross a retarget boundry; don't want to create strange incentives)
determine the expected return in Bitcoins from the block reward had the
hasher solved valid blocks instead and you can determine exactly how
much the proof-of-work was worth, kinda...
Things get a bit complex from here on. First of all there isn't a
compact proof that will tell you how much the fees of solving that block
would have been worth, and there can't be because miners can easily
manipulate the apparent fees of a block in both directions.
Also as with fidelity bonds (https://en.bitcoin.it/wiki/Fidelity_bonds)
the question of which value to use, historic or current, is important
too. If you use the Bitcoin face value increases or decreases of the
value of a Bitcoin are arguably distorting. On the other hand, if you
use historical exchange rates, which currency do you use and where do
you get trustworthy historical exchange rate data? (2)
1) See https://github.com/opentimestamps
2) Which reminds me, I do need to get around to bugging Mt. Gox to PGP
sign their exchange rate data and timestamp it properly, or do one or
both myself. It should be archived at archive.org or something too,
heck, the blockchain should be too, although timestamping that will
require a bit more work...
--
'peter'[:-1]@petertodd.org
0000000000000190ee1bf5262b2557eb69b49d0e14e1d644ec44a8488f7f5181
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130506/d4cb96db/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 14:56:31
in reply to nevent1q…ns4l
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 14:56:31Event JSON
{
"id": "67f8df9afe8d8d1cb77f1552545259dcdb184ce35096098ac0be15de9c67255e",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686149791,
"kind": 1,
"tags": [
[
"e",
"9cb33d8203a5589d82e93e68414f2319cab88bed2fa44a0f49d161195eb0441f",
"",
"root"
],
[
"e",
"b1a48a3f5da664510ef1cb1ad345293d27a62a7b10c6fac7716223e71b0e8842",
"",
"reply"
],
[
"p",
"ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a"
]
],
"content": "📅 Original date posted:2013-05-06\n📝 Original message:On Mon, May 06, 2013 at 09:50:03PM +0200, Adam Back wrote:\n\u003e Of course you'd probably need zerocoin to stand much chance of proving an\n\u003e address private key of an unlinked coin was in the double-spend disclosed\n\u003e attribute in the first place, and as we know zerocoin is not that efficient.\n\nSounds like a lot of research potential with many far off possiblities. :)\n\n\u003e \u003eMake the node identity expensive to obtain. For instance, construct PoW's\n\u003e \u003eincluding the node pubkey somehow,\n\u003e \n\u003e that could be easily done with the work of creating a vanity address. eg\n\u003e address containing many leading 0s.\n\nBitcoin is interesting because it provides a nice way to determine the\nvalue of a proof-of-work. Lets suppose you have a digest D and want to\ncreate a proof of work for that digest.\n\n1) Select a block B1 that is reasonably deep in the blockchain. (You\ndon't want it getting re-orged out of existence) Six blocks deep is\nprobably plenty.\n\n2) Construct an invalid block header, BP, with SHA256(B1 | D) as the\nprevious block hash. All other fields can be set to whatever is required\nby your hashing unit. (the merkle root would be an option too, but many\nhashing setups can't put arbitrary data into it)\n\n3) Hash until you have found the PoW with the difficulty you want.\n\n4) Timestamp BP in the blockchain, resulting in a merkle path M leading to\na subsequent block B2. (1)\n\n\nNow determining the value of D has a nice compact proof: B1, BP and M\nand B2. Taking the minimum of the difficulties of B1 and B2 (in case\nthey cross a retarget boundry; don't want to create strange incentives)\ndetermine the expected return in Bitcoins from the block reward had the\nhasher solved valid blocks instead and you can determine exactly how\nmuch the proof-of-work was worth, kinda...\n\nThings get a bit complex from here on. First of all there isn't a\ncompact proof that will tell you how much the fees of solving that block\nwould have been worth, and there can't be because miners can easily\nmanipulate the apparent fees of a block in both directions.\n\nAlso as with fidelity bonds (https://en.bitcoin.it/wiki/Fidelity_bonds)\nthe question of which value to use, historic or current, is important\ntoo. If you use the Bitcoin face value increases or decreases of the\nvalue of a Bitcoin are arguably distorting. On the other hand, if you\nuse historical exchange rates, which currency do you use and where do\nyou get trustworthy historical exchange rate data? (2)\n\n\n1) See https://github.com/opentimestamps\n\n2) Which reminds me, I do need to get around to bugging Mt. Gox to PGP\nsign their exchange rate data and timestamp it properly, or do one or\nboth myself. It should be archived at archive.org or something too,\nheck, the blockchain should be too, although timestamping that will\nrequire a bit more work...\n\n-- \n'peter'[:-1]@petertodd.org\n0000000000000190ee1bf5262b2557eb69b49d0e14e1d644ec44a8488f7f5181\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130506/d4cb96db/attachment.sig\u003e",
"sig": "08c038e6ff79d219539697444288a33d55acaa0d62b8980f5be1040254b1d634a39069032e14d4a82355bd784eb618844b0e726c9893829347f6b0885de96041"
}