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 B344413EC for ; Sun, 26 May 2019 16:29:04 +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 5CF6E6C5 for ; Sun, 26 May 2019 16:29:03 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1558888142; cv=none; d=zoho.com; s=zohoarc; b=XZf5V+53RdzPLC/I3FHcERYyM8hxVodFNo5Am2e2hRh+Pre1GMIH1shUKvsaTM8mqpv2HCL9LfAUCoyg8UZIi9cglD/8LUirEt4EsvGQFAzssKzJwlFFH94quXlFqsBwavd/TDJ7rszy03kfv0xF3MSwdQqqJGCDepqZt+RCqvI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1558888142; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=YA/vBAJmNDYR9UFCIli18ReLELmnIhEelkNJpwYltC8=; b=PaKziRIYtBkgddoL/2wjtuGZI6os6dWeVu7jGH6FVyL20KptCF+5fSqW+5Snt3tiQtTDvwXPEOub6mzsx70rsexpwckukM7h34BKCzkM6U6nHH/D7+DUs4pkDnlMk2e5irKsQvZ0tnHR2yiUoKBCE/gIXJhaoLp2QxfzWn9kirs= 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 155888814108485.17190566513978; Sun, 26 May 2019 09:29:01 -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 00:28:57 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <253DB697-BECF-4D68-8A1E-1549B52D5AFA@xbt.hk> References: <6DFB6C65-D123-40FD-9CE3-49FFCA81EE46@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:39 +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 16:29:04 -0000 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. 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. > 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