From: Sjors Provoost <sjors@sprovoost•nl>
To: Luke Dashjr <luke@dashjr•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
Date: Mon, 2 Oct 2017 10:09:00 +0100 [thread overview]
Message-ID: <C248375C-FEE3-4DDC-96DE-FA62CE665369@sprovoost.nl> (raw)
In-Reply-To: <201710020256.27964.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
Op 2 okt. 2017, om 03:56 heeft Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> het volgende geschreven:
>
> On Monday 02 October 2017 12:35:38 AM Mark Friedenbach wrote:
>>> b. OP_RETURNTRUE (Luke). I proposed this in an earlier version of BIP114
>>> but now I think it doesn’t interact well with signature aggregation, and
>>> I worry that it would have some other unexpected effects. c. Generalised
>>> NOP method: user has to provide the returned value, so even VERIFY-type
>>> code could do anything
>>
>> I see no reason to do either. Gate new behavior based on script execution
>> flags, which are set based on the script version. Script versions not
>> understood are treated as "return true" to begin with. The interpreter
>> isn't even going to try to decode the script according to the old rules,
>> let alone try to execute it, so there's no reason for the old soft-fork
>> compatability tricks.
>>
>> The new soft-fork trick is that you increment the script version number.
>> That is all.
>
> This breaks parallel softfork deployments.
If unknown script versions are treated as "return true", there's no need for versions to be deployed in sequence, right? Maybe they should be called numbered script types, rather than script versions.
Sjors
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-10-02 9:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-01 1:13 Luke Dashjr
2017-10-01 2:23 ` Mark Friedenbach
2017-10-01 2:47 ` Luke Dashjr
2017-10-01 5:04 ` Mark Friedenbach
2017-10-01 11:22 ` Felix Weis
2017-10-01 17:36 ` Luke Dashjr
2017-10-01 19:05 ` Russell O'Connor
2017-10-01 19:27 ` Mark Friedenbach
2017-10-01 19:41 ` Russell O'Connor
2017-10-01 20:39 ` Mark Friedenbach
2017-10-01 20:43 ` Luke Dashjr
2017-10-02 20:38 ` Russell O'Connor
2017-10-01 18:34 ` Mark Friedenbach
2017-10-01 21:32 ` Johnson Lau
2017-10-02 0:35 ` Mark Friedenbach
2017-10-02 2:56 ` Luke Dashjr
2017-10-02 9:09 ` Sjors Provoost [this message]
2017-10-02 0:45 ` Luke Dashjr
2017-10-05 20:33 ` Mark Friedenbach
2017-10-05 21:28 ` Russell O'Connor
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=C248375C-FEE3-4DDC-96DE-FA62CE665369@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/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