public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mark Friedenbach <mark@friedenbach.org>
To: jl2012@xbt.hk
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
Date: Sun, 23 Aug 2015 19:54:34 -0700	[thread overview]
Message-ID: <CAOG=w-vXFcq1bCkviWOK8nh5wz77tYy9hbLXCn8nGLzNRTSgOw@mail.gmail.com> (raw)
In-Reply-To: <85537faedb1e601d243e3edb666fa844@xbt.hk>

[-- Attachment #1: Type: text/plain, Size: 2487 bytes --]

Sorry this was meant for the list:

There are only 32 bits in the version field. If you're going to spend a bit
for perpetuity to indicate whether or not a feature is active, you'd better
have a good reason to make that feature optional.

I haven't seen a compelling use case for having BIP 68 be optional in that
way. As you note, BIP 68 semantics is already optional by toggling the most
significant bit, and that doesn't permanently burn a version bit.
On Aug 23, 2015 7:41 PM, "jl2012 via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Gregory Maxwell via bitcoin-dev 於 2015-08-23 21:01 寫到:
>
>
>> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
>> discussion has any thought been given to represent one block with more
>> than one increment?  This would leave additional space for future
>> signaling, or allow, for example, higher resolution numbers for a
>> sharechain commitement.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> I think this comment is more related to BIP68 instead of OP_CSV? Without
> further complicating the BIP68, I believe the best way to leave room for
> improvement is to spend a bit in tx nVersion to indicate the activation of
> BIP68. I have raised this issue before with
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html
> However, it seems Mark isn't in favor of my proposal
>
> The idea is not to permanently change the meaning of nSequence. Actually,
> BIP68 is "only enforced if the most significant bit of the sequence number
> field is set." So BIP68 is optional, anyway. All I suggest is to move the
> flag from nSequence to nVersion. However, this will leave much bigger room
> for using nSequence for other purpose in the future.
>
> AFAIK, nSequence is the only user definable and signed element in TxIn.
> There could be more interesting use of this field and we should not change
> its meaning permanently. (e.g. if nSequence had 8 bytes instead of 4 bytes,
> it could be used to indicate the value of the input to fix this problem:
> https://bitcointalk.org/index.php?topic=181734.0 )
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3509 bytes --]

  reply	other threads:[~2015-08-24  2:54 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-13 11:06 [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime Btc Drak
2015-08-13 18:12 ` Mark Friedenbach
2015-08-13 19:20   ` Gregory Maxwell
2015-08-13 23:42 ` Joseph Poon
2015-08-14  0:47   ` Mark Friedenbach
2015-08-14 18:53     ` Matt Corallo
2015-08-14 21:29       ` Mark Friedenbach
2015-08-14 22:24         ` Jorge Timón
2015-08-17 19:58 ` Btc Drak
2015-08-19 10:37   ` Jorge Timón
2015-08-19 16:21     ` Mark Friedenbach
2015-08-19 21:27       ` Joseph Poon
2015-08-19 21:32         ` Jorge Timón
2015-08-20 21:23         ` Peter Todd
2015-08-24  0:25       ` Tom Harding
2015-08-24  1:01         ` Gregory Maxwell
2015-08-24  2:23           ` Jorge Timón
2015-08-24  2:37             ` Mark Friedenbach
2015-08-25 22:08               ` Mark Friedenbach
2015-08-25 22:36                 ` Tier Nolan
2015-08-27 23:32                 ` Mark Friedenbach
2015-09-16 22:40                   ` Btc Drak
2015-09-16 23:23                     ` Eric Lombrozo
2015-09-17  4:23                       ` Mark Friedenbach
2015-09-18  1:21                         ` Rusty Russell
2015-09-17  7:43                   ` jl2012
2015-08-24  2:40           ` jl2012
2015-08-24  2:54             ` Mark Friedenbach [this message]
2015-08-24  7:00               ` jl2012
2015-08-25 10:15                 ` Btc Drak
2015-08-27  3:08                   ` Rusty Russell
2015-08-27 11:03                     ` David A. Harding
2015-08-27 12:29                     ` jl2012
2015-08-30 21:33                       ` 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-vXFcq1bCkviWOK8nh5wz77tYy9hbLXCn8nGLzNRTSgOw@mail.gmail.com' \
    --to=mark@friedenbach.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jl2012@xbt.hk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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