path: root/d8/239d6efdfb909f0109f77c71ca6a2b44865785

Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6906FF46
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Sep 2015 19:14:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
	[209.85.212.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 18DEB19E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Sep 2015 19:14:40 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so3877924wic.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Sep 2015 12:14:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=GOCMr9+cVy1uGDNbpw+eBjpbmWPe45gTYTdZv2MEdv0=;
	b=gjWcmxWW4yPtEM/h0MaaPf131+YA0ziQPK3h0Zmy0nWldwawp/+Mwh2AbZYMmSCY37
	uBAhtH3eQ1YGqP2yI8O/yai9qPp7wsSxZId3ogy441fG1NYR50YqDedgvkbI2u1Y3vtx
	nadBfZx++cxVM016MM/ubwGYbykFzd6NYlPKFhaIJqtGn3e/TgfLN5pvDW5mFFEv3usL
	zItmDpnghKUJYD1Wc9+MF8ttGozCPekUfF/5g46762AaTGKKMiHBn2Su8Zz1U2wuGhw2
	NSzZZtINeOEww+WgIQqrVSob/vL+J5M0tyRhFS9kEa9OqQM5QHdQrHWZxtDVHnlxooG4
	Z3Sg==
X-Gm-Message-State: ALoCoQkzBK6qMwNIjZtct2p9MTUNVYfO1BOeLuHrkwyHwkWl55OD2sWGPlj2jzMnahVUzrlInNtc
MIME-Version: 1.0
X-Received: by 10.194.238.39 with SMTP id vh7mr1349419wjc.109.1442517278819;
	Thu, 17 Sep 2015 12:14:38 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Thu, 17 Sep 2015 12:14:38 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Thu, 17 Sep 2015 12:14:38 -0700 (PDT)
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
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fill-or-kill transaction
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2015 19:14:41 -0000

--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--