public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aymeric Vitte <vitteaymeric@gmail.com>
To: Johnson Lau <jl2012@xbt.hk>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Two questions about segwit implementation
Date: Sun, 26 May 2019 18:18:46 +0200	[thread overview]
Message-ID: <e342cb8f-a909-a806-bd76-91580234cd7f@gmail.com> (raw)
In-Reply-To: <6DFB6C65-D123-40FD-9CE3-49FFCA81EE46@xbt.hk>

OK, thanks, understood for OP_0 but still for the 00 number of witness
data for non segwit inputs the one that is doing the transaction knows
which inputs are segwit or not, then parsing the transaction you can
associate the correct input to the correct witness data, without the
need of 00, so I must be missing the use case

Le 26/05/2019 à 16:33, Johnson Lau a écrit :
>> 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
>
-- 
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms



  reply	other threads:[~2019-05-26 16:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-25 23:56 [bitcoin-dev] Two questions about segwit implementation Aymeric Vitte
2019-05-26 14:33 ` Johnson Lau
2019-05-26 16:18   ` Aymeric Vitte [this message]
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=e342cb8f-a909-a806-bd76-91580234cd7f@gmail.com \
    --to=vitteaymeric@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jl2012@xbt.hk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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