Kaz Wesley [ARCHIVE] on Nostr: 📅 Original date posted:2014-07-31 📝 Original message:On Thu, Jul 31, 2014 at ...
📅 Original date posted:2014-07-31
📝 Original message:On Thu, Jul 31, 2014 at 6:06 PM, Peter Todd <pete at petertodd.org> wrote:
> Anything that changes the semantics of nLockTime will do harm to
> existing and future applications that make use of nLockTime for things
> like refund transactions.
I think this would be compatible with most uses of nLockTime -- e.g.,
at the time a refund transaction becomes broadcastable, its
beneficiary would usually have no reason to wait for a long time
before broadcasting it; if they did so (probably because they weren't
online to redeem the refund), they'd need to use the
submit-directly-to-miner option, but they wouldn't lose their refund.
> In any case, why do transactions need finite lifespans in mempools? If
> you want to double-spend them with higher fees, then implement
> replace-by-fee.
Perpetuating transactions that have been in mempools for a long time
and are not being confirmed has been cited as a reason for nodes not
to exchange mempools (#3721, #1833, #3722); it's been implied that it
would be desirable for wallets to wait until a transaction had had a
chance to be accepted before double-spending with a higher fee
(#3722); and an unconfirmed transaction-age-based policy for
preventing mempool accumulation has been advocated (#3753, #3722) [I
hope my summarization is not misrepresenting anyone's opinions here;
please see the arguments made in the actual comments on the bugs].
These discussions are mostly fairly old, but I don't know of any
changes that have been made that provide alternative answers to these
concerns mentioned by at least three different developers.
> In any case, lifetimes will never be deterministic as not everyone runs
> the same software.
That's true, but none of the benefits of these changes require the
policy to be unanimous; most of the effect could be provided by most
of the network following these rules.
>> Transactions would stop being relayed and drop out of mempools a fixed
>> number of blocks from their creation; once that window had passed, the
>> sender's wallet could begin to expect the transaction would not be
>> confirmed. In case a reorg displaces a transaction until after its
>> expiry height, a miner can still put it back in the blockchain; the
>> expiry height is just a relay rule. Also, a user who needed to get
>> their original "expired" transaction confirmed could still do so by
>> submitting it directly to a miner with suitable policies.
>
> ...in which case someone will circumvent this IsStandard() rule by
> submitting "expired" transactions directly to miners with suitable
> policies.
Yes, that is a feature. None of the benefits of transaction expiration
rely on expiration being final, and any possible downsides of
expiration are largely mitigated by the option still being available
to get expired transactions mined.
Published at
2023-06-07 15:24:39Event JSON
{
"id": "141df1b23b92711f50f6e26ba849a29bd31548449c01d19348ab51bb3af0e435",
"pubkey": "fb86e09da2994d49831e6fa34cbe7c71aef99054c8ac90c8438c5594b4ce2f60",
"created_at": 1686151479,
"kind": 1,
"tags": [
[
"e",
"862ea3dc96b72bff70fc377e79d0d6efd56d14bf0babb9aa995ab55fc1b92d18",
"",
"root"
],
[
"e",
"4a2e2bdf403451db7d6d4d4288a2229c5c15a374735824c6327654169dcc7b0d",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2014-07-31\n📝 Original message:On Thu, Jul 31, 2014 at 6:06 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e Anything that changes the semantics of nLockTime will do harm to\n\u003e existing and future applications that make use of nLockTime for things\n\u003e like refund transactions.\n\nI think this would be compatible with most uses of nLockTime -- e.g.,\nat the time a refund transaction becomes broadcastable, its\nbeneficiary would usually have no reason to wait for a long time\nbefore broadcasting it; if they did so (probably because they weren't\nonline to redeem the refund), they'd need to use the\nsubmit-directly-to-miner option, but they wouldn't lose their refund.\n\n\u003e In any case, why do transactions need finite lifespans in mempools? If\n\u003e you want to double-spend them with higher fees, then implement\n\u003e replace-by-fee.\n\nPerpetuating transactions that have been in mempools for a long time\nand are not being confirmed has been cited as a reason for nodes not\nto exchange mempools (#3721, #1833, #3722); it's been implied that it\nwould be desirable for wallets to wait until a transaction had had a\nchance to be accepted before double-spending with a higher fee\n(#3722); and an unconfirmed transaction-age-based policy for\npreventing mempool accumulation has been advocated (#3753, #3722) [I\nhope my summarization is not misrepresenting anyone's opinions here;\nplease see the arguments made in the actual comments on the bugs].\nThese discussions are mostly fairly old, but I don't know of any\nchanges that have been made that provide alternative answers to these\nconcerns mentioned by at least three different developers.\n\n\u003e In any case, lifetimes will never be deterministic as not everyone runs\n\u003e the same software.\n\nThat's true, but none of the benefits of these changes require the\npolicy to be unanimous; most of the effect could be provided by most\nof the network following these rules.\n\n\u003e\u003e Transactions would stop being relayed and drop out of mempools a fixed\n\u003e\u003e number of blocks from their creation; once that window had passed, the\n\u003e\u003e sender's wallet could begin to expect the transaction would not be\n\u003e\u003e confirmed. In case a reorg displaces a transaction until after its\n\u003e\u003e expiry height, a miner can still put it back in the blockchain; the\n\u003e\u003e expiry height is just a relay rule. Also, a user who needed to get\n\u003e\u003e their original \"expired\" transaction confirmed could still do so by\n\u003e\u003e submitting it directly to a miner with suitable policies.\n\u003e\n\u003e ...in which case someone will circumvent this IsStandard() rule by\n\u003e submitting \"expired\" transactions directly to miners with suitable\n\u003e policies.\n\nYes, that is a feature. None of the benefits of transaction expiration\nrely on expiration being final, and any possible downsides of\nexpiration are largely mitigated by the option still being available\nto get expired transactions mined.",
"sig": "2a45496ec3d99754bb8556dbc1ed1eb9aa3ab0062be37da766473f6c2bdd70e2839ed04aaefbfc1755ce247f7f870bec0183b97a492369f2ab8caf05b5bcb4a9"
}