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 19:44:11 -0400 [thread overview]
Message-ID: <20130506234411.GA26567@petertodd.org> (raw)
In-Reply-To: <20130506204307.GA23287@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]
On Mon, May 06, 2013 at 04:43:07PM -0400, Peter Todd wrote:
> 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...
One last thought... suppose you want to make these proof-of-works
transferable on the blockchain, as is easily possible with
announce/commit fidelity bond sacrifices. The problem is of course
re-use - you don't want it to be possible to use the same proof-of-work
for a different asset.
So for D use the txid:vout pair of a txout that you can spend, then
spend it to some output to create the start of the smartcoin/contract
asset chain. The txout can only be spent once, so the PoW is inherently
non-reusable.
The final proof is a more compact than a fidelity bond proof, just the
PoW block and a single transaction and existence proof rather than two
or three. (announce, commit, and commit txin if sacrifice is via fees)
Unfortunately PoW schemes do mean you are actually taking away from the
overall security of the network, and if there was a lot of demand for
these things it will lead to the undesirable effect of making it easy to
rent hashing power. Botnet owners will be happy to have a task that
requires even less communication than Bitcoin itself. Finally the
varience inherent in them is annoying too. But it's an interesting idea.
--
'peter'[:-1]@petertodd.org
00000000000001358eaf811792b28798a04103b2e47aecf54268736514defd2f
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-05-06 23:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 14:58 [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes) 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
2013-05-06 23:44 ` Peter Todd [this message]
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=20130506234411.GA26567@petertodd.org \
--to=pete@petertodd.org \
--cc=adam@cypherspace.org \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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