From: Peter Todd <pete@petertodd•org>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
Date: Mon, 6 May 2013 16:43:07 -0400 [thread overview]
Message-ID: <20130506204307.GA23287@petertodd.org> (raw)
In-Reply-To: <20130506195003.GB4583@netbook.cypherspace.org>
[-- Attachment #1: Type: text/plain, Size: 2952 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-05-06 20:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 14:58 Mike Hearn
2013-05-06 16:12 ` Peter Todd
2013-05-06 16:20 ` Jeff Garzik
2013-05-06 16:34 ` Mike Hearn
2013-05-06 16:37 ` Peter Todd
2013-05-06 16:47 ` Mike Hearn
2013-05-06 17:19 ` Peter Todd
2013-05-06 17:25 ` Jeff Garzik
2013-05-06 17:42 ` Gregory Maxwell
2013-05-06 17:53 ` Peter Todd
2013-05-06 18:01 ` Gregory Maxwell
2013-05-06 18:19 ` Peter Todd
2013-05-06 18:32 ` Adam Back
2013-05-06 19:08 ` Peter Todd
2013-05-06 19:50 ` Adam Back
2013-05-06 20:43 ` Peter Todd [this message]
2013-05-06 23:44 ` Peter Todd
2013-05-07 9:00 ` Mike Hearn
2013-05-09 0:57 ` John Dillon
2013-05-06 18:04 ` Adam Back
2013-05-06 18:25 ` Gregory Maxwell
2013-05-06 22:51 ` [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) Adam Back
2013-05-06 23:13 ` Gregory Maxwell
2013-05-07 4:48 ` Petr Praus
2013-05-07 21:07 ` Matt Corallo
2013-05-07 9:17 ` Mike Hearn
2013-05-07 11:07 ` Adam Back
2013-05-07 12:04 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130506204307.GA23287@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox