diff options
| author | Adam Back <adam@cypherspace.org> | 2013-06-02 23:45:54 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-06-02 21:46:08 +0000 |
| commit | 25b3016256a6367dfc0dd6b0ed62ebf9823e15bd (patch) | |
| tree | 47e17ad6b3899b228ed7d495bf4f7a5b2d1e3f73 | |
| parent | 292b499268608c14c925f0e7a0ffa407c85803a1 (diff) | |
| download | pi-bitcoindev-25b3016256a6367dfc0dd6b0ed62ebf9823e15bd.tar.gz pi-bitcoindev-25b3016256a6367dfc0dd6b0ed62ebf9823e15bd.zip | |
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
| -rw-r--r-- | fe/6e2303ff7f28213dee1cf03cbd99757456cd32 | 171 |
1 files changed, 171 insertions, 0 deletions
diff --git a/fe/6e2303ff7f28213dee1cf03cbd99757456cd32 b/fe/6e2303ff7f28213dee1cf03cbd99757456cd32 new file mode 100644 index 000000000..25eb38216 --- /dev/null +++ b/fe/6e2303ff7f28213dee1cf03cbd99757456cd32 @@ -0,0 +1,171 @@ +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 + + + |