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 39906305 for ; Tue, 30 Jun 2015 13:12:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96E8CFB for ; Tue, 30 Jun 2015 13:12:54 +0000 (UTC) Received: from mail-qg0-f46.google.com ([209.85.192.46]) by mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id 0MKKIa-1ZATJ521w6-001f9Y for ; Tue, 30 Jun 2015 15:12:53 +0200 Received: by qgii30 with SMTP id i30so3464200qgi.1 for ; Tue, 30 Jun 2015 06:12:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.27.70 with SMTP id b67mr43010609qkb.86.1435669972796; Tue, 30 Jun 2015 06:12:52 -0700 (PDT) Received: by 10.96.28.39 with HTTP; Tue, 30 Jun 2015 06:12:52 -0700 (PDT) In-Reply-To: <20150630013736.GA11508@savin.petertodd.org> References: <20150629050726.GA502@savin.petertodd.org> <5591E10F.9000008@thinlink.com> <20150630013736.GA11508@savin.petertodd.org> Date: Tue, 30 Jun 2015 15:12:52 +0200 Message-ID: From: Adam Back To: Peter Todd Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:RWlgehahXpK3FxZk/GW+bmj4Ql2Gr3LMgEBILeCcf84QUljUx06 I9d/wQVpFhc3hca7kzLsILUSddfPOlA9S7L5+5iNHxu6hsdgyBWx7nnvXAccUvOQjQQK3E3 H0Lq4fsnUi5z2gPXLpeoywk+X8X3wGiZwTTeYTSoAAvyfLtaPkjloC2zA6drGkDF7Mcj+gH FLVbHVjysd3mEm83Cllzg== X-UI-Out-Filterresults: notjunk:1;V01:K0:dAaURWaVlvA=:Gqid7DfsMql0ARYg49E5d5 +ZXWQ52uehROtFi4XRLnD3rJAXf20M6k3SygesARsnUPL6ZIR4dOgxTjiWsjUDIrmjhhLLY5u oYbabKrx6rzKd5s5EkSq6hz67jb0V8JG3m1Bbdo5BUxjK6G1FZq8mPzKAmbZLAMDTQUnRxapw kcxIRkbxRjzlkGtE8dmQgHWUri2QkV0fJ52tfoA+L7urEucaGaZfmQuPK31VN06H6FTdmu4He 6nYHUR17VMY0jXDTzqYPsxh+kzRhktiZft/CDp4m8rtZTYnTtv2yzttCkyffMrrhYjJ0GSBZR TeD0nZCmn4bRXiaf5O6ayNPEcgl4K3k4nMragK5iuBM4h75vjIOQepM+oXeG9pDSfM0S2GRc8 yACQpnLPPYsxSluvu4xEb+dfVOgJzS4Edy31U4ha3GvuNVsSOGpCsvZqGdHj7xuIx2IWW1VO6 gohLptbt8L79I5yZADKazPnparljmQIe2Iy2j5LROVQH6cYf7vSd/QxL4Xb1fRPgYif85KqRO Nxg9oypPs5BDxEvj7T2PuKnQppXYMtNhi6vIoQpIOBBeWzAITpJ3uhHrgtpPMelzEMF/BXxri LF2NozMLX+P5UL9icz8EbuaknOe6SjcZDsSNAWiKclOvhH2wPC7QvWs3tX09tHLl7/b5/tc3D VPqVzMfstv6gFOq2YeGwxQm2qyPX/wxFeKGO6uu2d1qU5nw== X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE 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 13:12:55 -0000 It is correct to view first-seen miner and relay policy as honour-based, though it is the current default. 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. 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. 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. 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. 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. Any thoughts on the simplest way to support an opt-in version of full-RBF? Adam On 30 June 2015 at 03:37, Peter Todd wrote: > On Mon, Jun 29, 2015 at 05:21:35PM -0700, Tom Harding wrote: >> On 6/28/2015 10:07 PM, Peter Todd wrote: >> >Worryingly large payment providers have shown >> >willingness(4) to consider extreme measures such as entering into legal >> >contracts directly with large miners to ensure their transactions get mined. >> >This is a significant centralization risk and it is not practical or even >> >possible for small miners to enter into these contracts, leading to a situation >> >where moving your hashing power to a larger pool will result in higher profits >> >from hashing power contracts; if these payment providers secure a majority of >> >hashing power with these contracts inevitably there will be a temptation to >> >kick non-compliant miners off the network entirely with a 51% attack. >> > >> >> Your incomprehensible meddling with successful usage patterns >> threatens to have unintended consequences directly in opposition to >> your own stated goal of decentralization. And yet you persist. >> >> As we deliberately break things and turn the P2P network into a >> completely unpredictable hodge-podge of relay policies, we should >> expect many more participants to bypass the P2P network entirely. >> >> Many of the pieces are already in place. >> >> If we wanted the P2P network to have more predicable behavior, it >> would be possible for nodes to provide incentives to their >> neighbors. For example, if you had a pair of nodes, you could test >> your peers to see that they actually do relay "standard" >> transactions. This would have emergent usability benefits for the >> P2P network as a whole. > > To be clear, full-RBF is a change that broadens what the P2P network > relays - transactions previously not relayed are now relayed. Under no > circumstance will full-RBF result in transactions *not* being relayed > that previously were relayed. This makes the P2P network more useful > rather than less, as it gives a predictable and uniform method to get > transactions to a wider variety of miners with a wider variety of > policies. > > Note how even if no miners ever supported full-RBF, supporting full-RBF > on relay nodes would still be useful to users as it provides an easy and > cost-effective mechanism to rebroadcast transactions. In fact, > supporting full-RBF by default and disabling it if getblocktemplate is > called would be reasonable, if more than a bit of a hack! > > In any case, my pull-req lets you set -fullrbfactivationtime=0 as a > simple and easy way to disable full-RBF functionality. Miners and relay > nodes who choose not to support it can easily do so, similar to how > OP_RETURN transactions can be disabled with -datacarrier=0 > > -- > 'peter'[:-1]@petertodd.org > 00000000000000000bfe93181a10e2f12a45da877b5026ae26988e936a1322ae > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >