📅 Original date posted:2017-07-02
📝 Original message: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
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 18:03:49
in reply to nevent1q…6kyr
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:03:49Event JSON
{
"id": "76c9c9ca8080a8a382b4f49a5e121ebb2f14f723e82ba1341ba80305030a91bf",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686161029,
"kind": 1,
"tags": [
[
"e",
"6ae908cbd0a9f12abff6467fd3d89eab09bcc74de9ac35cd83e3048488dcab93",
"",
"root"
],
[
"e",
"fe4e8a56c453cd7fd163a210cff048aa7b3b60af77ab7f91ad269637d4910d3a",
"",
"reply"
],
[
"p",
"0edd50f962d40f6d28430b426c163d97f61365f07c64af51b8de33261ddd108a"
]
],
"content": "📅 Original date posted:2017-07-02\n📝 Original message:This isn't BIP material, as it merely describes a local policy.\n\n(BIP125 itself is also local policy, but one that involves standardisation \nsince it expresses how wallets interoperate with nodes with that policy.)\n\nIf you wish to suggest this policy change, you should just implement it and \nopen a merge/pull request on the applicable project.\n\nLuke\n\n\nOn Sunday 02 July 2017 8:35:22 PM Rhavar via bitcoin-dev wrote:\n\u003e ==Abstract==\n\u003e BIP125 allows transactions to opt into replaceability with a primary use\n\u003e case of allowing users to increase the fees of unconfirming transactions,\n\u003e helping create a more efficient fee market place.\n\u003e However this goal is hindered when the receiver of a transaction spends\n\u003e from the unconfirmed output, which exposes the sender to the awkward\n\u003e position of needing to pick between needing to pay an effectively\n\u003e unbounded amount of money as per the BIP125 rules, or not fee bump at all.\n\u003e This is especially problematic in the case of batched sends in which there\n\u003e are multiple independent receivers. In practice this means wallets and\n\u003e services can not effectively low ball the fee of transactions, with the\n\u003e intention of fee bumping due to the risk of the receiver spending or\n\u003e sweeping it before it confirms. In order to support a healthy fee\n\u003e marketplace, this proposal aims to increase the utility of bip125 by\n\u003e making transactions that spend an unconfirmed BIP125 output non-standard.\n\u003e ==Summary==\n\u003e This policy specifies a max chain depth of 1 for any BIP125 transactions.\n\u003e ==Impact==\n\u003e Receivers of BIP125 transactions will need to wait until the transaction\n\u003e has confirmed before spending from it. This will not be significantly\n\u003e different than it is currently as they receivers need to be monitoring for\n\u003e replacements. If senders want to make further transactions before the\n\u003e BIP125 transaction confirms, and need to utilize the change of the\n\u003e transaction: they will need to replace the transaction with a one that\n\u003e makes the other send in \"pass through\" style or first finalize the BIP125\n\u003e transaction and then chain from the spend normally.\n\u003e \n\u003e -Ryan",
"sig": "c97e6c0a5b2f8372e9587e75c0c837bf49ea2bbdc7cfe499089587d1871c0f8b24e1a2c4bdb1f8bd6b2c08f28d91e796bd3895aa5b68bb824f7ba8f6ab88bf4e"
}