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 B28699EE for ; Tue, 4 Jul 2017 11:50:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from blaine.gmane.org (unknown [195.159.176.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0A98EA0 for ; Tue, 4 Jul 2017 11:50:38 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dSMLe-0005dp-UU for bitcoin-dev@lists.linuxfoundation.org; Tue, 04 Jul 2017 13:50:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-dev@lists.linuxfoundation.org From: Andreas Schildbach Date: Tue, 4 Jul 2017 13:50:30 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 In-Reply-To: Content-Language: en-US X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, RDNS_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 11:50:39 -0000 Your BIP would take away the only way the *receiver* has to raise the fee: CPFP. And the receiver is arguably the more important party in this question. After all the sender has no real incentive for his payment to be confirmed; it's receiver who has. On 07/02/2017 10:35 PM, Rhavar via bitcoin-dev wrote: > ==Abstract== > > BIP125 allows transactions to opt into replaceability with a primary use > case > of allowing users to increase the fees of unconfirming transactions, > helping create > a more efficient fee market place. > > However this goal is hindered when the receiver of a transaction spends > from the > unconfirmed output, which exposes the sender to the awkward position of > needing > to pick between needing to pay an effectively unbounded amount of money > as per the BIP125 rules, or not fee bump at all. > > This is especially problematic in the case of batched sends in which > there are > multiple independent receivers. In practice this means wallets and > services can not effectively low ball the fee of transactions, with the > intention of fee bumping due to the risk of the receiver spending or > sweeping it before it confirms. > > In order to support a healthy fee marketplace, this proposal aims to > increase > the utility of bip125 by making transactions that spend an unconfirmed > BIP125 > output non-standard. > > > ==Summary== > > This policy specifies a max chain depth of 1 for any BIP125 transactions. > > ==Impact== > > Receivers of BIP125 transactions will need to wait until the transaction > has confirmed before spending from it. This will not be significantly > different > than it is currently as they receivers need to be monitoring for > replacements. > > If senders want to make further transactions before the BIP125 > transaction confirms, > and need to utilize the change of the transaction: they will need to > replace the > transaction with a one that makes the other send in "pass through" style > or first > finalize the BIP125 transaction and then chain from the spend normally. > > > -Ryan > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >