Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E2009412 for ; Thu, 18 Aug 2016 03:00:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149081.authsmtp.net (outmail149081.authsmtp.net [62.13.149.81]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 029351DA for ; Thu, 18 Aug 2016 03:00:47 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u7I30kJD076146; Thu, 18 Aug 2016 04:00:46 +0100 (BST) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u7I30ibE086919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Aug 2016 04:00:44 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 63D3A400A9; Thu, 18 Aug 2016 02:57:34 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 8431A205F5; Wed, 17 Aug 2016 20:00:38 -0700 (PDT) Date: Wed, 17 Aug 2016 20:00:38 -0700 From: Peter Todd To: Sergio Demian Lerner , Bitcoin Protocol Discussion Message-ID: <20160818030038.GA12001@fedora-21-dvm> References: <1736097121.90204.1471369988809@privateemail.com> <976728541.94211.1471402973613@privateemail.com> <201608170440.35767.luke@dashjr.org> <703193091.96057.1471428948569@privateemail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: f515875a-64ef-11e6-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwoUGUATAgsB AmAbW1BeUF17XWY7 bghPaBtcak9QXgdq T0pMXVMcUQIRAhxY VGseWh97dgwIeX54 Y0UsCHVaWUx9cBdg REoBQ3AHZDJmdWgd WRVFdwNVdQJNdxoR b1V5GhFYa3VsNCMk FAgyOXU9MCtqYAJY XUknDGpACWoGFzo9 QR9KAjQzHQUifxIS AVQvLFJUO34mFGIO EHVDEVcRNxsfAwdf G0BREWdYIRE5HRUQ LWsA X-Authentic-SMTP: 61633532353630.1037:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Gregory Maxwell Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH 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: Thu, 18 Aug 2016 03:00:49 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 17, 2016 at 09:33:24PM -0300, Sergio Demian Lerner via bitcoin-= dev wrote: > If I send a transaction to an IoT device (say to an OpenDime or to the old > Firmcoin), and the OpenDime must verify that the transaction has been min= ed > (SPV verification), then it may expect the witness program to be of certa= in > maximum size (an implementation-imposed limit). If a Miner modifies the > witness size and makes it too large, then the device may not be able to > accept the transaction and the bitcoins may be lost. Lost because the > private key is in the device, and because the device cannot accept that > cloned transaction, never ever. >=20 > The same is true (although less strict) for side-chains and drive-chains: > they may have certain restrictions on the size of transactions they accept > to lock bitcoins. >=20 > That's why I'm proposing that a transaction becomes INVALID if the witness > size is higher than the expected size (by the sender). An important part of the design of segwit is that resource constained devic= es doing lite-client verification don't need to get witness data at all to ver= ify lite-client merkle-path proofs. Remember that lite-clients can't verify anything useful in witnesses anyway= , so for them to have witness data is useless (unless they're doing some kind of embedded consensus protocol with data published in witnesses, but few people here care about that use-case). --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXtSTTAAoJEGOZARBE6K+yxkQH/jkeCmYhV2CxVsfFpNBeZTh+ dPfa4DHq6Ug2AhpZE/64iJAhLXHflHBnt9UxIDmmqgiWLJLnSyrzQj20n1anRu+e 8dYRBlg+NPH8e9rNBmMYzMRdpE66gyaselQ7liJO5iooqqWGIfMxSxe2Y2kvIdNr lLF5ZhULwcIEY6gAT0v0wZdxGOclVla92wh6M+E6KoKQV6+zmxOJxXLMGZBEiuc6 d5TYsSYgCtI+T96l57zuxe+BGaBylG9nd9QduyNff2pTekL2I/lv6lOXyWbHtvba C3kV0DrtCi1ewcQXgNOQrOLd0ehYIjIEODPK8wWFXgZyFlLWq73ro2pcypFFhAo= =8dSb -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM--