MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 18 Sep 2015 05:12:27 -0400
From: jl2012@xbt.hk
To: Btc Drak <btcdrak@gmail.com>
In-Reply-To: <CADJgMzupLGVKfHnkAwJYUeAe-XHKtc0o7d8G3-2N1Ls5orfS=Q@mail.gmail.com>
References: <a50b82c156c805a284386d80a42cc926@xbt.hk>
	<CAOG=w-vGqsAcw5vdY8SaGVe4Q6XX1J=GCsZftWgjES_N_5c2pA@mail.gmail.com>
	<CABm2gDp_afyqskEV8QmO43=-6R_2OJm36GVQxcQO_3ao2jC1gw@mail.gmail.com>
	<C9A1D16E-03F7-4860-8E9B-32A98E06CE49@petertodd.org>
	<014345a983eabf243d9ce127de0dff7c@xbt.hk>
	<CADJgMzupLGVKfHnkAwJYUeAe-XHKtc0o7d8G3-2N1Ls5orfS=Q@mail.gmail.com>
Message-ID: <bc31c9283aa0ae5a1bcb6dedaff8b23d@xbt.hk>
User-Agent: Roundcube Webmail/1.0.5
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fill-or-kill transaction
Precedence: list

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.