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.
📝 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.