From: Pieter Wuille <pieter.wuille@gmail•com>
To: "Russell O'Connor" <roconnor@blockstream•io>,
Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
Date: Wed, 17 Aug 2016 00:30:52 +0200 [thread overview]
Message-ID: <CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> If one's goal is to mess with an transaction to prevent it from being
mined, it is more effective to just not relay the transaction rather than
to mess with the witness. Given two transactions with the same txid and
different witness data, miners and good nodes ought to mine/relay the
version with the lower cost (smaller?) witness data.
That implies that everyone will see both versions and be able to make that
choice. Unfortunately, those two versions will be definition be in conflict
with each other, and thus only one will end up paying a fee. We're can't
relay two transactions for the price of one, or we'd expose the p2p network
to a very cheap DDoS attack: just send increasingly small versions of the
same transaction.
Segwit's third party mallebility protection makes it not an issue for
dependent contracts if transactions are mauled (=apparently the verb
related to malleability), but there are still good reasons for senders not
to gratuitously make their transactions extensible in size or other
resources.
--
Pieter
[-- Attachment #2: Type: text/html, Size: 1346 bytes --]
next prev parent reply other threads:[~2016-08-16 22:30 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 [this message]
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
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=CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roconnor@blockstream$(echo .)io \
/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