Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5A684DC1 for ; Mon, 21 Dec 2015 15:48:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D39A1CB for ; Mon, 21 Dec 2015 15:48:23 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id to18so38264098igc.0 for ; Mon, 21 Dec 2015 07:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=zhuVowJxrs0cYWLxgkSc2H8FkGDPMqHcmkvPP5QdYPQ=; b=qBNFov8+zq4LH79rHW1mWtim2gYwdU1WxFtpj+/8QB1hmySYUz9XkODZox8dAIVFs3 w5gWd78qtS9QlYfU+Es48btmbhSXYeOEw+YxmCr7UhTsQezYFDeT+GFGhWPEk0+7j6Wl UCGvpNYA3Kj17EiQC3pnlSKDqSd+2DwsZVCtc4Rlx8aa0XjdfQTTfw4b2MkE1Kr3r0eY 5L9LuJcJE8rSC6NpzVyTH/29C31mHaHeVm7L1rCLL8ZQFuLbNEkqivUwv+/WjiSIqY3i LI4iQ7aTd/yFuXFcPDMe7SY4PiG+FY4oJoQ3cvCMVh5Sbs6jQkThpdxcqlTRFKyvsGYn 3rlQ== MIME-Version: 1.0 X-Received: by 10.50.129.99 with SMTP id nv3mr8585974igb.96.1450712903354; Mon, 21 Dec 2015 07:48:23 -0800 (PST) Received: by 10.79.77.75 with HTTP; Mon, 21 Dec 2015 07:48:23 -0800 (PST) In-Reply-To: <537b176b25a681255eee5f6c4268ab6e@xbt.hk> References: <537b176b25a681255eee5f6c4268ab6e@xbt.hk> Date: Mon, 21 Dec 2015 15:48:23 +0000 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7b3a91e646906705276a6b62 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] A new payment address format for segregated witness or not? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 15:48:24 -0000 --047d7b3a91e646906705276a6b62 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 21, 2015 at 5:14 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The SW in P2SH is worse in terms of: > 1. It requires an additional push in scriptSig, which is not prunable in > transmission, and is counted as part of the core block size > "Prunable in transmission" means that you have to include it when not sending the witnesses? That is a name collision with UTXO set prunable. My initial thought when reading that was "but scriptSigs are inherently prunable, it is scriptPubKeys that have to be held in the UTXO database" until I saw the "in transmission" clarification. --047d7b3a91e646906705276a6b62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 21, 2015 at 5:14 AM, jl2012 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
The SW in P2SH is worse in terms of:
1. It requires an additional push in scriptSig, which is not prunable in tr= ansmission, and is counted as part of the core block size
<= div>
"Prunable in transmission" means that you have= to include it when not sending the witnesses?

That is a = name collision with UTXO set prunable.=C2=A0 My initial thought when readin= g that was "but scriptSigs are inherently prunable, it is scriptPubKey= s that have to be held in the UTXO database" until I saw the "in = transmission" clarification.
--047d7b3a91e646906705276a6b62--