path: root/26/82d9f1625d4c159bff9416eba16e4329f10139

Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2D4B7117B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Sep 2015 19:12:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
	[209.85.212.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05CAD19E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Sep 2015 19:12:28 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so3766239wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Sep 2015 12:12:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=G8ULjlxo7LEv77jULYcbvh0r6FriY9BpOUayyRU2Ajk=;
	b=PFCYTeFfIw/K2EMOxQcz2QOYZagFMQkyraix5rQUbLA294VKRdYh7Ar9qz6hA3m4lV
	+1R1QXBLHQhmAXHtog1gztlNH04zwRqIrnWXhcz40fMvsW+p8CeZjDxV2lEJI4oatnag
	7XALGLZenyITkes7pkrU1ECeNoIbWCsaxro5XnAmFi2ZH/DIQZ4jFKTOHAs1QzAkAdj0
	pWV/+Bbd/UFdkiCJ4zkY+04XHGM5KCWnXgCCvR3p49K8MS8/KGybKfE6jzQWLjzsh+VR
	rRAk0A1/ADGtBqDGrrJCpGRHoCNjoSRwdSrvgSHBxWFwxsCceZyDRzTjPtPJf3jAvmyv
	RKVA==
X-Received: by 10.194.174.227 with SMTP id bv3mr1500091wjc.142.1442517147629; 
	Thu, 17 Sep 2015 12:12:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.21.200 with HTTP; Thu, 17 Sep 2015 12:12:08 -0700 (PDT)
In-Reply-To: <a50b82c156c805a284386d80a42cc926@xbt.hk>
References: <a50b82c156c805a284386d80a42cc926@xbt.hk>
From: Btc Drak <btcdrak@gmail.com>
Date: Thu, 17 Sep 2015 20:12:08 +0100
Message-ID: <CADJgMzusBukiU1AFgm3k0C-oiSVvsHfV1Jk0E01KOQyGieJbsA@mail.gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=089e013d0f9a2abefd051ff632b4
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
	HK_RANDOM_FROM, 
	HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=no 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:12:30 -0000

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

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.

On Thu, Sep 17, 2015 at 7: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
>

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

<div dir=3D"ltr">Forgive me if I have missed the exact use-case, but this s=
eems overly complex. Surely fill-or-kill refers to getting a transaction co=
nfirmed 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 s=
mall range of nLocktime such that a TX will be accepted into mempool for a =
specific period before expiring.</div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Thu, Sep 17, 2015 at 7:41 PM, jl2012 via bitcoin-de=
v <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">Fill-or-kill tx is not a new ide=
a and is discussed in the Scaling Bitcoin workshop. In Satoshi&#39;s implem=
entation of nLockTime, a huge range of timestamp (from 1970 to 2009) is was=
ted. By exploiting this unused range and with compromise in the time resolu=
tion, a fill-or-kill system could 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>

--089e013d0f9a2abefd051ff632b4--