diff options
author | Adam Back <adam@cypherspace.org> | 2015-02-22 08:02:03 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-02-22 08:02:10 +0000 |
commit | 4e5ab5d3d8975f1d9b45f9be368c21618ae284cd (patch) | |
tree | 60b8f08397529adbf882345ba54f373e9c7c95f5 | |
parent | 8d6b591af77206a74544e17b687d03b7f4e65109 (diff) | |
download | pi-bitcoindev-4e5ab5d3d8975f1d9b45f9be368c21618ae284cd.tar.gz pi-bitcoindev-4e5ab5d3d8975f1d9b45f9be368c21618ae284cd.zip |
[Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
-rw-r--r-- | 4c/4b32c115895f6ab6ca90d7f5c8e7f61b82cf5e | 166 |
1 files changed, 166 insertions, 0 deletions
diff --git a/4c/4b32c115895f6ab6ca90d7f5c8e7f61b82cf5e b/4c/4b32c115895f6ab6ca90d7f5c8e7f61b82cf5e new file mode 100644 index 000000000..a89de6fde --- /dev/null +++ b/4c/4b32c115895f6ab6ca90d7f5c8e7f61b82cf5e @@ -0,0 +1,166 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <adam.back@gmail.com>) id 1YPRUQ-0006GC-Mw + for bitcoin-development@lists.sourceforge.net; + Sun, 22 Feb 2015 08:02:10 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.216.171 as permitted sender) + client-ip=209.85.216.171; envelope-from=adam.back@gmail.com; + helo=mail-qc0-f171.google.com; +Received: from mail-qc0-f171.google.com ([209.85.216.171]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YPRUP-00070d-9y + for bitcoin-development@lists.sourceforge.net; + Sun, 22 Feb 2015 08:02:10 +0000 +Received: by qczc9 with SMTP id c9so7023705qcz.1 + for <bitcoin-development@lists.sourceforge.net>; + Sun, 22 Feb 2015 00:02:03 -0800 (PST) +MIME-Version: 1.0 +X-Received: by 10.140.232.5 with SMTP id d5mr12968533qhc.78.1424592123888; + Sun, 22 Feb 2015 00:02:03 -0800 (PST) +Sender: adam.back@gmail.com +Received: by 10.96.56.136 with HTTP; Sun, 22 Feb 2015 00:02:03 -0800 (PST) +Date: Sun, 22 Feb 2015 08:02:03 +0000 +X-Google-Sender-Auth: IPh6vNuE_mDn4SAXlaBqbuat8GY +Message-ID: <CALqxMTGBVdMX2RkuXNhkJ38XRM6DgAj+OmQTfHWuVF=emD-06Q@mail.gmail.com> +From: Adam Back <adam@cypherspace.org> +To: Jeff Garzik <jgarzik@bitpay.com> +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Score: -0.6 (/) +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 + 1.9 FUZZY_AMBIEN BODY: Attempt to obfuscate words in spam + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature + -0.9 AWL AWL: Adjusted score from AWL reputation of From: address +X-Headers-End: 1YPRUP-00070d-9y +Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net> +Subject: [Bitcoin-development] alternate proposal opt-in miner takes + double-spend (Re: replace-by-fee v0.10.0rc4) +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, 22 Feb 2015 08:02:11 -0000 + +I agree with Mike & Jeff. Blowing up 0-confirm transactions is vandalism. + +bitcoin transactions are all probabilistic. there is a small chance +1-confirm transactions can be reversed, and a different but also +usable chance that 0-confirm transactions can be reversed. I know +0-confirm is implemented in policy and not consensus, but it provides +fast transactions and a lot of the current ecosystem is using it for +low value transactions. why would anyone want to vandalise that. + +to echo Mike bitcoin itself kind of depends on some honest majority, +we can otherwise get to situations soon enough where its more +profitable to double-spend than mine honestly as subsidy drops and +transaction values increase even without 0-confirm transactions. +subsidy doesnt last forever (though it lasts a really long time) and +even right now if you involve values that dwarf subsidy you could make +a "criminally rational" behaviour that was more profitable. we even +saw 0-confirm odds-attacks against satoshi dice clones. but if we +assume the "criminal rational" model, its a is a race to the bottom +logic, and bitcoin is already broken if we have someone who wants to +go for it with high values. that'd be scorched earth also. + +(I read the rest of the arguments, i understood them, I disagree, no +need to repeat in reply.) + +So how about instead, to be constructive, whether you agree with the +anti-arson view or not, lets talk about solutions. Here's one idea: + +We introduce a new signature type that marks itself as can be spent by +miners if a double-spend is seen (before 1-confirm.) We'd define a +double-spend as a spend that excludes outputs to avoid affecting valid +double-spend scenarios. And we add behaviour to relay those +double-spends (at priority). We may even want the double-spend to be +serialisation incomplete but verifiable to deter back-channel payments +to pretend not to receive one, in collusion with the double-spending +party. + +Now the risk to the sender is if they accidentally double-spend. How +could they do that? By having a hardware or software crash where they +sent a tx but crashed before writing a record of having sent it. The +correct thing to do would be to transactionally write the transaction +before sending it. Still you can get a fail if the hardware +irrecoverably fails, and you have to resume from backup. Or if you +run multiple non-synced wallets on the same coins. + +Typically if you recover from backup the 1-confirmation window will +have passed so the risk is limited. + +The feature is opt-in so you dont have to put high value coins at risk +of failure. + +(Its related to the idea of a one-use signature, where two signatures +reveals a simultaneous equation that can recover the private key; +except here the miner is allowed to take the coins without needing the +private key). + +Its soft-forkable because its a new transaction type. + +ps I agree with Greg also that longer-term more scalable solutions are +interesting, but I'd like to see the core network work as a stepping +stone. As Justus observed: the scalable solutions so far have had +non-ideal ethos tradeoffs so are not drop-in upgrades to on-chain +0-confirm. + +Adam + +On 22 February 2015 at 04:06, Jeff Garzik <jgarzik@bitpay.com> wrote: +> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wro= +te: +>> On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay.com> wrote= +: +>>> This isn't some theoretical exercise. Like it or not many use +>>> insecure 0-conf transactions for rapid payments. Deploying something +>>> that makes 0-conf transactions unusable would have a wide, negative +>>> impact on present day bitcoin payments, thus "scorched earth" +> +>> And maybe by maintaining first seen policies we're harming the system +>> in the long term by encouraging people to widely deploy systems based +>> on extremely weak assumptions. +> +> Lacking a coded, reviewed alternative, that's only a platitude. +> Widely used 0-conf payments are where we're at today. Simply ceasing +> the "maintaining [of] first seen policies" alone is simply not a +> realistic option. The negative impact to today's userbase would be +> huge. +> +> Instant payments need a security upgrade, yes. +> +> -- +> Jeff Garzik +> Bitcoin core developer and open source evangelist +> BitPay, Inc. https://bitpay.com/ +> +> -------------------------------------------------------------------------= +----- +> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server +> from Actuate! Instantly Supercharge Your Business Reports and Dashboards +> with Interactivity, Sharing, Native Excel Exports, App Integration & more +> Get technology previously reserved for billion-dollar corporations, FREE +> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/ostg= +.clktrk +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development + + |