From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
Date: Thu, 28 May 2015 16:57:15 +0100 [thread overview]
Message-ID: <CAE-z3OWrVP+jE9bL=9+eC+RE5L5kYQ_Y-JT4Go2r+o-M=eYssw@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-vY7WHso90mtzhSRiuTLVfahMv1Xr6p_AZvyh4krxPLSg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2459 bytes --]
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 <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 order of a
> year or more.
>
> On Thu, May 28, 2015 at 8:18 AM, Tier Nolan <tier.nolan@gmail•com> wrote:
>
>> On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach <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 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
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 3890 bytes --]
next prev parent reply other threads:[~2015-05-28 15:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 1:50 Mark Friedenbach
2015-05-27 7:47 ` Peter Todd
2015-05-27 8:18 ` Gregory Maxwell
2015-05-27 10:00 ` Tier Nolan
2015-05-27 10:58 ` Peter Todd
2015-05-27 17:07 ` Jorge Timón
2015-05-27 8:04 ` Telephone Lemien
2015-05-27 10:11 ` Mike Hearn
2015-05-27 15:26 ` Mark Friedenbach
2015-05-27 17:39 ` Mike Hearn
2015-05-28 9:56 ` Mark Friedenbach
2015-05-28 10:23 ` Mike Hearn
2015-05-28 10:30 ` Tier Nolan
2015-05-28 12:04 ` Peter Todd
2015-05-28 13:35 ` Tier Nolan
2015-05-28 16:22 ` s7r
2015-05-28 17:21 ` Tier Nolan
2015-05-28 14:59 ` Mark Friedenbach
2015-05-28 15:18 ` Tier Nolan
2015-05-28 15:38 ` Mark Friedenbach
2015-05-28 15:57 ` Tier Nolan [this message]
2015-06-10 2:40 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE-z3OWrVP+jE9bL=9+eC+RE5L5kYQ_Y-JT4Go2r+o-M=eYssw@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox