From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YPXFy-0007cU-WD for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 14:11:39 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.41 as permitted sender) client-ip=209.85.192.41; envelope-from=adam.back@gmail.com; helo=mail-qg0-f41.google.com; Received: from mail-qg0-f41.google.com ([209.85.192.41]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YPXFw-0004JJ-Tb for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 14:11:38 +0000 Received: by mail-qg0-f41.google.com with SMTP id i50so20887873qgf.0 for ; Sun, 22 Feb 2015 06:11:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.229.25.200 with SMTP id a8mr15426198qcc.22.1424614291471; Sun, 22 Feb 2015 06:11:31 -0800 (PST) Sender: adam.back@gmail.com Received: by 10.96.56.136 with HTTP; Sun, 22 Feb 2015 06:11:31 -0800 (PST) In-Reply-To: <20150222123428.GA6570@savin.petertodd.org> References: <20150222123428.GA6570@savin.petertodd.org> Date: Sun, 22 Feb 2015 14:11:31 +0000 X-Google-Sender-Auth: 7AunybWXiLaIjHcZfGZ24F6_hVM Message-ID: From: Adam Back To: Peter Todd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.4 (-) 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 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.1 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YPXFw-0004JJ-Tb Cc: Bitcoin Development Subject: Re: [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 14:11:39 -0000 My actual point outside of the emotive stuff (and I should've stayed away from that too) is how about we explore ways to improve practical security of fast confirmation transactions, and if we find something better, then we can help people migrate to that before deprecating the current weaker 0-conf transactions. If I understand this is also your own motivation. Feel free to comment on or improve the proposal or find other approaches. Adam On 22 February 2015 at 12:34, Peter Todd wrote: > On Sun, Feb 22, 2015 at 08:02:03AM +0000, Adam Back wrote: > > FWIW I've been advocating this kind of thing in various forms for > literally years, including to hold fidelity bonded banks honest - what > you now call 'federated sidechains' - and most recently Feb 12th on > #bitcoin-dev: > > 19:56 < petertodd> leakypat: now, do note that an advanced version [of re= place-by-fee scorched earth] could be to make another tx that alice and bob= setup in advance such that if alcie doublespends, bob gets the money *and*= alice pays a bunch of cash to miners fees > 19:57 < petertodd> leakypat: this would work espectially well if we impro= ved the scripting system so a script could evaluate true based on proof-of-= doublespend > 19:58 < leakypat> Yeah, proof of double spend would ideally be done at th= e protocol level > 19:59 < petertodd> leakypat: if satoshi hadn't make the multiple things t= hat CHECKSIG does into one opcode it'd be really easy, but alas... > > Implementing it as a general purpose scripting language improvement has > a lot of advantages, not least of which is that you no longer need to > rely entirely on inherently unreliable P2P networking: Promise to never > create two signatures for a specific BIP32 root pubkey and make > violating that promise destroy and/or reallocate a fidelity bond whose > value is locked until some time into the future. Since the fidelity bond > is a separate pool of funds, detection of the double-spend can happen > later. > > Equally, that *is* what replace-by-fee scorched-earth does without the > need for a soft-fork, minus the cryptographic proof and with a bit less > flexibility. > >> I agree with Mike & Jeff. Blowing up 0-confirm transactions is vandalis= m. > > Is releasing a version of Bitcoin Core with different IsStandard() rules > than the previous version vandalism? Is mining with a different policy > than other people vandalism? Is mining at a pool that gets sybil > attacked vandalism? Are my replace-by-fee tools an act of vandalism? > Because every one of those things causes people to get double-spent in > the real world, even losing tens of thousands of dollars until they get > some sense and stop treating unconfirmed transactions as confirmed. > > Is it vandalism if you decide to host a wedding right next to a hairpin > corner at a rally race and complain to me that mud is getting on the > pretty white dresses? Is it vandalism if I tell that wedding party to > fuck off before someone gets hurt? Is it vandalism if some racers take > the mudguards off for a few laps to see if we can encourage them to > leave before someone gets *actually* hurt? Or someone decides that the > solution is to pave the track over and hold a bicycle race instead... > > -- > 'peter'[:-1]@petertodd.org > 000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8