From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 25BAE1415 for ; Sun, 26 May 2019 17:24:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96207878 for ; Sun, 26 May 2019 17:24:20 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1558891459; cv=none; d=zoho.com; s=zohoarc; b=mK7xMx6foHThDaCZVCWKSUN1Q6HNofirNTtxs3EHDw+KbVwlY+mRWDlqgiuMG7zpi5YjGE1E/Fp4IMSYe44sPvToG+endLqWlP9Epe5IsyoEPowi5avCpk7uXMYM9XLLMncBI7DT0Ws13C9Rcq80TFd+50dFdQdLmMbd0Ph6xRc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1558891459; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=3lbw1j4LLv1lfqn7kQ6RQ3Xx5u2x9MMIzab/OxGt8Gc=; b=oThq4+JyNRxS8J2QdEaHO6JAN/Wkj8uiLHhX/hurFXefGhAgGYsmeOMq/YzQb9EY4X6R60q3qpq9TH/RQRc4HJXUFJLE/e7o7t2t8XA3Gov5zpRBFSEq+Pmg3oMH5XGIcXthN2lP8JSydc02nj6T5LO9zdphJaD60T2bELcBgnc= 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 155889145718745.73247323521434; Sun, 26 May 2019 10:24:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Johnson Lau In-Reply-To: Date: Mon, 27 May 2019 01:24:13 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6DFB6C65-D123-40FD-9CE3-49FFCA81EE46@xbt.hk> <253DB697-BECF-4D68-8A1E-1549B52D5AFA@xbt.hk> To: Aymeric Vitte 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:47 +0000 Cc: bitcoin-dev 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 17:24:21 -0000 Empty scriptSig doesn=E2=80=99t imply segwit input: if the previous = scriptPubKey is OP_1 (which does not allow witness), it could still be = spent with an empty scriptSig Similarly, a scriptSig looking like a spend of P2SH-segwit doesn=E2=80=99t= imply segwit input: if the previous scriptPubKey is empty, it could be = spent with a push of any non-zero value. > On 27 May 2019, at 1:09 AM, Aymeric Vitte = wrote: >=20 > I did not phrase correctly in fact, what I meant is: if the validator > sees empty or witness script in scriptSig, then this is a segwit = input, > and doing this one by one the validator can associate the correct = segwit > data to the correct segwit input, so 00 does not look to be needed >=20 > Le 26/05/2019 =C3=A0 18:28, Johnson Lau a =C3=A9crit : >> This is not how it works. While the transaction creator may know = which inputs are segwit, the validators have no way to tell until they = look up the UTXO set. >>=20 >> In a transaction, all information about an input the validators have = is the 36-byte outpoint (txid + index). Just by looking at the outpoint, = there is no way to tell whether it is segwit-enabled or not. So there = needs to be a way to tell the validator that =E2=80=9Cthe witness for = this input is empty=E2=80=9D, and it is the =E2=80=9C00=E2=80=9D. >>=20 >>> On 27 May 2019, at 12:18 AM, Aymeric Vitte = wrote: >>>=20 >>> =E2=80=A6=E2=80=A6. 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 >>=20