From: Johnson Lau <jl2012@xbt•hk>
To: Russell O'Connor <roconnor@blockstream•io>,
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade
Date: Tue, 18 Dec 2018 04:16:12 +0800 [thread overview]
Message-ID: <E07C0182-1656-44B0-AD2E-8EAF9552ECC1@xbt.hk> (raw)
In-Reply-To: <CAMZUoKnSi+8W7znTNv4BcjrrTDJubDeWeJ8ynUtzs04ES2z6AQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]
> On 16 Dec 2018, at 7:38 AM, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On Fri, Dec 14, 2018 at 8:39 AM Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
> 5. if there's exactly one, non-zero item on the stack; succeed
>
> Unless it is too much bikeshedding, I'd like to propose that to succeed the stack must be exactly empty. Script is more composable that way, removing the need for special logic to handle top-level CHECKSIG, vs mid-level CHECKSIGVERIFY.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
I proposed the same in BIP114. I wish Satoshi had designed that way. But I’m not sure if that would do more harm than good. For example, people might lose money by copying an existing script template. But they might also lose money in the same way as CHECKMULTISIG is disabled. So I’m not sure.
Another related thing I’d like to bikeshed is to pop the stack after OP_CLTV and OP_CSV. The same pros and cons apply.
[-- Attachment #2: Type: text/html, Size: 2164 bytes --]
next prev parent reply other threads:[~2018-12-17 20:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-14 10:48 Anthony Towns
2018-12-15 23:38 ` Russell O'Connor
2018-12-17 20:16 ` Johnson Lau [this message]
2018-12-18 3:18 ` Russell O'Connor
2018-12-18 4:58 ` Anthony Towns
2018-12-18 10:00 ` 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=E07C0182-1656-44B0-AD2E-8EAF9552ECC1@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roconnor@blockstream$(echo .)io \
/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