On Nov 26, 2015 12:06 AM, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Again my objection would go away if we renamed nSequence, but I actually
think the nSequence name is better...
I suggested to rename nSequence to nMaturity on this list even before the
bi
After reading Rusty's post, I admit there's something to be said for the fact
that both the script and the nSequence field play a combined role, and thus,
making the interaction between the two more clear in the naming make sense.
It is somewhat unfortunate that currently, we can't just have a d
I was curious about there being only 10 single-byte opcodes left. There
are ten single-byte OP_NOPx opcodes defined, but there are 15 opcodes that
"simply *do not exist anymore* in the protocol" because they are scary (had
bugs that "could crash any Bitcoin node if exploited" or "allowed anyone to
Eric Lombrozo via bitcoin-dev writes:
>>From an app developer's perspective, I think it is pretty blatantly
> clear that relative timelock is *the* critical exposed functionality
> intended here.
As someone who actually developed scripts using CSV, I agree with Mark
(and Matt). The relative lo
On Thu, Nov 26, 2015 at 01:32:58PM -0800, Eric Lombrozo via bitcoin-dev wrote:
> After a little more though (and some comments from aj), I realize that the
> opcode naming convention is actually CHECK VERIFY.
>
> Therefore, the full opcode name should be CHECKRELATIVELOCKTIMEVERIFY.
>
> However
ater acceptance more quickly; while stubbornly adhering to an
>esoteric detail that is only there for historical reasons will only
>continue to delay the idea's acceptance and adoptance.
>
>- Eric
>
>-- Original Message --
>From: "Mark Friedenbach via bitcoin-de
's
>something to be said for naming consistency.
>
>- Eric
>
>
>
>-- Original Message ------
>From: "Jorge Timón"
>To: "Btc Drak"
>Cc: "Bitcoin Dev"
>Sent: 11/24/2015 4:31:55 AM
>Subject: Re: [bitcoin-dev] Alternative n
ornly adhering to an
esoteric detail that is only there for historical reasons will only
continue to delay the idea's acceptance and adoptance.
- Eric
-- Original Message --
From: "Mark Friedenbach via bitcoin-dev"
To: "Btc Drak"
Cc: "Bitcoin D
Looks like I'm the long dissenting voice here? As the originator of the
name CHECKSEQUENCEVERIFY, perhaps I can explain why the name was
appropriately chosen and why the proposed alternatives don't stand up.
First, the names are purposefully chosen to illustrate what they do:
What does CHECKLOCKT
hard failing or NOP), so there's
something to be said for naming consistency.
- Eric
-- Original Message --
From: "Jorge Timón"
To: "Btc Drak"
Cc: "Bitcoin Dev"
Sent: 11/24/2015 4:31:55 AM
Subject: Re: [bitcoin-dev] Alternative name for CHECKSE
On Nov 24, 2015 1:21 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Whatever we call it, deciding on that is a simple s/FOO/BAR/ prior to
> release.
While I agree we're not in a hurry, the more we wait, the longer docs (to
be modified later) will accumulate ma
I agree, I believe the first name that an op with equivalent functionality
had was simply op_maturity.
At least I remember we discussed such an opcode when discussing pegged
sidechains' design.
I kind of dislike the check_x_verify naming pattern. We want all new
operands to return if whatever they
On Tue, Nov 24, 2015 at 10:30:52AM +, Btc Drak via bitcoin-dev wrote:
> BIP68 introduces relative lock-time semantics to part of the nSequence
> field leaving the majority of bits undefined for other future applications.
>
> BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifi
BIP68 introduces relative lock-time semantics to part of the nSequence
field leaving the majority of bits undefined for other future applications.
BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically
limited to verifying transaction inputs according to BIP68's relative
lock-t
14 matches
Mail list logo
