1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E2009412
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <pete@petertodd.org>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20160818030038.GA12001@fedora-21-dvm>
References: <1736097121.90204.1471369988809@privateemail.com>
<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
<976728541.94211.1471402973613@privateemail.com>
<201608170440.35767.luke@dashjr.org>
<703193091.96057.1471428948569@privateemail.com>
<CAKzdR-qmL0Em058ama8CyAONrY2TbCSU7_SbfKoDEy0ZwnsFBA@mail.gmail.com>
<CAAS2fgQ=Z+xmg0DcANV4vhp+XhpL1Vz0HNkJwNGdHTxtK1q1kg@mail.gmail.com>
<CAKzdR-peLkVqdrnQS61J=H4e4N5dAnXa_+UzXR4cGPsjn=cWHw@mail.gmail.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: <CAKzdR-peLkVqdrnQS61J=H4e4N5dAnXa_+UzXR4cGPsjn=cWHw@mail.gmail.com>
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 <gmaxwell@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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--
|
