path: root/4a/772f67beced9edb0862da17bbd66a126e54f01

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 86447122E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Sep 2015 19:07:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f181.google.com (mail-io0-f181.google.com
	[209.85.223.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 600A819D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Sep 2015 19:07:54 +0000 (UTC)
Received: by iofh134 with SMTP id h134so33005289iof.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Sep 2015 12:07:54 -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:from:date
	:message-id:subject:to:cc:content-type;
	bh=dL7qlWiVlOKz6gnXREnQfXTdgHJQhjqXcc7dAbO+Dbg=;
	b=L4XKXLWMIXLswxppaN9vWJa1eNuU8F4hjDtGN71Rfjq6QPqS68XfenJjwBuDRL1yEi
	RD9+7So9QM5onS4KVIFMuzOGP+rmRBIvC9NA3TTbaXrVdVrGXHcqB7wIEgHWw0QvRpPn
	LJCLVMgIm1u91kjP3dFKTWLLqBgDz6sfixUqPiv/+N/woTM/NYCEBSm1lE1kbjnEeDTX
	joyVMWYUqRBUUHGZWOAAMhkQlUgzT56PQdt3lo89WKP0CTXh1PhfLxjLrCjUXlbbvlNY
	AHc5xEsm3NJqWnDls4iIGWzyTxMn2DO2HDy1XzIQ48c0dqYbxrEmucuev1cHY0ZVa+fm
	1d8g==
X-Gm-Message-State: ALoCoQm3WJs4CvJkjHyHzC1EG+RtUenmhXIctpXtNOy5poenSI6c24w+ExB+aCS/RII/YePVzijQ
X-Received: by 10.107.15.159 with SMTP id 31mr9945924iop.159.1442516873815;
	Thu, 17 Sep 2015 12:07:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.135.104 with HTTP; Thu, 17 Sep 2015 12:07:34 -0700 (PDT)
X-Originating-IP: [184.162.86.160]
In-Reply-To: <a50b82c156c805a284386d80a42cc926@xbt.hk>
References: <a50b82c156c805a284386d80a42cc926@xbt.hk>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 17 Sep 2015 15:07:34 -0400
Message-ID: <CAOG=w-vGqsAcw5vdY8SaGVe4Q6XX1J=GCsZftWgjES_N_5c2pA@mail.gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=001a113ee868d8c140051ff621a0
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:07:55 -0000

--001a113ee868d8c140051ff621a0
Content-Type: text/plain; charset=UTF-8

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
>

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

<div dir=3D"ltr"><div>Note that this violates present assumptions about tra=
nsaction validity, unless a constraint also exists that any output of such =
an expiry block is not spent for at least 100 blocks.<br><br></div>Do you h=
ave 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 bitco=
in-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.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 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Fill-or-kill tx is not a ne=
w idea and is discussed in the Scaling Bitcoin workshop. In Satoshi&#39;s i=
mplementation of nLockTime, a huge range of timestamp (from 1970 to 2009) i=
s wasted. By exploiting this unused range and with compromise in the time r=
esolution, 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>

--001a113ee868d8c140051ff621a0--