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 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 <bitcoin-development@lists.sourceforge.net>;
	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 <multiple recipients>
	(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 <adam@cypherspace.org>
To: Peter Todd <pete@petertodd.org>
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 <bitcoin-development@lists.sourceforge.net>
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: <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: 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: <data> 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