From: Johnson Lau <jl2012@xbt•hk>
To: Aymeric Vitte <vitteaymeric@gmail•com>,
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Two questions about segwit implementation
Date: Sun, 26 May 2019 22:33:06 +0800 [thread overview]
Message-ID: <6DFB6C65-D123-40FD-9CE3-49FFCA81EE46@xbt.hk> (raw)
In-Reply-To: <e537e781-e10f-7299-fddb-67fab74124c0@gmail.com>
> On 26 May 2019, at 7:56 AM, Aymeric Vitte via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> I realized recently that my segwit implementation was not correct,
> basically some time ago, wrongly reading the specs (and misleaded by
> what follows), I thought that scriptsig would go into witness data as it
> was, but that's not the case, op_pushdata is replaced by varlen
>
Witness is not script. There is no op_pushdata or any other opcodes.
Witness is a stack. For each input, the witness starts with a CCompactSize for the number of stack elements for this input. Each stack element in turns starts with a CCompactSize for the size of this element, followed by the actual data
> Now reading correctly the specs, they seem to be not totally correct,
> then the first question is: why OP_0 is 00 in witness data and not 0100?
> Does this apply to other op_codes? This does not look logical at all
>
A “00” element means the size of this element is zero. Since it’s zero size, no data is followed. This will create an empty element on the stack. It’s effectively same as OP_0 (Again, witness is not script)
A “0100” element means the element size is one, and the data for this element is “00”. So it will leave an 1-byte element on the stack.
> The second question is: why for non segwit inputs there is a 00 length
> in segwit data, what is the rational for that? It should just be nothing
> since you don't need this to reconciliate things
The “00” here means "this input has no witness stack element”. You need this even for non segwit inputs, because there is no way to tell whether an input is segwit-enabled or not, until you look up the UTXO, which might not be always available. Transaction serialization couldn’t rely on contextual information.
However, if all inputs have no stack element, the spec requires you to always use the non-segwit serialization.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
next prev parent reply other threads:[~2019-05-26 14:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-25 23:56 Aymeric Vitte
2019-05-26 14:33 ` Johnson Lau [this message]
2019-05-26 16:18 ` Aymeric Vitte
2019-05-26 16:28 ` Johnson Lau
2019-05-26 17:09 ` Aymeric Vitte
2019-05-26 17:24 ` Johnson Lau
2019-05-26 21:17 ` Aymeric Vitte
2019-05-26 17:54 ` Pieter Wuille
2019-05-26 19:34 ` Thomas Kerin
2019-05-27 7:26 ` Kostas Karasavvas
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=6DFB6C65-D123-40FD-9CE3-49FFCA81EE46@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=vitteaymeric@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