public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: Jeff Garzik <jgarzik@exmulti.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash)
Date: Mon, 13 May 2013 23:12:44 +0200	[thread overview]
Message-ID: <20130513211244.GA9550@netbook.cypherspace.org> (raw)
In-Reply-To: <CA+8xBpdmxpCPO77Nr=vDwsKAKTEU4PM4ButT3bDUkhA5tzc3Zw@mail.gmail.com>

Some musings about the differences between Peter's proof-of-sacrifice (you
did the work but elected to make the small reward chance unclaimable), vs
conventional actually doing the work but then destroying the bitcoin!

- proof-of-sacrifice seems similiar to hashcash except its difficulty is
   time stamped and measured against the bitcoins dynamic difficulty,
   (coordinated inflation control being something posited but never
   implemented in hashcash).  So thats kind of interesting, particularly if
   you can do it with very low bandwidth, and decentralized; unclear.

- with proof-of-sacrifice its more offline because you do not need an on
   block-chain double spend protection (via flood-fill, validation, and block
   chain mining) because it is simply "unspendable", though you could show
   the same proof to multiple people.  In any case the values are far too low
   to spam the block chain with.

- because proof-of-sacrifice is small you can afford to mine them on the
   spot and make them payable to the identity of the recipient, like cheques:
   they identify the recipient, so they are automaticaly non-respendable in
   the eyes of the recipient (he keeps his own double-spend db, and people
   wont accept cheques made payabe to other people).  This is how hashcash
   works for email.  Also a time-stamp ensures you dont even need a big
   double-spend db, as you can prune it if you reject expired cheqes.

- you could give a proof-of-sacrifice a private key, just like bitcoins;
   then they could be pre-mined and identity or other info could be signed
   later.  However then you have double spending issues again.  You can 

- I mentioned amortizable hashcash under-contribution feature you can make
   it so the recipient uncovers the actual value of the coin (if it is
   merge-mined).  (Put recipient public key in coinbase, hash for min share
   size eg 32-bits leading 0s call that "collision"; send to recipient, he
   decrypts the hash with private key, so the decryption is verifiable with
   public key.  Then the full value of the coin is 
	   zerobit( collision ) + zerobits( decrypt( collision ) )
   if that alternate validation was allowed in bitcoin.

- 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.  Then the miners who
   created that block have actual share proofs that are claims against
   something eventually redeemable.  Maybe if they collect enough
   share-proofs to reach a minimum bitcoin transaction size, they can redeem
   a big strip of shares for a few mBTC, but claims below that are rejected
   by the network due to tx fee.  (btw I think it seems possible to have a
   publicly auditable pool so it cant skim nor disclaim shares.)

>I've been thinking about a decentralized way to create an anonymous
>identity, something I think it key to any number of decentralized, P2P
>and anonymous markets.  

There were some systems that charged hashcash for pseudonyms i2p names (i2p
is a ToR like system)...  see htp://www.i2p2.e/naming.html then there was of
course namecoin.  There was some remailer/email nymserver integration as
well.

>Getting back on topic, somewhat, one idea I had for creation cost of a
>SIN was associating the creation cost of a SIN with a bitcoin
>transaction's miner fee.  Anybody in the world could, therefore,
>create a SIN in a decentralized fashion, simply by following a
>published protocol for burning a specified amount of bitcoins via
>miner fee.  It can be cryptographically proven with 100% certainty who

Yes it seems that having a proof-of-sacrifice that hardens the block chain
is the important part.

When you said destroy-via-miner-fee:

>Don't forget:  4. destroy-via-miner-fee, which is useful because it
>provides funding for a public service (bitcoin transaction
>verification).

Is that directly possible?  Because the reward transaction has no source,
and no fee?  Or can you put a 25BTC fee in the reward transaction in the
coinbase?

If so that seems like the best option for proof-of-sacrifice rather than
proving destroying the possibility of reward.  But alternatively the bitcoin
foundation as recipient, or EFF etc.  25BTC is a big reward might have some
double roll-over lottery effects - everyone piles in for the occasional
25BTC!

Adam

On Mon, May 13, 2013 at 02:38:15PM -0400, Jeff Garzik wrote:
>On Mon, May 13, 2013 at 6:54 AM, Adam Back <adam@cypherspace.org> wrote:
>> On Mon, May 13, 2013 at 07:31:21AM +0000, John Dillon wrote:
>>>[with] merge-mining [you get] more value from just one unit of work.
>>
>> correct.
>>
>>>But Peter's coinbase hashcash protocol carefully ensures [...] the amount
>>>of value the miner would have then given away in a "anyone-can-spend"
>>>output.
>>
>> I think there are 3 choices:
>>
>> 1. merged-mine (almost zero incremental cost as the bitcoin mining return is
>>     still earned)
>>
>> 2. destroy bitcoin (hash of public key is all 00s so no computible private
>>     key)
>>
>> 3. anyone-can-spend (= first to spend gets coin?)
>
>Don't forget:  4. destroy-via-miner-fee, which is useful because it
>provides funding for a public service (bitcoin transaction
>verification).
>
>(a tangent, but related)
>
>I've been thinking about a decentralized way to create an anonymous
>identity, something I think it key to any number of decentralized, P2P
>and anonymous markets.  My main focus, for this identity project, is
>to develop a decentralized protocol for generating a UUID-like unique
>identifier (bitstring), in a way that has some amount of creation cost
>attached (to prevent creating a billion of such tokens etc.).  I call
>it a system identifier, or SIN.
>
>Once you have a SIN, you may associate the SIN with a GPG fingerprint,
>email address, real name, login credentials, etc.  eBay-like
>marketplaces publish SIN ratings (though it displays on screen as
>"jgarzik" not "1234-abcd-5678-def0").  Standard-and-Poors style
>ratings agencies would similarly rate a business's SIN.  SIN's build a
>reputation and trust over time, while controlling their own anonymity
>(or lack thereof).  Anybody may abandon a SIN at any time. Ownership
>of a SIN is cryptographically proven via digital signature.
>
>Getting back on topic, somewhat, one idea I had for creation cost of a
>SIN was associating the creation cost of a SIN with a bitcoin
>transaction's miner fee.  Anybody in the world could, therefore,
>create a SIN in a decentralized fashion, simply by following a
>published protocol for burning a specified amount of bitcoins via
>miner fee.  It can be cryptographically proven with 100% certainty who
>made such a transaction, and the miner fee attaches a creation cost to
>ensure that SINs are not -too- cheap.
>
>Burn-via-miner-fee is a useful tool outside of this example.  It funds
>a public service, providing a positive feedback loop for miners who
>receive fees via such services.
>
>-- 
>Jeff Garzik
>exMULTI, Inc.
>jgarzik@exmulti.com



  reply	other threads:[~2013-05-13 21:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-11  4:53 [Bitcoin-development] Coinbase TxOut Hashcash Peter Todd
2013-05-11 10:22 ` [Bitcoin-development] merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash) Adam Back
2013-05-13  7:31   ` John Dillon
2013-05-13 10:54     ` Adam Back
2013-05-13 18:38       ` Jeff Garzik
2013-05-13 21:12         ` Adam Back [this message]
2013-05-13 22:00           ` Jeff Garzik
2013-05-14  9:25             ` Adam Back
2013-05-14 16:50               ` Jeff Garzik
2013-05-14 20:07                 ` Adam Back
2013-05-14  2:30           ` John Dillon
2013-05-14 17:25         ` 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=20130513211244.GA9550@netbook.cypherspace.org \
    --to=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jgarzik@exmulti.com \
    /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