From: Mark Friedenbach <mark@friedenbach•org>
To: 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 08:38:43 -0700 [thread overview]
Message-ID: <CAOG=w-vY7WHso90mtzhSRiuTLVfahMv1Xr6p_AZvyh4krxPLSg@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OXO++0n+UVKe1KYyGv=GyHrZ-MsJtYELk+KC6cEV2UbHQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]
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: 2888 bytes --]
next prev parent reply other threads:[~2015-05-28 15:39 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 [this message]
2015-05-28 15:57 ` Tier Nolan
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='CAOG=w-vY7WHso90mtzhSRiuTLVfahMv1Xr6p_AZvyh4krxPLSg@mail.gmail.com' \
--to=mark@friedenbach$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tier.nolan@gmail$(echo .)com \
/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