Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <adam.back@gmail.com>) id 1Uc03F-0003Jn-L2
	for bitcoin-development@lists.sourceforge.net;
	Mon, 13 May 2013 21:12:57 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.174 as permitted sender)
	client-ip=209.85.215.174; envelope-from=adam.back@gmail.com;
	helo=mail-ea0-f174.google.com; 
Received: from mail-ea0-f174.google.com ([209.85.215.174])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Uc03D-0002GF-M4
	for bitcoin-development@lists.sourceforge.net;
	Mon, 13 May 2013 21:12:57 +0000
Received: by mail-ea0-f174.google.com with SMTP id z7so2834953eaf.5
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 13 May 2013 14:12:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent:x-hashcash:x-hashcash:x-hashcash:x-hashcash;
	bh=hzeuDJBjmw3JmDHtf7FUsB6gxqW7naol13FTlR2+1Mc=;
	b=M62tLFEI90h7Pqi3AikqvZE5ENX6nB4hm7f/pED2ztJZgPur8HMho79YBF5gMJiFEf
	MH7FW96FHdnlsf49azYAFyVLJDJvB4Nt7XCshkVaaVgv6qrCtXEpC11s95dvA/HMMfgO
	xaQAJ22RHmHSR/Ds/4xcqwaCl/FGJfLOo69JBPIbbgNXz4G/rAmZjkwDjDz4JauRLX8O
	P7l2Hpa8fwgjrMror//g6PqDb0myqnH2TzXHgFBLoR6UR4b3rUCTsef0CGE0fGvQnVo/
	lv7+DjrY5xWk9dYLiPvE14k29lvlBBbqFacRPtakAHPYs0JBLbK2AaHCsHnHfTTMHkBP
	YjoA==
X-Received: by 10.14.221.67 with SMTP id q43mr36944837eep.1.1368479569310;
	Mon, 13 May 2013 14:12:49 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
	by mx.google.com with ESMTPSA id
	bp51sm25482284eeb.5.2013.05.13.14.12.47 for <multiple recipients>
	(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 13 May 2013 14:12:48 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
	id 5F6522E0619; Mon, 13 May 2013 23:12:47 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
	Mon, 13 May 2013 23:12:44 +0200
Date: Mon, 13 May 2013 23:12:44 +0200
From: Adam Back <adam@cypherspace.org>
To: Jeff Garzik <jgarzik@exmulti.com>
Message-ID: <20130513211244.GA9550@netbook.cypherspace.org>
References: <20130511045342.GA28588@petertodd.org>
	<20130511102209.GA27823@netbook.cypherspace.org>
	<CAPaL=UV7B2ULcUSBBQNWKc70PzGnveeF2WiWQE7msteZ6TZAbQ@mail.gmail.com>
	<20130513105408.GB3393@netbook.cypherspace.org>
	<CA+8xBpdmxpCPO77Nr=vDwsKAKTEU4PM4ButT3bDUkhA5tzc3Zw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CA+8xBpdmxpCPO77Nr=vDwsKAKTEU4PM4ButT3bDUkhA5tzc3Zw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130513:jgarzik@exmulti.com::cuvIqcCFmrSxF4b+:000000000000000000
	000000000000000000000000A0Jf
X-Hashcash: 1:20:130513:john.dillon892@googlemail.com::h+hGgidkB/ipAceZ:00000000
	0000000000000000000000000sJX
X-Hashcash: 1:20:130513:bitcoin-development@lists.sourceforge.net::zkKq8NJ54nlDU
	PZ8:000000000000000000005VL9
X-Hashcash: 1:20:130513:adam@cypherspace.org::AlbJKmXccS0j2Kvg:00000000000000000
	0000000000000000000000000DA8
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(adam.back[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1Uc03D-0002GF-M4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] merged mining hashcash & bitcoin (Re:
 Coinbase TxOut Hashcash)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2013 21:12:57 -0000

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