Btc Drak 於 2015-09-18 02:42 寫到:
On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev
<bitcoin-dev@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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
