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 > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
