MIME-Version: 1.0
In-Reply-To: <CAOG=w-vGqsAcw5vdY8SaGVe4Q6XX1J=GCsZftWgjES_N_5c2pA@mail.gmail.com>
References: <a50b82c156c805a284386d80a42cc926@xbt.hk>
	<CAOG=w-vGqsAcw5vdY8SaGVe4Q6XX1J=GCsZftWgjES_N_5c2pA@mail.gmail.com>
Date: Thu, 17 Sep 2015 21:14:38 +0200
Message-ID: <CABm2gDp_afyqskEV8QmO43=-6R_2OJm36GVQxcQO_3ao2jC1gw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Mark <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=089e0141aa1afcd58d051ff639b4
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fill-or-kill transaction
Precedence: list

--089e0141aa1afcd58d051ff639b4
Content-Type: text/plain; charset=UTF-8

Fill or kill us normally used for trades and I think it can be confusing.
Previous times this has been discussed it has been discussed under
nExpiryTime or op_height (which enables expiration), for example, in the
freimarkets white paper.

As Mark points out this can be made safe by requiring that all the outputs
of a transaction that can expire have op_maturity/csv/rcltv of 100. That
makes them as reorg-safe as coinbase transactions. Unfortunately this
doesn't play very well with p2sh...
On Sep 17, 2015 3:08 PM, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Note that this violates present assumptions about transaction validity,
> unless a constraint also exists that any output of such an expiry block is
> not spent for at least 100 blocks.
>
> Do you have a clean way of ensuring this?
>
> On Thu, Sep 17, 2015 at 2:41 PM, jl2012 via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Fill-or-kill tx is not a new idea and is discussed in the Scaling Bitcoin
>> workshop. In Satoshi's implementation of nLockTime, a huge range of
>> timestamp (from 1970 to 2009) is wasted. By exploiting this unused range
>> and with compromise in the time resolution, a fill-or-kill system could be
>> built with a softfork.
>>
>> -----------
>> Two new parameters, nLockTime2 and nKillTime are defined:
>>
>> nLockTime2 (Range: 0-1,853,010)
>> 0: Tx could be confirmed at or after block 420,000
>> 1: Tx could be confirmed at or after block 420,004
>> .
>> .
>> 719,999: Tx could be confirmed at or after block 3,299,996 (about 55
>> years from now)
>> 720,000: Tx could be confirmed if the median time-past >= 1,474,562,048
>> (2016-09-22)
>> 720,001: Tx could be confirmed if the median time-past >= 1,474,564,096
>> (2016-09-22)
>> .
>> .
>> 1,853,010 (max): Tx could be confirmed if the median time-past >=
>> 3,794,966,528 (2090-04-04)
>>
>> nKillTime (Range: 0-2047)
>> if nLockTime2 < 720,000, the tx could be confirmed at or before block
>> (nLockTime2 + nKillTime * 4)
>> if nLockTime2 >= 720,000, the tx could be confirmed if the median
>> time-past <= (nLockTime2 - 720,001 + nKillTime) * 2048
>>
>> Finally, nLockTime = 500,000,000 + nKillTime + nLockTime2 * 2048
>>
>> Setting a bit flag in tx nVersion will activate the new rules.
>>
>> The resolution is 4 blocks or 2048s (34m)
>> The maximum confirmation window is 8188 blocks (56.9 days) or 16,769,024s
>> (48.5 days)
>>
>> For example:
>> With nLockTime2 = 20 and nKillTime = 100, a tx could be confirmed only
>> between block 420,080 and 420,480
>> With nLockTime2 = 730,000 and nKillTime = 1000, a tx could be confirmed
>> only between median time-past of 1,495,042,048 and 1,497,090,048
>>
>> ----------------
>> Why is this a softfork?
>>
>> Remember this formula: nLockTime = 500,000,000 + nKillTime + nLockTime2 *
>> 2048
>>
>> For height based nLockTime2 (<= 719,999)
>>
>> For nLockTime2 = 0 and nKillTime = 0, nLockTime = 500,000,000, which
>> means the tx could be confirmed after 1970-01-01 with the original lock
>> time rule. As the new rule does not allow confirmation until block 420,000,
>> it's clearly a softfork.
>>
>> It is not difficult to see that the growth of nLockTime will never catch
>> up nLockTime2.
>>
>> At nLockTime2 = 719,999 and nKillTime = 2047, nLockTime = 1,974,559,999,
>> which means 2016-09-22. However, the new rule will not allow confirmation
>> until block 3,299,996 which is decades to go
>>
>>
>>
>> For time based nLockTime2 (> 720,000)
>>
>> For nLockTime2 = 720,000 and nKillTime = 0, nLockTime = 1,974,560,000,
>> which means the tx could be confirmed after median time-past 1,474,560,000
>> (assuming BIP113). However, the new rule will not allow confirmation until
>> 1,474,562,048, therefore a soft fork.
>>
>> For nLockTime2 = 720,000 and nKillTime = 2047, nLockTime = 1,974,562,047,
>> which could be confirmed at 1,474,562,047. Again, the new rule will not
>> allow confirmation until 1,474,562,048. The 1 second difference makes it a
>> soft fork.
>>
>> Actually, for every nLockTime2 value >= 720,000, the lock time with the
>> new rule must be 1-2048 seconds later than the original rule.
>>
>> For nLockTime2 = 1,853,010 and nKillTime = 2047, nLockTime =
>> 4,294,966,527, which is the highest possible value with the 32-bit nLockTime
>>
>> ----------------
>> User's perspective:
>>
>> A user wants his tx either filled or killed in about 3 hours. He will set
>> a time-based nLockTime2 according to the current median time-past, and set
>> nKillTime = 5
>>
>> A user wants his tx get confirmed in the block 630000, the first block
>> with reward below 10BTC. He is willing to pay high fee but don't want it
>> gets into another block. He will set nLockTime2 = 210,000 and nKillTime = 0
>>
>> ----------------
>> OP_CLTV
>>
>> Time-based OP_CLTV could be upgraded to support time-based nLockTime2.
>> However, height-based OP_CLTV is not compatible with nLockTime2. To spend a
>> height-based OP_CLTV output, user must use the original nLockTime.
>>
>> We may need a new OP_CLTV2 which could verify both nLockTime and
>> nLockTime2
>>
>> ----------------
>> 55 years after?
>>
>> The height-based nLockTime2 will overflow in 55 years. It is very likely
>> a hard fork will happen to implement a better fill-or-kill system. If not,
>> we could reboot everything with another tx nVersion for another 55 years.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<p dir=3D"ltr">Fill or kill us normally used for trades and I think it can =
be confusing. Previous times this has been discussed it has been discussed =
under nExpiryTime or op_height (which enables expiration), for example, in =
the freimarkets white paper.</p>
<p dir=3D"ltr">As Mark points out this can be made safe by requiring that a=
ll the outputs of a transaction that can expire have op_maturity/csv/rcltv =
of 100. That makes them as reorg-safe as coinbase transactions. Unfortunate=
ly this doesn&#39;t play very well with p2sh...</p>
<div class=3D"gmail_quote">On Sep 17, 2015 3:08 PM, &quot;Mark Friedenbach =
via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"att=
ribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Note that th=
is violates present assumptions about transaction validity, unless a constr=
aint also exists that any output of such an expiry block is not spent for a=
t least 100 blocks.<br><br></div>Do you have a clean way of ensuring this?<=
br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, =
Sep 17, 2015 at 2:41 PM, jl2012 via bitcoin-dev <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Fill-or-kill tx is not a new idea and is discussed in the Sca=
ling Bitcoin workshop. In Satoshi&#39;s implementation of nLockTime, a huge=
 range of timestamp (from 1970 to 2009) is wasted. By exploiting this unuse=
d range and with compromise in the time resolution, a fill-or-kill system c=
ould be built with a softfork.<br>
<br>
-----------<br>
Two new parameters, nLockTime2 and nKillTime are defined:<br>
<br>
nLockTime2 (Range: 0-1,853,010)<br>
0: Tx could be confirmed at or after block 420,000<br>
1: Tx could be confirmed at or after block 420,004<br>
.<br>
.<br>
719,999: Tx could be confirmed at or after block 3,299,996 (about 55 years =
from now)<br>
720,000: Tx could be confirmed if the median time-past &gt;=3D 1,474,562,04=
8 (2016-09-22)<br>
720,001: Tx could be confirmed if the median time-past &gt;=3D 1,474,564,09=
6 (2016-09-22)<br>
.<br>
.<br>
1,853,010 (max): Tx could be confirmed if the median time-past &gt;=3D 3,79=
4,966,528 (2090-04-04)<br>
<br>
nKillTime (Range: 0-2047)<br>
if nLockTime2 &lt; 720,000, the tx could be confirmed at or before block (n=
LockTime2 + nKillTime * 4)<br>
if nLockTime2 &gt;=3D 720,000, the tx could be confirmed if the median time=
-past &lt;=3D (nLockTime2 - 720,001 + nKillTime) * 2048<br>
<br>
Finally, nLockTime =3D 500,000,000 + nKillTime + nLockTime2 * 2048<br>
<br>
Setting a bit flag in tx nVersion will activate the new rules.<br>
<br>
The resolution is 4 blocks or 2048s (34m)<br>
The maximum confirmation window is 8188 blocks (56.9 days) or 16,769,024s (=
48.5 days)<br>
<br>
For example:<br>
With nLockTime2 =3D 20 and nKillTime =3D 100, a tx could be confirmed only =
between block 420,080 and 420,480<br>
With nLockTime2 =3D 730,000 and nKillTime =3D 1000, a tx could be confirmed=
 only between median time-past of 1,495,042,048 and 1,497,090,048<br>
<br>
----------------<br>
Why is this a softfork?<br>
<br>
Remember this formula: nLockTime =3D 500,000,000 + nKillTime + nLockTime2 *=
 2048<br>
<br>
For height based nLockTime2 (&lt;=3D 719,999)<br>
<br>
For nLockTime2 =3D 0 and nKillTime =3D 0, nLockTime =3D 500,000,000, which =
means the tx could be confirmed after 1970-01-01 with the original lock tim=
e rule. As the new rule does not allow confirmation until block 420,000, it=
&#39;s clearly a softfork.<br>
<br>
It is not difficult to see that the growth of nLockTime will never catch up=
 nLockTime2.<br>
<br>
At nLockTime2 =3D 719,999 and nKillTime =3D 2047, nLockTime =3D 1,974,559,9=
99, which means 2016-09-22. However, the new rule will not allow confirmati=
on until block 3,299,996 which is decades to go<br>
<br>
<br>
<br>
For time based nLockTime2 (&gt; 720,000)<br>
<br>
For nLockTime2 =3D 720,000 and nKillTime =3D 0, nLockTime =3D 1,974,560,000=
, which means the tx could be confirmed after median time-past 1,474,560,00=
0 (assuming BIP113). However, the new rule will not allow confirmation unti=
l 1,474,562,048, therefore a soft fork.<br>
<br>
For nLockTime2 =3D 720,000 and nKillTime =3D 2047, nLockTime =3D 1,974,562,=
047, which could be confirmed at 1,474,562,047. Again, the new rule will no=
t allow confirmation until 1,474,562,048. The 1 second difference makes it =
a soft fork.<br>
<br>
Actually, for every nLockTime2 value &gt;=3D 720,000, the lock time with th=
e new rule must be 1-2048 seconds later than the original rule.<br>
<br>
For nLockTime2 =3D 1,853,010 and nKillTime =3D 2047, nLockTime =3D 4,294,96=
6,527, which is the highest possible value with the 32-bit nLockTime<br>
<br>
----------------<br>
User&#39;s perspective:<br>
<br>
A user wants his tx either filled or killed in about 3 hours. He will set a=
 time-based nLockTime2 according to the current median time-past, and set n=
KillTime =3D 5<br>
<br>
A user wants his tx get confirmed in the block 630000, the first block with=
 reward below 10BTC. He is willing to pay high fee but don&#39;t want it ge=
ts into another block. He will set nLockTime2 =3D 210,000 and nKillTime =3D=
 0<br>
<br>
----------------<br>
OP_CLTV<br>
<br>
Time-based OP_CLTV could be upgraded to support time-based nLockTime2. Howe=
ver, height-based OP_CLTV is not compatible with nLockTime2. To spend a hei=
ght-based OP_CLTV output, user must use the original nLockTime.<br>
<br>
We may need a new OP_CLTV2 which could verify both nLockTime and nLockTime2=
<br>
<br>
----------------<br>
55 years after?<br>
<br>
The height-based nLockTime2 will overflow in 55 years. It is very likely a =
hard fork will happen to implement a better fill-or-kill system. If not, we=
 could reboot everything with another tx nVersion for another 55 years.<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div>

--089e0141aa1afcd58d051ff639b4--