summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAdam Back <adam@cypherspace.org>2015-02-22 08:02:03 +0000
committerbitcoindev <bitcoindev@gnusha.org>2015-02-22 08:02:10 +0000
commit4e5ab5d3d8975f1d9b45f9be368c21618ae284cd (patch)
tree60b8f08397529adbf882345ba54f373e9c7c95f5
parent8d6b591af77206a74544e17b687d03b7f4e65109 (diff)
downloadpi-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/4b32c115895f6ab6ca90d7f5c8e7f61b82cf5e166
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
+
+