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 1UjG6K-0006Il-3e for bitcoin-development@lists.sourceforge.net; Sun, 02 Jun 2013 21:46:08 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.176 as permitted sender) client-ip=209.85.212.176; envelope-from=adam.back@gmail.com; helo=mail-wi0-f176.google.com; Received: from mail-wi0-f176.google.com ([209.85.212.176]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UjG6I-0007jX-Ut for bitcoin-development@lists.sourceforge.net; Sun, 02 Jun 2013 21:46:08 +0000 Received: by mail-wi0-f176.google.com with SMTP id hr14so2126710wib.9 for ; Sun, 02 Jun 2013 14:46:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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; bh=rCf9TtpOaPuZQedx2UilwcsEXJJknZC96Sti8hGC1K8=; b=Z6cxrDigZH26u1uN+Td8ff/qp61fuS7K9lB5ILzn2DgPsUheA3jwYbtswBOfvpFVlT cHYpE7rIWwhadYPo6bg/O0tj6qDqMoeM9M3V5bp40OGAVcgpWMwCBwxMtzmKOkEMDROw 8P4nj/VopcAte3b4fqzuHqxPqGzqgbsEKyt37gN/mbeMYlVLzeWP42dvm4FMLRdeZ7Fp Vb4MQVjMAbCd4BJjEDSyM7Ii/ImG5mM43V2Z6Vgln3KqrXHiLaJAR3OfoVg/v4W1yQZJ 1wf2WY/VVevV+5HPQt6rrQbCsqahfMtjSF1xVWS8D6YKZnVUzhaAgLmwDSwfvZQkoO2U vArg== X-Received: by 10.180.90.164 with SMTP id bx4mr10474794wib.13.1370209560715; Sun, 02 Jun 2013 14:46:00 -0700 (PDT) Received: from netbook (88-105-4-7.dynamic.dsl.as9105.com. [88.105.4.7]) by mx.google.com with ESMTPSA id q13sm19389862wie.8.2013.06.02.14.45.59 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Jun 2013 14:45:59 -0700 (PDT) Received: by netbook (Postfix, from userid 1000) id D53642E0748; Sun, 2 Jun 2013 23:45:57 +0200 (CEST) Received: by flare (hashcash-sendmail, from uid 1000); Sun, 2 Jun 2013 23:45:54 +0200 Date: Sun, 2 Jun 2013 23:45:54 +0200 From: Adam Back To: Peter Todd Message-ID: <20130602214553.GA11528@netbook.cypherspace.org> References: <20130601193036.GA13873@savin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20130601193036.GA13873@savin> User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:130602:pete@petertodd.org::y03R0EyuGNIyA/hr:0000000000000000000 000000000000000000000000F0Re X-Hashcash: 1:20:130602:bitcoin-development@lists.sourceforge.net::8I/wOdClW8Bn8 ps1:000000000000000000008gLI X-Hashcash: 1:20:130602:adam@cypherspace.org::wI+O/asC6n7WY1e4:00000000000000000 0000000000000000000000003/Qo 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: 1UjG6I-0007jX-Ut Cc: Bitcoin-Dev Subject: Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 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: Sun, 02 Jun 2013 21:46:08 -0000 So the idea is that people may want to use proof-of-work unrelated to bitcoin, and abuse bitcoin to obtain that proof, in a way denominated in BTC (and with a published USD exchange rate). And the ways they can do that are to: a) create unspendable addresses (which maybe you cant compact in the UTXO set if the unspendable address choices are not standardized) b) spend to anyone which I take it goes to a random person who happens to see the address first and race the "spend to me" out on to the network, and hope miners dnt replace it with "spend to miner", which is insecure c) doesnt delay by 100 blocks just delay the "spend to me" race? Also most likely to be one by a big miner once they adapt and join the race. d) some new standardized spend to fees (only miners can claim). e) spend to charity/non-profit of choice could be useful also f) I guess we see something related in zerocoin - locked but unlockable via another type of transaction later. g) why not instead make the beneficiary the address of the service the user is consuming that is being DoS protected by the proof-of-sacrifice? Seems more useful than burning virtual money, then it helps the bitcoin network AND it helps the service provide better service! so if I understand what you proposed d) seems like a useful concept if that is not currently possible. eg alternatively could we not just propose a standard recognized address that clearly no-one knows the EC discrete log of? Adam On Sat, Jun 01, 2013 at 03:30:36PM -0400, Peter Todd wrote: >Currently the most compact way (proof-size) to sacrifice Bitcoins that >does not involve making them unspendable is to create a anyone-can-spend >output as the last txout in the coinbase of a block: > >scriptPubKey: OP_TRUE > >The proof is then the SHA256 midstate, the txout, and the merkle path to >the block header. However this mechanism needs miner support, and it is >not possible to pay for such a sacrifice securely, or create an >assurance contract to create one. > >A anyone-can-spend in a regular txout is another option, but there is no >way to prevent a miner from including a transaction spending that txout >in the same block. Once that happens, there is no way to prove the miner >didn't create both, thus invalidating the sacrifice. The announce-commit >protocol solves that problem, but at the cost of a much larger proof, >especially if multiple parties want to get together to pay the cost of >the sacrifice. (the proof must include the entire tx used to make the >sacrifice) > >However if we add a rule where txouts ending in OP_TRUE are unspendable >for 100 blocks, similar to coinbases, we fix these problems. The rule >can be done as a soft-fork with 95% support in the same way the >blockheight rule was implemented. Along with that change >anyone-can-spend outputs should be make IsStandard() so they will be >relayed. > >The alternative is sacrifices to unspendable outputs, which is very >undesirable compared to sending the money to miners to further >strengthen the security of the network. > >We should always make it easy for people to write code that does what is >best for Bitcoin. > >-- >'peter'[:-1]@petertodd.org >00000000000000ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293 >------------------------------------------------------------------------------ >Get 100% visibility into Java/.NET code with AppDynamics Lite >It's a free troubleshooting tool designed for production >Get down to code-level detail for bottlenecks, with <2% overhead. >Download for free and get started troubleshooting in minutes. >http://p.sf.net/sfu/appdyn_d2d_ap2 >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development