From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 To: Jeff Garzik Message-ID: <20130513211244.GA9550@netbook.cypherspace.org> References: <20130511045342.GA28588@petertodd.org> <20130511102209.GA27823@netbook.cypherspace.org> <20130513105408.GB3393@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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