path: root/1e/435566dbb87005e124d3a061794c474755ee01

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mark@friedenbach.org>) id 1YzoND-0001aZ-5R
	for bitcoin-development@lists.sourceforge.net;
	Tue, 02 Jun 2015 15:45:03 +0000
X-ACL-Warn: 
Received: from mail-ie0-f181.google.com ([209.85.223.181])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YzoN8-0003pe-Kt
	for bitcoin-development@lists.sourceforge.net;
	Tue, 02 Jun 2015 15:45:03 +0000
Received: by ieczm2 with SMTP id zm2so136153683iec.1
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 02 Jun 2015 08:44:53 -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=KKQK17RFVj8Ps/vz9dFGSczlqIVvYtfBwc8KTiGsHiE=;
	b=Qd5emifusVQkWWiojfW+qtg8DnE8qWcu1kbxUrzGinVV3Ua6QER28C4/1rty0/cXIb
	YoqriW0wae2mxgvvhlJiCA3JqS6lgHn3vBnIJWgibkVKBbXiyxTwQSpualENLQyHCaty
	l9M0Gvfdh8ZnasnSWuE9lpi+0A7xO4yGE0RiO72+gzrzMHKT5mvRnzEURMwdRhNVvy/d
	DpqnsyvnKVTAbhyqm8A5fFxFvtHrerqIpArFi7yEjZFFWm6Br6X9+QqAhRdjajqR3AE/
	mxSH63vcU7Q52lBwCWd1y07JHjQFxmVKV2NN2xh1zm32LRYgKSUQdjOo6fiqQ/3z06Ry
	tf0w==
X-Gm-Message-State: ALoCoQmRdgYpBcrTEVXKgNagWMqMC+LKTxKshOzsIc0JM5MAovXgPV2FaA31Od2z1lu/rjDIVAdC
MIME-Version: 1.0
X-Received: by 10.107.3.210 with SMTP id e79mr34570336ioi.50.1433259893178;
	Tue, 02 Jun 2015 08:44:53 -0700 (PDT)
Received: by 10.107.10.197 with HTTP; Tue, 2 Jun 2015 08:44:52 -0700 (PDT)
X-Originating-IP: [172.56.17.138]
Received: by 10.107.10.197 with HTTP; Tue, 2 Jun 2015 08:44:52 -0700 (PDT)
In-Reply-To: <CALqxMTFkWOfWXOnVAnZESkVWHtbZLc=T_sQDoTofr66mcb6_gQ@mail.gmail.com>
References: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com>
	<CABHVRKQD4YPt0NA8VnXW4VYx0fmCgSHUYq-73F2esHZqX-FUxw@mail.gmail.com>
	<CAOG=w-tDdJTkkqGaEEpDZ6pX0kXT7f2wvoN_cEpd6+MVnu1CdQ@mail.gmail.com>
	<E67A3D18-EFB0-4156-98B7-082793D2D871@gmail.com>
	<CALqxMTFkWOfWXOnVAnZESkVWHtbZLc=T_sQDoTofr66mcb6_gQ@mail.gmail.com>
Date: Tue, 2 Jun 2015 08:44:53 -0700
Message-ID: <CAOG=w-v-twsRcfT=nOQA0y5MYQ7bN+W_NVXYkuWSb0kyh4rnvg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=001a113f8ef0ce101e05178ad2d0
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1YzoN8-0003pe-Kt
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP draft] Consensus-enforced
 transaction replacement signalled via sequence numbers
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2015 15:45:03 -0000

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

Oh it is far worse than that. There is nothing preventing those coins from
being spent somewhere else, so actually an expiry would enable coin theft
in a reorg -- you make your spends expire right after they hit the chain
the first time, and then if there is a reorg the spend and subsequent
transactions are invalidated. This is an exploitable means of theft.

For this reason it is very important to male sure that once a transaction
makes it on the chain, it cannot be invalidated by means of a reorg.
On Jun 2, 2015 6:11 AM, "Adam Back" <adam@cypherspace.org> wrote:

> That would also introduce the anomaly of a script that was once valid
> becoming later invalid, when nothing varies other than time.  That is
> not super compatible with the current model of reprocessing
> transactions in later blocks if the block they were first in gets
> reorged.
>
> (Not a huge flexibility loss as you can implement "not after" by
> making it the previous holders responsibility to spend a "not before"
> back to themselves.)
>
> Adam
>
> On 2 June 2015 at 13:52, Stephen <stephencalebmorse@gmail.com> wrote:
> > Do you think it would be useful to have an inverted version of both CSV
> and
> > CLTV? To verify if an output is spent before a specific time. CLTV and
> CSV
> > could be implemented by taking two stack arguments, an integer for the
> > comparison and TRUE/FALSE.
> >
> > Now that I think about this more, the problem is that, for example, just
> > having a lock time of less than some value doesn't actually mean it has
> to
> > be spent before that script value, so this might not work. Likely any
> > implementations of such a feature would have to provide the script
> execution
> > environment with access to information that it doesn't have now, which is
> > what we are trying to avoid.
> >
> > Best,
> > Stephen
> >
> >
> >
> > On Jun 2, 2015, at 12:16 AM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
> >
> > You are correct! I am maintaining a 'checksequenceverify' branch in my
> git
> > repository as well, an OP_RCLTV using sequence numbers:
> >
> > https://github.com/maaku/bitcoin/tree/checksequenceverify
> >
> > Most of the interesting use cases for relative lock-time require an RCLTV
> > opcode. What is interesting about this architecture is that it possible
> to
> > cleanly separate the relative lock-time (sequence numbers) from the RCLTV
> > opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation.
> Like
> > CLTV, the CSV opcode only checks transaction data and requires no
> contextual
> > knowledge about block headers, a weakness of the other RCLTV proposals
> that
> > violate the clean separation between libscript and libconsensus. In a
> > similar way, this BIP proposal only touches the transaction validation
> logic
> > without any impact to script.
> >
> > I would like to propose an additional BIP covering the
> CHECKSEQUENCEVERIFY
> > opcode and its enabling applications. But, well, one thing at a time.
> >
> > On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <
> stephencalebmorse@gmail.com>
> > wrote:
> >>
> >> Hi Mark,
> >>
> >> Overall, I like this idea in every way except for one: unless I am
> missing
> >> something, we may still need an OP_RCLTV even with this being
> implemented.
> >>
> >> In use cases such as micropayment channels where the funds are locked up
> >> by multiple parties, the enforcement of the relative locktime can be
> done by
> >> the first-signing party. So, while your solution would probably work in
> >> cases like this, where multiple signing parties are involved, there may
> be
> >> other, seen or unforeseen, use cases that require putting the relative
> >> locktime right into the spending contract (the scriptPubKey itself).
> When
> >> there is only one signer, there's nothing that enforces using an
> nSequence
> >> and nVersion=2 that would prevent spending the output until a certain
> time.
> >>
> >> I hope this is received as constructive criticism, I do think this is an
> >> innovative idea. In my view, though, it seems to be less fully-featured
> than
> >> just repurposing an OP_NOP to create OP_RCLTV. The benefits are
> obviously
> >> that it saves transaction space by repurposing unused space, and would
> >> likely work for most cases where an OP_RCLTV would be needed.
> >>
> >> Best,
> >> Stephen
> >>
> >> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <mark@friedenbach.org>
> >> wrote:
> >>>
> >>> I have written a reference implementation and BIP draft for a soft-fork
> >>> change to the consensus-enforced behaviour of sequence numbers for the
> >>> purpose of supporting transaction replacement via per-input relative
> >>> lock-times. This proposal was previously discussed on the mailing list
> in
> >>> the following thread:
> >>>
> >>> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
> >>>
> >>> In short summary, this proposal seeks to enable safe transaction
> >>> replacement by re-purposing the nSequence field of a transaction input
> to be
> >>> a consensus-enforced relative lock-time.
> >>>
> >>> The advantages of this approach is that it makes use of the full range
> of
> >>> the 32-bit sequence number which until now has rarely been used for
> anything
> >>> other than a boolean control over absolute nLockTime, and it does so
> in a
> >>> way that is semantically compatible with the originally envisioned use
> of
> >>> sequence numbers for fast mempool transaction replacement.
> >>>
> >>> The disadvantages are that external constraints often prevent the full
> >>> range of sequence numbers from being used when interpreted as a
> relative
> >>> lock-time, and re-purposing nSequence as a relative lock-time
> precludes its
> >>> use in other contexts. The latter point has been partially addressed by
> >>> having the relative lock-time semantics be enforced only if the
> >>> most-significant bit of nSequence is set. This preserves 31 bits for
> >>> alternative use when relative lock-times are not required.
> >>>
> >>> The BIP draft can be found at the following gist:
> >>>
> >>> https://gist.github.com/maaku/be15629fe64618b14f5a
> >>>
> >>> The reference implementation is available at the following git
> >>> repository:
> >>>
> >>> https://github.com/maaku/bitcoin/tree/sequencenumbers
> >>>
> >>> I request that the BIP editor please assign a BIP number for this work.
> >>>
> >>> Sincerely,
> >>> Mark Friedenbach
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>

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

<p dir=3D"ltr">Oh it is far worse than that. There is nothing preventing th=
ose coins from being spent somewhere else, so actually an expiry would enab=
le coin theft in a reorg -- you make your spends expire right after they hi=
t the chain the first time, and then if there is a reorg the spend and subs=
equent transactions are invalidated. This is an exploitable means of theft.=
</p>
<p dir=3D"ltr">For this reason it is very important to male sure that once =
a transaction makes it on the chain, it cannot be invalidated by means of a=
 reorg.</p>
<div class=3D"gmail_quote">On Jun 2, 2015 6:11 AM, &quot;Adam Back&quot; &l=
t;<a href=3D"mailto:adam@cypherspace.org">adam@cypherspace.org</a>&gt; wrot=
e:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That would also i=
ntroduce the anomaly of a script that was once valid<br>
becoming later invalid, when nothing varies other than time.=C2=A0 That is<=
br>
not super compatible with the current model of reprocessing<br>
transactions in later blocks if the block they were first in gets<br>
reorged.<br>
<br>
(Not a huge flexibility loss as you can implement &quot;not after&quot; by<=
br>
making it the previous holders responsibility to spend a &quot;not before&q=
uot;<br>
back to themselves.)<br>
<br>
Adam<br>
<br>
On 2 June 2015 at 13:52, Stephen &lt;<a href=3D"mailto:stephencalebmorse@gm=
ail.com">stephencalebmorse@gmail.com</a>&gt; wrote:<br>
&gt; Do you think it would be useful to have an inverted version of both CS=
V and<br>
&gt; CLTV? To verify if an output is spent before a specific time. CLTV and=
 CSV<br>
&gt; could be implemented by taking two stack arguments, an integer for the=
<br>
&gt; comparison and TRUE/FALSE.<br>
&gt;<br>
&gt; Now that I think about this more, the problem is that, for example, ju=
st<br>
&gt; having a lock time of less than some value doesn&#39;t actually mean i=
t has to<br>
&gt; be spent before that script value, so this might not work. Likely any<=
br>
&gt; implementations of such a feature would have to provide the script exe=
cution<br>
&gt; environment with access to information that it doesn&#39;t have now, w=
hich is<br>
&gt; what we are trying to avoid.<br>
&gt;<br>
&gt; Best,<br>
&gt; Stephen<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Jun 2, 2015, at 12:16 AM, Mark Friedenbach &lt;<a href=3D"mailto:ma=
rk@friedenbach.org">mark@friedenbach.org</a>&gt; wrote:<br>
&gt;<br>
&gt; You are correct! I am maintaining a &#39;checksequenceverify&#39; bran=
ch in my git<br>
&gt; repository as well, an OP_RCLTV using sequence numbers:<br>
&gt;<br>
&gt; <a href=3D"https://github.com/maaku/bitcoin/tree/checksequenceverify" =
target=3D"_blank">https://github.com/maaku/bitcoin/tree/checksequenceverify=
</a><br>
&gt;<br>
&gt; Most of the interesting use cases for relative lock-time require an RC=
LTV<br>
&gt; opcode. What is interesting about this architecture is that it possibl=
e to<br>
&gt; cleanly separate the relative lock-time (sequence numbers) from the RC=
LTV<br>
&gt; opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation.=
 Like<br>
&gt; CLTV, the CSV opcode only checks transaction data and requires no cont=
extual<br>
&gt; knowledge about block headers, a weakness of the other RCLTV proposals=
 that<br>
&gt; violate the clean separation between libscript and libconsensus. In a<=
br>
&gt; similar way, this BIP proposal only touches the transaction validation=
 logic<br>
&gt; without any impact to script.<br>
&gt;<br>
&gt; I would like to propose an additional BIP covering the CHECKSEQUENCEVE=
RIFY<br>
&gt; opcode and its enabling applications. But, well, one thing at a time.<=
br>
&gt;<br>
&gt; On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse &lt;<a href=3D"mailto:st=
ephencalebmorse@gmail.com">stephencalebmorse@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi Mark,<br>
&gt;&gt;<br>
&gt;&gt; Overall, I like this idea in every way except for one: unless I am=
 missing<br>
&gt;&gt; something, we may still need an OP_RCLTV even with this being impl=
emented.<br>
&gt;&gt;<br>
&gt;&gt; In use cases such as micropayment channels where the funds are loc=
ked up<br>
&gt;&gt; by multiple parties, the enforcement of the relative locktime can =
be done by<br>
&gt;&gt; the first-signing party. So, while your solution would probably wo=
rk in<br>
&gt;&gt; cases like this, where multiple signing parties are involved, ther=
e may be<br>
&gt;&gt; other, seen or unforeseen, use cases that require putting the rela=
tive<br>
&gt;&gt; locktime right into the spending contract (the scriptPubKey itself=
). When<br>
&gt;&gt; there is only one signer, there&#39;s nothing that enforces using =
an nSequence<br>
&gt;&gt; and nVersion=3D2 that would prevent spending the output until a ce=
rtain time.<br>
&gt;&gt;<br>
&gt;&gt; I hope this is received as constructive criticism, I do think this=
 is an<br>
&gt;&gt; innovative idea. In my view, though, it seems to be less fully-fea=
tured than<br>
&gt;&gt; just repurposing an OP_NOP to create OP_RCLTV. The benefits are ob=
viously<br>
&gt;&gt; that it saves transaction space by repurposing unused space, and w=
ould<br>
&gt;&gt; likely work for most cases where an OP_RCLTV would be needed.<br>
&gt;&gt;<br>
&gt;&gt; Best,<br>
&gt;&gt; Stephen<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach &lt;<a href=3D"ma=
ilto:mark@friedenbach.org">mark@friedenbach.org</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I have written a reference implementation and BIP draft for a =
soft-fork<br>
&gt;&gt;&gt; change to the consensus-enforced behaviour of sequence numbers=
 for the<br>
&gt;&gt;&gt; purpose of supporting transaction replacement via per-input re=
lative<br>
&gt;&gt;&gt; lock-times. This proposal was previously discussed on the mail=
ing list in<br>
&gt;&gt;&gt; the following thread:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; <a href=3D"http://sourceforge.net/p/bitcoin/mailman/message/34=
146752/" target=3D"_blank">http://sourceforge.net/p/bitcoin/mailman/message=
/34146752/</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; In short summary, this proposal seeks to enable safe transacti=
on<br>
&gt;&gt;&gt; replacement by re-purposing the nSequence field of a transacti=
on input to be<br>
&gt;&gt;&gt; a consensus-enforced relative lock-time.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The advantages of this approach is that it makes use of the fu=
ll range of<br>
&gt;&gt;&gt; the 32-bit sequence number which until now has rarely been use=
d for anything<br>
&gt;&gt;&gt; other than a boolean control over absolute nLockTime, and it d=
oes so in a<br>
&gt;&gt;&gt; way that is semantically compatible with the originally envisi=
oned use of<br>
&gt;&gt;&gt; sequence numbers for fast mempool transaction replacement.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The disadvantages are that external constraints often prevent =
the full<br>
&gt;&gt;&gt; range of sequence numbers from being used when interpreted as =
a relative<br>
&gt;&gt;&gt; lock-time, and re-purposing nSequence as a relative lock-time =
precludes its<br>
&gt;&gt;&gt; use in other contexts. The latter point has been partially add=
ressed by<br>
&gt;&gt;&gt; having the relative lock-time semantics be enforced only if th=
e<br>
&gt;&gt;&gt; most-significant bit of nSequence is set. This preserves 31 bi=
ts for<br>
&gt;&gt;&gt; alternative use when relative lock-times are not required.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The BIP draft can be found at the following gist:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; <a href=3D"https://gist.github.com/maaku/be15629fe64618b14f5a"=
 target=3D"_blank">https://gist.github.com/maaku/be15629fe64618b14f5a</a><b=
r>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The reference implementation is available at the following git=
<br>
&gt;&gt;&gt; repository:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; <a href=3D"https://github.com/maaku/bitcoin/tree/sequencenumbe=
rs" target=3D"_blank">https://github.com/maaku/bitcoin/tree/sequencenumbers=
</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I request that the BIP editor please assign a BIP number for t=
his work.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Sincerely,<br>
&gt;&gt;&gt; Mark Friedenbach<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --------------------------------------------------------------=
----------------<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; Bitcoin-development mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">B=
itcoin-development@lists.sourceforge.net</a><br>
&gt;&gt;&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoi=
n-development" target=3D"_blank">https://lists.sourceforge.net/lists/listin=
fo/bitcoin-development</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
&gt;<br>
</blockquote></div>

--001a113f8ef0ce101e05178ad2d0--