From: Peter Todd <pete@petertodd•org>
To: Sergio Demian Lerner <sergio.d.lerner@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Gregory Maxwell <gmaxwell@gmail•com>
Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
Date: Wed, 17 Aug 2016 20:00:38 -0700 [thread overview]
Message-ID: <20160818030038.GA12001@fedora-21-dvm> (raw)
In-Reply-To: <CAKzdR-peLkVqdrnQS61J=H4e4N5dAnXa_+UzXR4cGPsjn=cWHw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]
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 mined
> (SPV verification), then it may expect the witness program to be of certain
> 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.
>
> 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.
>
> 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 devices
doing lite-client verification don't need to get witness data at all to verify
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).
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2016-08-18 3:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-16 17:53 Johnson Lau
2016-08-16 19:37 ` Luke Dashjr
2016-08-16 19:43 ` Peter Todd
2016-08-16 21:58 ` Joseph Poon
2016-08-16 22:23 ` Russell O'Connor
2016-08-16 22:30 ` Pieter Wuille
2016-08-16 22:36 ` Russell O'Connor
2016-08-16 22:39 ` Pieter Wuille
2016-08-16 22:52 ` Russell O'Connor
2016-08-17 0:18 ` Gregory Maxwell
2016-08-17 0:27 ` Russell O'Connor
2016-08-17 2:30 ` Peter Todd
2016-08-17 3:02 ` Johnson Lau
2016-08-17 4:40 ` Luke Dashjr
2016-08-17 10:15 ` Johnson Lau
2016-08-18 0:11 ` Sergio Demian Lerner
[not found] ` <CAAS2fgQ=Z+xmg0DcANV4vhp+XhpL1Vz0HNkJwNGdHTxtK1q1kg@mail.gmail.com>
2016-08-18 0:33 ` Sergio Demian Lerner
2016-08-18 3:00 ` Peter Todd [this message]
2016-09-05 14:55 ` Russell O'Connor
2016-09-01 11:39 ` Johnson Lau
2016-09-05 1:32 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160818030038.GA12001@fedora-21-dvm \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmaxwell@gmail$(echo .)com \
--cc=sergio.d.lerner@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox