From: jl2012@xbt•hk
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Gregory Maxwell <gmaxwell@gmail•com>,
Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness features wish list
Date: Sun, 13 Dec 2015 13:41:44 -0500 [thread overview]
Message-ID: <a46f4277e8859affba4e5cfe5474d53a@xbt.hk> (raw)
In-Reply-To: <CAPg+sBia_rCNkPfKhKxDiOaun5zRKj9LVRkGf_YqVvYWiTox1A@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Pieter Wuille 2015-12-13 13:07 :
> The use of a NOP opcode to indicate a witness script was something I
> considered at first too, but it's not really needed. You wouldn't be
> able to use that opcode in any place a normal opcode could occur, as
> it needs to be able to inspect the full scriptSig (rather than just
> its resulting stack) anyway. So both in practice and conceptually it
> is only really working as a template that gets assigned a special
> meaning (like P2SH did). We don't need an opcode for that, and instead
> we could say that any scriptPubKey (or redeemscript) that consists of
> a single push is a witness program.
>
>> 5. The most significant byte of serialized script is the version byte,
>> an
>> unsigned number
>> 6. If the version byte is 0x00, the script must fail
>
> What is that good for?
Just to make sure a script like OP_0 OP_SEGWIT will fail.
Anyway, your design may be better so forget it
>> 7. If the version byte is 0x02 to 0xff, the rest of the serialized
>> script is
>> ignored and the output is spendable with any form of witness (even if
>> the
>> witness contains something invalid in the current script system, e.g.
>> OP_RETURN)
>
> Do you mean the scriptPubKey itself, or the script that follows after
> the version byte?
> * The scriptPubKey itself: that's in contradiction with your rule 4,
> as segwit scripts are by definition only a push (+ opcode), so they
> can't be an OP_RETURN.
> * The script after the version byte: agree - though it doesn't
> actually need to be a script at all even (see further).
I am not referring to the serialized script, but the witness. Basically,
it doesn't care what the content look like.
> It is useful however to allow segwit inside P2SH
Agree
> So let me summarize by giving an equivalent to your list above,
> reflecting how my current prototype works:
> A) A scriptPubKey or P2SH redeemscript that consists of a single push
> of 2 to 41 bytes gets a new special meaning, and the byte vector
> pushed by it is called the witness program.
Why 41 bytes? Do you expect all witness program to be P2SH-like?
> The program
> must not fail and result in a single TRUE on the stack, and nothing
> else (to prevent stuffing the witness with pointless data during relay
> of transactions).
Could we just implement this as standardness rule? It is always possible
to stuff the scriptSig with pointless data so I don't think it's a new
attack vector. What if we want to include the height and tx index of
the input for compact fraud proof? Such fraud proof should not be an
opt-in function and not be dependent on the version byte
For the same reason, we should also allow traditional tx to have data
in the witness field, for any potential softfork upgrade
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQGcBAEBCAAGBQJWbbugAAoJEO6eVSA0viTSD8oMAKFvd/+KZgH13tErEA+iXzF5
pwT4/eoQWSTvxIDVrFN+9wV79ogO4/aiCDEdmNF2IZD3QqmhKl7iOPw2SEseRTbe
e1r5z67yuudXyEQocZvy5+NOUp3N978b8weuRsHWG1HXgxTRmgZTrEeNtbEUs0X2
n5l6e0scnZAu70svBXr8X9HnOm2P/QLxtAqyNW19caCi+Dg/4Curx48tXQ/I9IxT
SYFVzB++FIoua49Cf1RJN+dUfywg67wT5l9NX4uWAX0qNB+p6BPP8df/72G/u564
NIaJs3IFiUaNktXz9aDM4s7pSzR6PlCK6LFKjE52sBY5uREHGU4PnfX9YqtwiEXA
Hr3YoFiepxAwl6icJi3wHKa6i0NGvj1fR1h6xuJ7ulzNv5mwuzXPOgvTDK4wpejl
ee8wsQZwmzchAfgyfPsgSaPh/jjBwm2S+WDMbL4HDmnWqVDl8dG3I/b3XP0aegY9
4RxPhLOA1qToNDGhnm+JNqT60OKgatpDN/4bRgRscA==
=4B1D
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2015-12-13 18:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 6:47 jl2012
2015-12-10 8:26 ` Gregory Maxwell
2015-12-10 8:28 ` Bryan Bishop
2015-12-10 9:51 ` Gregory Maxwell
2015-12-13 15:25 ` jl2012
2015-12-13 18:07 ` Pieter Wuille
2015-12-13 18:41 ` jl2012 [this message]
2015-12-10 12:54 ` Tamas Blummer
2015-12-12 0:43 ` Jannes Faber
2015-12-13 20:34 ` Rusty Russell
2015-12-14 11:44 ` Jonathan Toomim
2015-12-14 12:32 Adam Back
2015-12-14 12:50 ` Jonathan Toomim
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=a46f4277e8859affba4e5cfe5474d53a@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmaxwell@gmail$(echo .)com \
--cc=pieter.wuille@gmail$(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