<oembed><type>rich</type><version>1.0</version><author_name>npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_name><author_url>https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2013-06-02&#xA;📝 Original message:On Sat, Jun 01, 2013 at 10:32:07PM -0400, Gavin wrote:&#xA;&gt; Feels like a new opcode might be better.&#xA;&gt; &#xA;&gt; Eg  &lt;data&gt; 100 OP_NOP1&#xA;&gt; &#xA;&gt; ... Where op_nop1 is redefined to be &#39;verify depth&#39; ... &#xA;&#xA;Good idea.&#xA;&#xA;Either way, looks like complex announce-commit logic isn&#39;t needed and a&#xA;simple txout with one of a few possible forms will work.&#xA;&#xA;I&#39;d say we tell people to sacrifice to (provably) unspendable for now&#xA;and do a soft-fork later if there is real demand for this stuff in the&#xA;future.&#xA;&#xA;&gt; On Jun 1, 2013, at 3:30 PM, Peter Todd &lt;pete at petertodd.org&gt; wrote:&#xA;&gt; &#xA;&gt; &gt; Currently the most compact way (proof-size) to sacrifice Bitcoins that&#xA;&gt; &gt; does not involve making them unspendable is to create a anyone-can-spend&#xA;&gt; &gt; output as the last txout in the coinbase of a block:&#xA;&gt; &gt; &#xA;&gt; &gt; scriptPubKey: &lt;data&gt; OP_TRUE&#xA;&gt; &gt; &#xA;&gt; &gt; The proof is then the SHA256 midstate, the txout, and the merkle path to&#xA;&gt; &gt; the block header. However this mechanism needs miner support, and it is&#xA;&gt; &gt; not possible to pay for such a sacrifice securely, or create an&#xA;&gt; &gt; assurance contract to create one.&#xA;&gt; &gt; &#xA;&gt; &gt; A anyone-can-spend in a regular txout is another option, but there is no&#xA;&gt; &gt; way to prevent a miner from including a transaction spending that txout&#xA;&gt; &gt; in the same block. Once that happens, there is no way to prove the miner&#xA;&gt; &gt; didn&#39;t create both, thus invalidating the sacrifice. The announce-commit&#xA;&gt; &gt; protocol solves that problem, but at the cost of a much larger proof,&#xA;&gt; &gt; especially if multiple parties want to get together to pay the cost of&#xA;&gt; &gt; the sacrifice. (the proof must include the entire tx used to make the&#xA;&gt; &gt; sacrifice)&#xA;&gt; &gt; &#xA;&gt; &gt; However if we add a rule where txouts ending in OP_TRUE are unspendable&#xA;&gt; &gt; for 100 blocks, similar to coinbases, we fix these problems. The rule&#xA;&gt; &gt; can be done as a soft-fork with 95% support in the same way the&#xA;&gt; &gt; blockheight rule was implemented. Along with that change&#xA;&gt; &gt; anyone-can-spend outputs should be make IsStandard() so they will be&#xA;&gt; &gt; relayed.&#xA;&gt; &gt; &#xA;&gt; &gt; The alternative is sacrifices to unspendable outputs, which is very&#xA;&gt; &gt; undesirable compared to sending the money to miners to further&#xA;&gt; &gt; strengthen the security of the network.&#xA;&gt; &gt; &#xA;&gt; &gt; We should always make it easy for people to write code that does what is&#xA;&gt; &gt; best for Bitcoin.&#xA;&#xA;-- &#xA;&#39;peter&#39;[:-1]@petertodd.org&#xA;0000000000000092f448c7630e47584650efa7e27604161c0b5984d603d944ea&#xA;-------------- next part --------------&#xA;A non-text attachment was scrubbed...&#xA;Name: signature.asc&#xA;Type: application/pgp-signature&#xA;Size: 490 bytes&#xA;Desc: Digital signature&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130602/e4620fb3/attachment.sig&gt;</html></oembed>