From: "Russell O'Connor" <roconnor@blockstream•io>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
Russell O'Connor <roconnor@blockstream•com>,
Kalle Alm <kalle.alm@gmail•com>
Subject: Re: [bitcoin-dev] BIP 117 Feedback
Date: Fri, 12 Jan 2018 05:48:33 -0500 [thread overview]
Message-ID: <CAMZUoKn4noCEQR6eqf9hiZSMdk-3b8UHR1NrEFrKNoLSMzVjGQ@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBgRrqZryiETZYCWiqHNOmN2bCfsvr30znjN-gKiU5Vfjg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]
Putting aside for the moment the concerns that Pieter and Rusty have raised
about BIP 117 (concerns which I agree with), is BIP 117 even a viable soft
fork to begin with?
When it comes to soft forks of Script, in the past there have been two
kinds.
The first kind is soft-forking new script semantics into NOPn codes. In
this case, everyone ought to know that these op codes are reserved for
future extensions and no one should be writing script that depends on NOPn
having NOP behavior (For users who want real nop behaviour, there does
exist a real NOP opcode).
The second kind of soft-forking new script semantics is the
reinterpretation of various wholesale scripts (historically via
templates). Examples of this are Segwit and P2SH. In the case of Segwit,
the scripts gaining new semantics were applied to a form of completely
unsecured "anyone-can-spend" programs. Anyone who created such output
prior to the activation of Segwit would know that anyone could claim
ownership of those outputs, and therefore the possibility of losing the
ability to spend legacy forms of these segwit-style outputs is arguably not
harmful as no one in particular had ownership of such funds. The story for
P2SH is somewhat similar: Prior to the activation of P2SH the creator of of
P2SH style outputs would know that anyone could claim ownership of that
style of output as soon as the hash preimage is published (in the mempool,
for example).
However, if I understand correctly, the situation for BIP 117 is entirely
different. As far as I understand there is currently no restrictions about
terminating a v0 witness program with a non-empty alt-stack, and there are
no restrictions on leaving non-canonical boolean values on the main stack.
There could already be commitments to V0 witness programs that, when
executed in some reasonable context, leave a non-empty alt-stack and/or
leave a non-canonical true value on the main stack. Unlike the P2SH or
Segwit soft-forks, these existing commitments could be real outputs that
currently confer non-trivial ownership over their associated funds. If BIP
117 were activated, these commitments would be subject to a new set of
rules that didn't exist when the commitments were made. In particular,
these funds could be rendered unspendable. Because segwit commitments are
hashes of segwit programs, there is no way to even analyze the blockchain
to determine if these commitments currently exist (and even if we could it
probably woudln't be adequate protection).
Naturally we shouldn't be making new rules that could, in principle,
retroactively remove ownership of existing user's funds.
>
[-- Attachment #2: Type: text/html, Size: 3224 bytes --]
next prev parent reply other threads:[~2018-01-12 10:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-09 11:22 Rusty Russell
2018-01-09 12:40 ` Mark Friedenbach
2018-01-09 14:21 ` Pieter Wuille
2018-01-09 22:57 ` Mark Friedenbach
2018-01-12 10:48 ` Russell O'Connor [this message]
2018-01-16 1:06 ` Rusty Russell
2018-01-16 3:27 ` Gregory Maxwell
2018-01-16 4:15 ` Luke Dashjr
2018-01-16 8:39 ` Russell O'Connor
2018-03-05 15:28 ` Johnson Lau
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=CAMZUoKn4noCEQR6eqf9hiZSMdk-3b8UHR1NrEFrKNoLSMzVjGQ@mail.gmail.com \
--to=roconnor@blockstream$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=kalle.alm@gmail$(echo .)com \
--cc=pieter.wuille@gmail$(echo .)com \
--cc=roconnor@blockstream$(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