From: Mark Friedenbach <mark@friedenbach.org>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
Date: Sun, 1 Oct 2017 11:34:07 -0700
References: <201710010113.30518.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <201710010113.30518.luke@dashjr.org>
Message-Id: <089161B1-9AD6-45A2-BE0A-215FECC19510@friedenbach.org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
Precedence: list

I would also suggest that the 520 byte push limitation be removed for v1 =
scripts as well. MERKLEBRANCHVERIFY in particular could benefit from =
larger proof sizes. To do so safely would require reworking script =
internals to use indirect pointers and reference counting for items on =
stack, but this is worth doing generally, and introducing a per-input =
hashing limit equal to a small multiple of the witness size (or =
retaining the opcount limit).

> On Sep 30, 2017, at 6:13 PM, Luke Dashjr via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> I've put together a first draft for what I hope to be a good next step =
for=20
> Segwit and Bitcoin scripting:
>    =
https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki
>=20
> This introduces 5 key changes:
>=20
> 1. Minor versions for witnesses, inside the witness itself. =
Essentially the=20
> witness [major] version 1 simply indicates the witness commitment is =
SHA256d,=20
> and nothing more.
>=20
> The remaining two are witness version 1.0 (major 1, minor 0):
>=20
> 2. As previously discussed, undefined opcodes immediately cause the =
script to=20
> exit with success, making future opcode softforks a lot more flexible.
>=20
> 3. If the final stack element is not exactly true or false, it is =
interpreted=20
> as a tail-call Script and executed. (Credit to Mark Friedenbach)
>=20
> 4. A new shorter fixed-length signature format, eliminating the need =
to guess=20
> the signature size in advance. All signatures are 65 bytes, unless a =
condition=20
> script is included (see #5).
>=20
> 5. The ability for signatures to commit to additional conditions, =
expressed in=20
> the form of a serialized Script in the signature itself. This would be =
useful=20
> in combination with OP_CHECKBLOCKATHEIGHT (BIP 115), hopefully ending =
the=20
> whole replay protection argument by introducing it early to Bitcoin =
before any=20
> further splits.
>=20
> This last part is a big ugly right now: the signature must commit to =
the=20
> script interpreter flags and internal "sigversion", which basically =
serve the=20
> same purpose. The reason for this, is that otherwise someone could =
move the=20
> signature to a different context in an attempt to exploit differences =
in the=20
> various Script interpretation modes. I don't consider the BIP =
deployable=20
> without this getting resolved, but I'm not sure what the best approach =
would=20
> be. Maybe it should be replaced with a witness [major] version and =
witness=20
> stack?
>=20
> There is also draft code implementing [the consensus side of] this:
>    =
https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1
>=20
> Thoughts? Anything I've overlooked / left missing that would be=20
> uncontroversial and desirable? (Is any of this unexpectedly =
controversial for=20
> some reason?)
>=20
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev