From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yy0BQ-0002EQ-Eu for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 15:57:24 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.49 as permitted sender) client-ip=209.85.192.49; envelope-from=tier.nolan@gmail.com; helo=mail-qg0-f49.google.com; Received: from mail-qg0-f49.google.com ([209.85.192.49]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yy0BM-0007kK-Qs for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 15:57:24 +0000 Received: by qgez61 with SMTP id z61so18531160qge.1 for ; Thu, 28 May 2015 08:57:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.38.167 with SMTP id t36mr3981579qgt.69.1432828635144; Thu, 28 May 2015 08:57:15 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Thu, 28 May 2015 08:57:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 May 2015 16:57:15 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Development Content-Type: multipart/alternative; boundary=001a11c12ce4d2a27e0517266960 X-Spam-Score: 3.3 (+++) 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 (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 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 2.7 MALFORMED_FREEMAIL Bad headers on message from free email service X-Headers-End: 1Yy0BM-0007kK-Qs Subject: Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 15:57:24 -0000 --001a11c12ce4d2a27e0517266960 Content-Type: text/plain; charset=UTF-8 What are the use cases for relative lock time verify? I have 1 and I think that is the kind of thing it is useful for. I think that most cases are just to guarantee that the other party has a chance to react. This means that 8191 blocks should be more than enough (and most would set it lower). For long term, the absolute version is just as good. That depends on use cases. "You can't take step 4 until 3 months after step 3 has completed" doesn't seem useful. On Thu, May 28, 2015 at 4:38 PM, Mark Friedenbach wrote: > Oh ok you mean a semantic difference for the purpose of explaining. It > doesn't actually change the code. > > Regarding saving more bits, there really isn't much room if you consider > time-based relative locktimes and long-lived channels on the order of a > year or more. > > On Thu, May 28, 2015 at 8:18 AM, Tier Nolan wrote: > >> On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach >> wrote: >> >>> Why 3? Do we have a version 2? >>> >> I meant whatever the next version is, so you are right, it's version 2. >> >>> As for doing it in serialization, that would alter the txid making it a >>> hard fork change. >>> >> The change is backwards compatible (since there is no restrictions on >> sequence numbers). This makes it a soft fork. >> >> That doesn't change the fact that you are changing what a field in the >> transaction represents. >> >> You could say that the sequence number is no longer encoded in the >> serialization, it is assumed to be 0xFFFFFFFF for all version 2+ >> transactions and the relative locktime is a whole new field that is the >> same size (and position). >> >> I think keeping some of the bytes for other uses is a good idea. The >> entire top 2 bytes could be ignored when working out relative locktime >> verify. That leaves them fully free to be set to anything. >> >> It could be that if the MSB of the bottom 2 bytes is set, then that >> activates the rule and the top 2 bytes are ignored. >> >> Are there any use-cases which need a RLTV of more than 8191 blocks delay >> (that can't be covered by the absolute version)? >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > --001a11c12ce4d2a27e0517266960 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What are the use cases for relative lock ti= me verify?=C2=A0 I have 1 and I think that is the kind of thing it is usefu= l for.

I think that most cases are just to guarantee that the = other party has a chance to react.=C2=A0 This means that 8191 blocks should= be more than enough (and most would set it lower).

For long t= erm, the absolute version is just as good.=C2=A0 That depends on use cases.= =C2=A0 "You can't take step 4 until 3 months after step 3 has comp= leted" doesn't seem useful.

On Thu, May 28, 2015 at 4:38 PM, Mark Fr= iedenbach <mark@friedenbach.org> wrote:
Oh ok you mean a semantic difference= for the purpose of explaining. It doesn't actually change the code.
Regarding saving more bits, there really isn't much room if = you consider time-based relative locktimes and long-lived channels on the o= rder of a year or more.

On Thu, May 28, 2015 at 8:18 AM, Ti= er Nolan <tier.nolan@gmail.com> wrote:
On Thu, May 28, 2015 at 3:59 PM, Mark Friede= nbach <mark@friedenbach.org> wrote:

Why 3? Do we have a version 2?

I meant whatever the next version is, so you are right, it's ve= rsion 2.

As for doing it in serialization, that would alter the txid = making it a hard fork change.

The change is bac= kwards compatible (since there is no restrictions on sequence numbers).=C2= =A0=C2=A0 This makes it a soft fork.

That doesn't change the fac= t that you are changing what a field in the transaction represents.

=
You could say that the sequence number is no longer encoded in t= he serialization, it is assumed to be 0xFFFFFFFF for all version 2+ transac= tions and the relative locktime is a whole new field that is the same size = (and position).

I think keeping some of the bytes for oth= er uses is a good idea.=C2=A0 The entire top 2 bytes could be ignored when = working out relative locktime verify.=C2=A0 That leaves them fully free to = be set to anything.=C2=A0

It could be that if the MSB of the bottom= 2 bytes is set, then that activates the rule and the top 2 bytes are ignor= ed.

Are there any use-cases which need a RLTV of more tha= n 8191 blocks delay (that can't be covered by the absolute version)?=C2= =A0

------------------------------------------= ------------------------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



--001a11c12ce4d2a27e0517266960--