Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5D0F9136C for ; Sun, 26 May 2019 14:33:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender4-of-o59.zoho.com (sender4-of-o59.zoho.com [136.143.188.59]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4A6E213A for ; Sun, 26 May 2019 14:33:11 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1558881190; cv=none; d=zoho.com; s=zohoarc; b=VgnjTSHB/bXEhCZ7FfgyjFJ430b+A4LxifqUNaimQngqABa/a0yX8tp5BCAJRhX4NfriWI+hMwl8sCgnM+FOKxclwL4D++srLEq0LcyLjYfZKObwO3+2jpQSDcSuvJ6Sl7q5IxCAFOcX8j9uVbSMpVg6GqnXwrFnJTFWKz+9rfU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1558881190; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=xPuk3UNwbLs5El/VpCLvftVJM/tmwrT8zgmnjU1UTX0=; b=BrszPYhi/vb7+hOHZB3tq8hTYOEmK7DlYqtKxf/OTAPVMuictO52X4xszaxvlWzf2OI9rtyXe6TGGcvsGWeE2D6HuCVgD1j1o2qVcn2sY4uiGHry/SXQzYioMLf2zkpkq+0eRHzHjxUKqxXgwMs1xa/cpB634mZz3TvQz6lPNuk= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk; spf=pass smtp.mailfrom=jl2012@xbt.hk; dmarc=pass header.from= header.from= Received: from [192.168.1.2] (1-64-133-115.static.netvigator.com [1.64.133.115]) by mx.zohomail.com with SMTPS id 1558881189582425.15699548208727; Sun, 26 May 2019 07:33:09 -0700 (PDT) From: Johnson Lau Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 26 May 2019 22:33:06 +0800 References: To: Aymeric Vitte , bitcoin-dev In-Reply-To: Message-Id: <6DFB6C65-D123-40FD-9CE3-49FFCA81EE46@xbt.hk> X-Mailer: Apple Mail (2.3445.104.11) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 27 May 2019 14:27:31 +0000 Subject: Re: [bitcoin-dev] Two questions about segwit implementation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 14:33:12 -0000 > On 26 May 2019, at 7:56 AM, Aymeric Vitte via bitcoin-dev = wrote: >=20 > 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 >=20 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 >=20 A =E2=80=9C00=E2=80=9D element means the size of this element is zero. = Since it=E2=80=99s zero size, no data is followed. This will create an = empty element on the stack. It=E2=80=99s effectively same as OP_0 = (Again, witness is not script) A =E2=80=9C0100=E2=80=9D element means the element size is one, and the = data for this element is =E2=80=9C00=E2=80=9D. 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 =E2=80=9C00=E2=80=9D here means "this input has no witness stack = element=E2=80=9D. 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=E2=80=99t rely on contextual information. However, if all inputs have no stack element, the spec requires you to = always use the non-segwit serialization. >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev