MIME-Version: 1.0
In-Reply-To: <014345a983eabf243d9ce127de0dff7c@xbt.hk>
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>
From: Btc Drak <btcdrak@gmail.com>
Date: Fri, 18 Sep 2015 07:42:42 +0100
Message-ID: <CADJgMzupLGVKfHnkAwJYUeAe-XHKtc0o7d8G3-2N1Ls5orfS=Q@mail.gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=047d7ba98212d64b66051fffd757
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fill-or-kill transaction
Precedence: list

--047d7ba98212d64b66051fffd757
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Btc Drak =E6=96=BC 2015-09-17 15:12 =E5=AF=AB=E5=88=B0:
>
>> 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 referen=
ce
> only and tx validity depends only on the nLockTime. Benevolent miners
> should drop the tx after the suggested kill time but there is no guarante=
e
>

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.

--047d7ba98212d64b66051fffd757
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev <span dir=3D"ltr">&lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">Btc Drak =E6=96=BC 2015-09-17 15:12 =E5=AF=AB=E5=88=B0:<s=
pan class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Forgive me if I have missed the exact use-case, but this seems overly<br>
complex. Surely fill-or-kill refers to getting a transaction confirmed<br>
within a few confirms or to drop the tx from the mempool so it wont be<br>
considered for inclusion anymore. As such, you could just repurpose a<br>
small range of nLocktime such that a TX will be accepted into mempool<br>
for a specific period before expiring.<br>
</blockquote>
<br></span>
What I&#39;m describing is to implement fill-or-kill as consensus rule. Cer=
tainly, we could implement it at the P2P network level: everything is the s=
ame as I described, but the nLockTime2 and nKillTime are for reference only=
 and tx validity depends only on the nLockTime. Benevolent miners should dr=
op the tx after the suggested kill time but there is no guarantee<br></bloc=
kquote><div><br></div><div>Sure, you can make the scheme I describe consens=
us based by adding the rule tx is not valid to mine after expiry: this stil=
l keeps the simplicity I described.</div></div></div></div>

--047d7ba98212d64b66051fffd757--