<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 1 June 2013 21:30, Peter Todd <span dir="ltr">&lt;<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently the most compact way (proof-size) to sacrifice Bitcoins that<br>
does not involve making them unspendable is to create a anyone-can-spend<br>
output as the last txout in the coinbase of a block:<br>
<br>
scriptPubKey: &lt;data&gt; OP_TRUE<br>
<br>
The proof is then the SHA256 midstate, the txout, and the merkle path to<br>
the block header. However this mechanism needs miner support, and it is<br>
not possible to pay for such a sacrifice securely, or create an<br>
assurance contract to create one.<br></blockquote><div><br></div><div>Sorry if this is a stupid question, but why would someone want to sacrifice their bitcoins?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
A anyone-can-spend in a regular txout is another option, but there is no<br>
way to prevent a miner from including a transaction spending that txout<br>
in the same block. Once that happens, there is no way to prove the miner<br>
didn&#39;t create both, thus invalidating the sacrifice. The announce-commit<br>
protocol solves that problem, but at the cost of a much larger proof,<br>
especially if multiple parties want to get together to pay the cost of<br>
the sacrifice. (the proof must include the entire tx used to make the<br>
sacrifice)<br>
<br>
However if we add a rule where txouts ending in OP_TRUE are unspendable<br>
for 100 blocks, similar to coinbases, we fix these problems. The rule<br>
can be done as a soft-fork with 95% support in the same way the<br>
blockheight rule was implemented. Along with that change<br>
anyone-can-spend outputs should be make IsStandard() so they will be<br>
relayed.<br>
<br>
The alternative is sacrifices to unspendable outputs, which is very<br>
undesirable compared to sending the money to miners to further<br>
strengthen the security of the network.<br>
<br>
We should always make it easy for people to write code that does what is<br>
best for Bitcoin.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
&#39;peter&#39;[:-1]@<a href="http://petertodd.org" target="_blank">petertodd.org</a><br>
00000000000000ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293<br>
</font></span><br>------------------------------------------------------------------------------<br>
Get 100% visibility into Java/.NET code with AppDynamics Lite<br>
It&#39;s a free troubleshooting tool designed for production<br>
Get down to code-level detail for bottlenecks, with &lt;2% overhead.<br>
Download for free and get started troubleshooting in minutes.<br>
<a href="http://p.sf.net/sfu/appdyn_d2d_ap2" target="_blank">http://p.sf.net/sfu/appdyn_d2d_ap2</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br></div></div>