From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: From: Adam Back To: Jeff Garzik 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On Sat, Feb 21, 2015 at 10:25 PM, Jorge Tim=C3=B3n wro= te: >> On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik 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