Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2013-05-06 📝 Original message:On Mon, May 06, 2013 at ...
📅 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>;
📝 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>;