jl2012 at xbt.hk [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-18 📝 Original message:Btc Drak 於 2015-09-18 ...
📅 Original date posted:2015-09-18
📝 Original message:Btc Drak 於 2015-09-18 02:42 寫到:
> On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Btc Drak 於 2015-09-17 15:12 寫到:
>>
>>> Forgive me if I have missed the exact use-case, but this seems
>>> overly
>>> complex. Surely fill-or-kill refers to getting a transaction
>>> confirmed
>>> within a few confirms or to drop the tx from the mempool so it
>>> wont be
>>> considered for inclusion anymore. As such, you could just
>>> repurpose a
>>> small range of nLocktime such that a TX will be accepted into
>>> mempool
>>> for a specific period before expiring.
>>
>> What I'm describing is to implement fill-or-kill as consensus rule.
>> Certainly, we could implement it at the P2P network level:
>> everything is the same as I described, but the nLockTime2 and
>> nKillTime are for reference only and tx validity depends only on the
>> nLockTime. Benevolent miners should drop the tx after the suggested
>> kill time but there is no guarantee
>
> Sure, you can make the scheme I describe consensus based by adding the
> rule tx is not valid to mine after expiry: this still keeps the
> simplicity I described.
If you simply redefine a range of unused nLockTime as nKillTime, users
will be constrained to use either nLockTime or nKillTime, but not both
in the same tx.
If we are willing to scarify a large range of tx nVersion, say
10-15bits, the nKillTime data could be embedded there.
Another option is nSequence, which will allow per-input nKillTime and
nLockTime.
The cleanest way, of course, is a hardfork to add a new nKillTime field
to the tx so people could use nLockTime and nKillTime in parallel.
Published at
2023-06-07 17:40:46Event JSON
{
"id": "cb74bdda0317e1822952008ffac69ac33a2e750bd8172e69d756abb85114bca0",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686159646,
"kind": 1,
"tags": [
[
"e",
"d245f3cd2427d9c30e488b3eacebf2ae42b122d633366f33db323c8696dd9375",
"",
"root"
],
[
"e",
"aac6443c5e5a13fbd4e31f2a07bebb7ec67643290f94fb733183110caa1999f1",
"",
"reply"
],
[
"p",
"fdf31024ca0537ed828d895ddc8525f8af023f0dc935a8327a8a496d0d7a9f83"
]
],
"content": "📅 Original date posted:2015-09-18\n📝 Original message:Btc Drak 於 2015-09-18 02:42 寫到:\n\u003e On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e\u003e Btc Drak 於 2015-09-17 15:12 寫到:\n\u003e\u003e \n\u003e\u003e\u003e Forgive me if I have missed the exact use-case, but this seems\n\u003e\u003e\u003e overly\n\u003e\u003e\u003e complex. Surely fill-or-kill refers to getting a transaction\n\u003e\u003e\u003e confirmed\n\u003e\u003e\u003e within a few confirms or to drop the tx from the mempool so it\n\u003e\u003e\u003e wont be\n\u003e\u003e\u003e considered for inclusion anymore. As such, you could just\n\u003e\u003e\u003e repurpose a\n\u003e\u003e\u003e small range of nLocktime such that a TX will be accepted into\n\u003e\u003e\u003e mempool\n\u003e\u003e\u003e for a specific period before expiring.\n\u003e\u003e \n\u003e\u003e What I'm describing is to implement fill-or-kill as consensus rule.\n\u003e\u003e Certainly, we could implement it at the P2P network level:\n\u003e\u003e everything is the same as I described, but the nLockTime2 and\n\u003e\u003e nKillTime are for reference only and tx validity depends only on the\n\u003e\u003e nLockTime. Benevolent miners should drop the tx after the suggested\n\u003e\u003e kill time but there is no guarantee\n\u003e \n\u003e Sure, you can make the scheme I describe consensus based by adding the\n\u003e rule tx is not valid to mine after expiry: this still keeps the\n\u003e simplicity I described.\n\nIf you simply redefine a range of unused nLockTime as nKillTime, users \nwill be constrained to use either nLockTime or nKillTime, but not both \nin the same tx.\n\nIf we are willing to scarify a large range of tx nVersion, say \n10-15bits, the nKillTime data could be embedded there.\n\nAnother option is nSequence, which will allow per-input nKillTime and \nnLockTime.\n\nThe cleanest way, of course, is a hardfork to add a new nKillTime field \nto the tx so people could use nLockTime and nKillTime in parallel.",
"sig": "e55b06ca3b57a3817e41c639d72b942102412b14acbb8041db73fb63cf358607ccc3e0b2f1bf72c1b3b13401c2d77cb732e8126d2735c6bda794f75c8d0f749a"
}