path: root/75/5fe7ed7f7ae2aefd7b7568f34419481f62cdbb

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <stephencalebmorse@gmail.com>) id 1Yzd9G-0008SC-Av
	for bitcoin-development@lists.sourceforge.net;
	Tue, 02 Jun 2015 03:45:54 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.174 as permitted sender)
	client-ip=209.85.160.174;
	envelope-from=stephencalebmorse@gmail.com;
	helo=mail-yk0-f174.google.com; 
Received: from mail-yk0-f174.google.com ([209.85.160.174])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Yzd9E-00057J-Bv
	for bitcoin-development@lists.sourceforge.net;
	Tue, 02 Jun 2015 03:45:54 +0000
Received: by yked142 with SMTP id d142so49896487yke.3
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 01 Jun 2015 20:45:46 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.0.161 with SMTP id 21mr26188230yhb.141.1433216746879;
	Mon, 01 Jun 2015 20:45:46 -0700 (PDT)
Received: by 10.13.245.70 with HTTP; Mon, 1 Jun 2015 20:45:46 -0700 (PDT)
In-Reply-To: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com>
References: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com>
Date: Mon, 1 Jun 2015 23:45:46 -0400
Message-ID: <CABHVRKQD4YPt0NA8VnXW4VYx0fmCgSHUYq-73F2esHZqX-FUxw@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=089e016345c4157f24051780c703
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(stephencalebmorse[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Yzd9E-00057J-Bv
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 03:45:54 -0000

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

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

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

<div dir=3D"ltr">Hi Mark,<br><br>Overall, I like this idea in every way exc=
ept for one: unless I am missing something, we may still need an <font face=
=3D"monospace, monospace">OP_RCLTV</font> even with this being implemented.=
=C2=A0<div><br></div><div>In use cases such as micropayment channels where =
the funds are locked up by multiple parties, the enforcement of the relativ=
e 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 pu=
tting the relative locktime right into the spending contract (the <font fac=
e=3D"monospace, monospace">scriptPubKey</font> itself). When there is only =
one signer, there&#39;s nothing that enforces using an nSequence and nVersi=
on=3D2 that would prevent spending the output until a certain time.=C2=A0</=
div><div><br></div><div>I hope this is received as constructive criticism, =
I do think this is an innovative idea. In my view, though, it seems to be l=
ess fully-featured than just repurposing an <font face=3D"monospace, monosp=
ace">OP_NOP</font> to create <font face=3D"monospace, monospace">OP_RCLTV</=
font>. The benefits are obviously that it saves transaction space by repurp=
osing unused space, and would likely work for most cases where an <font fac=
e=3D"monospace, monospace">OP_RCLTV</font> would be needed.</div><div><br><=
/div><div>Best,<br>Stephen</div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">=
mark@friedenbach.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>I have written a reference implementation and BIP d=
raft for a soft-fork change to the consensus-enforced behaviour of sequence=
 numbers for the purpose of supporting transaction replacement via per-inpu=
t relative lock-times. This proposal was previously discussed on the mailin=
g list in the following thread:<br><br><a href=3D"http://sourceforge.net/p/=
bitcoin/mailman/message/34146752/" target=3D"_blank">http://sourceforge.net=
/p/bitcoin/mailman/message/34146752/</a><br><br></div><div>In short summary=
, this proposal seeks to enable safe transaction replacement by re-purposin=
g the nSequence field of a transaction input to be a consensus-enforced rel=
ative lock-time.<br><br>The advantages of this approach is that it makes us=
e of the full range of the 32-bit sequence number which until now has rarel=
y been used for anything other than a boolean control over absolute nLockTi=
me, and it does so in a way that is semantically compatible with the origin=
ally envisioned use of sequence numbers for fast mempool transaction replac=
ement.<br><br></div><div>The disadvantages are that external constraints of=
ten prevent the full range of sequence numbers from being used when interpr=
eted 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 partia=
lly addressed by having the relative lock-time semantics be enforced only i=
f the most-significant bit of nSequence is set. This preserves 31 bits for =
alternative use when relative lock-times are not required.<br></div><div><b=
r></div><div>The BIP draft can be found at the following gist:<br><br><a hr=
ef=3D"https://gist.github.com/maaku/be15629fe64618b14f5a" target=3D"_blank"=
>https://gist.github.com/maaku/be15629fe64618b14f5a</a><br><br></div><div>T=
he reference implementation is available at the following git repository:<b=
r></div><div><br><a href=3D"https://github.com/maaku/bitcoin/tree/sequencen=
umbers" target=3D"_blank">https://github.com/maaku/bitcoin/tree/sequencenum=
bers</a><br><br></div><div>I request that the BIP editor please assign a BI=
P number for this work.<br><br></div><div>Sincerely,<br></div><div>Mark Fri=
edenbach<br></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--089e016345c4157f24051780c703--