From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] CLTV opcode allocation; long-term plans?
Date: Mon, 4 May 2015 01:07:15 -0400 [thread overview]
Message-ID: <20150504050715.GA18856@savin.petertodd.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]
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 have two lines of thought on this:
1) We're going to end up with a Script v2.0 reasonably soon, probably
based on Russel O'Connor and Pieter Wuille's Merkelized Abstract Syntax
Tree³ idea. This needs at most a single OP_NOPx to implement and mostly
removes the scarcity of upgradable NOP's.
2) Similarly in script v1.0 even if we do use up all ten OP_NOPx's, the
logical thing to do is implement an <actual opcode #> OP_EXTENDED.
3) It's not clear what form a relative CLTV will actually take; the BIP
itself proposes a OP_PREVOUT_HEIGHT_VERIFY/OP_PREVOUT_DATA along with
OP_ADD, with any opcode accessing non-reorg-safe prevout info being made
unavailable until the coinbase maturity period has passed for
soft-fork safeness.
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 implemented as
follows:
<relative nLockTime> 2 OP_CLTV
On the bad side it'd be two or three days of work to rewrite all the
existing tests and example code and update the BIP, and (slightly) gets
us away from the well-tested existing implementation. It also may
complicate the codebase compared to sticking with just doing a Script
v2.0, with the additional execution environment data required for v2.0
scripts cleanly separated out. But all in all, the above isn't too big
of a deal.
Interested in your thoughts.
1) https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-98568239
2) https://github.com/bitcoin/bitcoin/pull/5496
3) http://css.csail.mit.edu/6.858/2014/projects/jlrubin-mnaik-nityas.pdf
--
'peter'[:-1]@petertodd.org
00000000000000000908b2eb1cb0660069547abdddad7fa6ad4e743cebe549de
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next reply other threads:[~2015-05-04 5:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-04 5:07 Peter Todd [this message]
2015-05-05 0:54 ` [Bitcoin-development] CLTV opcode allocation; long-term plans? Btc Drak
2015-05-09 9:12 ` Peter Todd
2015-05-12 19:16 ` Jorge Timón
2015-05-12 19:23 ` Pieter Wuille
2015-05-12 19:30 ` Btc Drak
2015-05-12 20:38 ` Luke Dashjr
2015-05-12 21:01 ` Peter Todd
2015-05-13 0:38 ` Jorge Timón
2015-05-07 1:35 ` Rusty Russell
2015-05-07 17:17 ` Peter Todd
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=20150504050715.GA18856@savin.petertodd.org \
--to=pete@petertodd.org \
--cc=bitcoin-development@lists.sourceforge.net \
/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