This saves us ocodes for later but it's uglier and produces slightly
bigger scripts.
If we're convinced it's worth it, seems like the right way to do it,
and certainly cltv and rclv/op_maturity are related.
But let's not forget that we can always use this same trick with the
last opcode to get
I have no strong opinion, but a slight preference for separate opcodes.
Reason: given the current progress, they'll likely be deployed
independently, and maybe the end result is not something that cleanly fits
the current CLTV argument structure.
Gavin and @NicolasDorier have a point: If there isn't actually scarcity of
NOPs because OP_NOP10 could become type OP_EX (if we run out), it makes
sense to chose the original unparameterised CLTV version #6124 which also
has been better tested. It's cleaner, more readable and results in a
slightly
It should actually be straightforward to softfork RCLTV in as a negative CLTV.
All nLockTime are = any negative number, so a negative number makes CLTV a
no-op always. Therefore, it is clean to define negative numbers as relative
later. It's also somewhat obvious to developers, since negative
On Tue, May 12, 2015 at 08:38:27PM +, Luke Dashjr wrote:
It should actually be straightforward to softfork RCLTV in as a negative CLTV.
All nLockTime are = any negative number, so a negative number makes CLTV a
no-op always. Therefore, it is clean to define negative numbers as relative
I like the reuse with negative numbers more than the current proposal
because it doesn't imply bigger scripts. If all problems that may
arise can be solved, that is.
If we went that route, we would start with the initial CLTV too.
But I don't see many strong arguments in favor of using the current
On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote:
That said, if people have strong feelings about this, I would be willing
to make OP_CLTV work as follows:
nLockTime 1 OP_CLTV
Where the 1 selects absolute mode, and all others act as OP_NOP's. A
future relative CLTV could
On Thu, May 07, 2015 at 11:05:47AM +0930, Rusty Russell wrote:
Peter Todd p...@petertodd.org writes:
That said, if people have strong feelings about this, I would be willing
to make OP_CLTV work as follows:
nLockTime 1 OP_CLTV
Where the 1 selects absolute mode, and all others act
Peter Todd p...@petertodd.org writes:
That said, if people have strong feelings about this, I would be willing
to make OP_CLTV work as follows:
nLockTime 1 OP_CLTV
Where the 1 selects absolute mode, and all others act as OP_NOP's. A
future relative CLTV could then be a future soft-fork
On Mon, May 4, 2015 at 6:07 AM, Peter Todd p...@petertodd.org wrote:
Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool
only CLTV pull-req²:
I like merging this, but doing both CLTV things in one swoop would be
really nice. Certainly if we're gonna use one of the
Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool
only CLTV pull-req²:
I like merging this, but doing both CLTV things in one swoop would be
really nice. Certainly if we're gonna use one of the precious few
OP_NOPs we have we might as well make it more flexible.
I
11 matches
Mail list logo
