From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4795EAC2 for ; Tue, 30 Jun 2015 16:05:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149055.authsmtp.co.uk (outmail149055.authsmtp.co.uk [62.13.149.55]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 45689118 for ; Tue, 30 Jun 2015 16:05:34 +0000 (UTC) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5UG5UI7098763; Tue, 30 Jun 2015 17:05:30 +0100 (BST) 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 t5UG5OpZ025950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 Jun 2015 17:05:26 +0100 (BST) Date: Tue, 30 Jun 2015 12:05:24 -0400 From: Peter Todd To: Adam Back Message-ID: <20150630160523.GG17984@savin.petertodd.org> References: <20150629050726.GA502@savin.petertodd.org> <5591E10F.9000008@thinlink.com> <20150630013736.GA11508@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Zrag5V6pnZGjLKiw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: d2cf2722-1f41-11e5-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdQIUEkAaAgsB AmMbWlNeUFh7W2Q7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRlk cRthEnNydQBPfX4+ Z0JjXnAVCEYpI0R6 QExJFDsCZHphaTUa TUkOcAdJcANIexZF O1F8UScOLwdSbGoL FQ4vNDcwO3BTJTpg CissFQBab1sPGnYG SggGFD4iWEcUAgs+ IlQqJ0YYG1cUP0Mu eUAqWV8ULhsfYgAA X-Authentic-SMTP: 61633532353630.1024: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-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 16:05:35 -0000 --Zrag5V6pnZGjLKiw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2015 at 03:12:52PM +0200, Adam Back wrote: > It is correct to view first-seen miner and relay policy as > honour-based, though it is the current default. >=20 > I think it would be better to deploy full-RBF in an opt-in way and > leave the current default miner & relay policies as is. So for > example a new signature flag or transaction type that is marked as > opting-in waiving the first-seen policy. >=20 > In this way we can get a smoother transition for people away from the > first-seen assumption, towards greenaddress (trust based) and > lightning / payment channel solutions. Mid-term the channel and hub > model can provide fast secure 0-confirm transactions, which are > generically not known to be directly and robustly securable via miner > consensus. >=20 > As we've seen abruptly stopping the first-seen miner & relay policy is > risky and unpopular and causes people to seek contracts with miners to > retain first-seen. This is itself a bad trend for fungibility for > obvious reasons. Well, as you know I have good reason to believe those contracts are being actively worked on right now. I've been talking about this issue for something like two years now, and rather than seeing a shift away =66rom use of zeroconf, we're seeing new services adopting it, always large, centralized, startups in the payment space. Meanwhile the story for decentralized wallets is if anything even worse, and most such wallets don't even have code to detect double-spends at all. =46rom the point of view of large companies like Coinbase, getting hashing power contracts and sybil attacking the network is relatively easy. Why would they invest in genuine improvements when they can take the easy way out? Especially when the easy way is something their smaller competitors simply have no access too? Working on those contracts now only makes sense, especially as the reliability of the P2P network in providing zeroconf guarantees continues to decline as transaction volume increases, and uniformity of nodes decreases. By acting sooner rather than later in adopting full-RBF I think we have a shot at changing the direction of the industry; if we wait I think we stand a real chance of that dangerous infrastructure being put into place. Equally, when you ask who is benefiting from the status quo, it isn't decentralized wallets, but a small number of centralized startups who have an advantage that the former can't match. > We shouldn't prejudge people's and segment's of business weak-reliance > on first-seen. Some types of payments are generally high trust (known > relationships) or physical stores or very low marginal cost (coffee > marginal cost <10c, sale price > $2 or lower ebook, audio stream etc > as embodied by fremium model). It is not ours to prejudge and kill > their business. It our job to help improve network security however, > so that they do not have to eat a fraud cost. And that is do able > with trust via greenaddress, or without trust (other than > time-preference) via the hub & channel model. You know, if the status quo didn't have the downsides I mention above, I'd probably agree with you on that point. But the risks outweigh it IMO. > Security maybe incrementally improvable via non-spendable relaying of > proof of double-spent status, and services that try to measure % of > miners by hashrate with assumption of first-seen that have have seen a > given transaction first, though I am not sure such approaches are > robust enough to invest time in vs greenaddress or hub & channel. Note how relaying proof of double-spent status is only useful if you can do something about it; the only method available without a scripting language soft-fork is the scorched earth concept, which ironically relies on full-RBF. > Any thoughts on the simplest way to support an opt-in version of full-RBF? I'd suggest using nSequence for that purpose by defining non-maxint nSequence as allowing RBF. (as well as non-maxint - 1 for nLockTime usage to discourage fee sniping) Mark Friedenbach's sequence number BIP is going to make use of transaction replacement anyway after all, so doing that would be forward-compatible with it. --=20 'peter'[:-1]@petertodd.org 0000000000000000129dec64f63611dc737b87331bb165740fb5552a92833a12 --Zrag5V6pnZGjLKiw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVkr5AXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNmY5MGVhZmI3MTExZjRjYWVhMWY3OTJmZTUzNWZkYzFj MjI1MWJjNDUxNDc4N2MvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftYiggAs9iqm/BOETt6H+AzCaMbPUby oWJeXHrGw6YcoQj5b5kROb2DeNuJJlEE+SsfgqwLjqUL2t0b4hXha0Kd7Dhc+Ux2 VsDi/++XMJkUgYoi3qAjzWIM9RtyMxeI93jVW1MF3ibcEgIpUMEAIljf0Dv8TzCM rbEsKPp0OsrignWoBJwPdIBv0LF0JwLnD9XsfY2vRgX4a6fCds1CLKNzDtfm+MYs S6p3KGSuDorAgQ3OdVeAWOzm/JSok3fHv9G9DlEZFXwcu1HXMJ8EEWTF0mOY+M8Q ua44aH6JEsTRxMEzSgodPMOjgOrIvcl+hO8XXTXOpKQACUky6xio1nKgX/XyDw== =PfJE -----END PGP SIGNATURE----- --Zrag5V6pnZGjLKiw--