From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YPVkM-0005Ry-Jt for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 12:34:54 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.43 as permitted sender) client-ip=62.13.149.43; envelope-from=pete@petertodd.org; helo=outmail149043.authsmtp.co.uk; Received: from outmail149043.authsmtp.co.uk ([62.13.149.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YPVkL-0001TJ-AA for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 12:34:54 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1MCYcSO069365; Sun, 22 Feb 2015 12:34:38 GMT Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1MCYYNI061100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 22 Feb 2015 12:34:36 GMT Date: Sun, 22 Feb 2015 07:34:28 -0500 From: Peter Todd To: Adam Back Message-ID: <20150222123428.GA6570@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 29e54bd9-ba8f-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAAUHlAWAgsB AmMbWlZeU1l7WmQ7 bA9PbARUfEhLXhtr VklWR1pVCwQmRR18 dXd3LGBycQRHeH4+ ZEFqXngVXk0vcEIv FkdJRzwOM3phaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDFzog SgoEFCkiVVUfQD00 NBUiYlkEAAMQNA03 MF0sQxoEOhwfEW8W E0ZQCitUYkIZSiwn RUNgUBxWCjBFRS5X D1giM1pGDzEaRHIe XRMDEwsEV2It X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YPVkL-0001TJ-AA 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 12:34:54 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 repl= ace-by-fee scorched earth] could be to make another tx that alice and bob s= etup in advance such that if alcie doublespends, bob gets the money *and* a= lice pays a bunch of cash to miners fees 19:57 < petertodd> leakypat: this would work espectially well if we improve= d the scripting system so a script could evaluate true based on proof-of-do= ublespend 19:58 < leakypat> Yeah, proof of double spend would ideally be done at the = protocol level 19:59 < petertodd> leakypat: if satoshi hadn't make the multiple things tha= t 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 vandalism. 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... --=20 'peter'[:-1]@petertodd.org 000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8 --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJU6czPXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxN2MyZjM0NmY4MWU5Mzk1NmM1Mzg1MzE2ODJmNWFmM2E5 NWY5Yzk0Y2I3YTg0ZTgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftqRwf/Zj9DMFWWx4csiONsp3Zahf0N t2TwRYDC1oYcqRoFucTPBPoBZLU6Eo9Z5ZcVpW08m2JeC6Qe3S+PyJeHQGHpIZYJ ZPjbqCe6nvBxkf2ZLpLIrNw5cqkEYnrR0KecZgK6dKCLECT35EZnF5yCGmOpjM6F cispcjpsmunrXKpfuPAN7isFK64ZoKVANep80prI4H3Bx15DQSpCH+jNCMvrFh7a SQQjM9Ph+SJF1XV5ijbTXUIO8H7y3hGqPa9jNPb7epK7uDaXz5fwVs1x8+hRQwGt 2eqie3aNNE1RcHSKSHmuolCFicPJ9VfL7Qe2L3wpf2qanpfllEwlw1amY2FXWw== =7BwV -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5--