📅 Original date posted:2013-05-21
📝 Original message:What if a transaction is tagged as eligible for replace by fee possibly
using the lock_time (0xFFFFFFFE) so the parties involved can decide
which approach works best for them. If the receiving side doesn't see
the type of transaction they want they consider it invalid. The payment
protocol can be used to negotiate which method should be used.
If lock_time is final as it is now for all standard transactions, the
current behaviour for transaction propagation would be kept with the
addition of double spend proof notifications as I described. But if the
transactions are tagged appropriately, they would be replaced by fee.
In the recommended implementation, once a node sees a transaction that
is not eligible to be replaced by fee it would treat all successive
transactions that way despite the tag.
This shouldn't hurt merchants that wish to use just double spend
notification while still enabling replace by fee for those who think it
is preferred.
I do find the burn coins and buyer pays twice with a merchant refund to
be compelling solutions, but you can't always trust the merchant (face
to face street merchant). Also, there is a short window of time were a
block can be mined before the burn coin counter measure is received. It
is isn't guaranteed this will work better than current behaviour with
double spend notification especially considering notification don't cost
the merchant when it works.
- Quinn
Quinn Harris [ARCHIVE] /
npub18z…u3jvu
2023-06-07 15:02:21
in reply to nevent1q…muw3
Author Public Key
npub18zpfny5rg862xszvk3d4hnna037cj0dem7dpg36azurwx99wpnfquu3jvuPublished at
2023-06-07 15:02:21Event JSON
{
"id": "279a786348ef9f6e23c6cef7d7d216cf4462e00b5c9a92a81989a734effbc810",
"pubkey": "388299928341f4a3404cb45b5bce7d7c7d893db9df9a14475d1706e314ae0cd2",
"created_at": 1686150141,
"kind": 1,
"tags": [
[
"e",
"e2b0d4c9e9ef91bcdbcf2583000e9ebb8fa15ef27e8a01c38f0772dbda8190a9",
"",
"root"
],
[
"e",
"a0c74c931f7524cf092e77cdd6eb1483710efbbde5abb1147405d61d642c7c46",
"",
"reply"
],
[
"p",
"adcb53cdbd72e2a0c22452a9087f173c6b55edc7b504ff9b861e9c02af9a87d4"
]
],
"content": "📅 Original date posted:2013-05-21\n📝 Original message:What if a transaction is tagged as eligible for replace by fee possibly \nusing the lock_time (0xFFFFFFFE) so the parties involved can decide \nwhich approach works best for them. If the receiving side doesn't see \nthe type of transaction they want they consider it invalid. The payment \nprotocol can be used to negotiate which method should be used.\n\nIf lock_time is final as it is now for all standard transactions, the \ncurrent behaviour for transaction propagation would be kept with the \naddition of double spend proof notifications as I described. But if the \ntransactions are tagged appropriately, they would be replaced by fee.\n\nIn the recommended implementation, once a node sees a transaction that \nis not eligible to be replaced by fee it would treat all successive \ntransactions that way despite the tag.\n\nThis shouldn't hurt merchants that wish to use just double spend \nnotification while still enabling replace by fee for those who think it \nis preferred.\n\nI do find the burn coins and buyer pays twice with a merchant refund to \nbe compelling solutions, but you can't always trust the merchant (face \nto face street merchant). Also, there is a short window of time were a \nblock can be mined before the burn coin counter measure is received. It \nis isn't guaranteed this will work better than current behaviour with \ndouble spend notification especially considering notification don't cost \nthe merchant when it works.\n\n- Quinn",
"sig": "ed7d07b3cee673e95112e07a6baa23af2c77ee762c77c9f2c2e755f6bd0de31e8c4838e25163f2a85d33d8da515ea15ab00f29267f340337f2a5d3cefdd2ade3"
}