Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions

[Luke Dashjr <luke@dashjr.org>]

This isn't BIP material, as it merely describes a local policy.

(BIP125 itself is also local policy, but one that involves standardisation 
since it expresses how wallets interoperate with nodes with that policy.)

If you wish to suggest this policy change, you should just implement it and 
open a merge/pull request on the applicable project.

Luke


On Sunday 02 July 2017 8:35:22 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