[bitcoin-dev] Fill-or-kill transaction

[jl2012 at xbt.hk]

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.