public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Russell O'Connor" <roconnor@blockstream.io>
To: Gregory Maxwell <greg@xiph.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
Date: Tue, 16 Aug 2016 20:27:54 -0400	[thread overview]
Message-ID: <CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgQ66mQQ6Bdcm7C=CSzjkk3CwZCFLdSsDFdiDaRXhLiO=Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]

Okay.

I'm not really opposed to this BIP, but I am worried that fighting script
malleability is a battle that can never be won; even leaving one avenue of
malleability open is probably just as bad as having many avenues of
malleability, so it just doesn't seem worthwhile to me.

On Tue, Aug 16, 2016 at 8:18 PM, Gregory Maxwell <greg@xiph.org> wrote:

> On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I see.
> >
> > But is it really necessary to soft fork over this issue?  Why not just
> make
> > it a relay rule?  Miners are already incentivized to modify transactions
> to
> > drop excess witness data and/or prioritize (versions of) transactions
> based
> > on their cost.  If a miner wants to mine a block with excess witness
> data,
> > it is mostly their own loss.
>
> Relay rules are quite fragile-- people build programs or protocols not
> expecting them to be violated, without proper error handling in those
> cases... and then eventually some miner rips them out because they
> simply don't care about them: not enforcing them won't make their
> blocks invalid.
>
> It's my general view that we should avoid blocking things with relay
> rules unless we think that someday they could be made invalid... not
> necessarily that they will, but that it's plausible. Then the
> elimination at the relay level is just the first exploratory step in
> that direction.
>
> One should also consider adversarial behavior by miners.  For example,
> I can mine blocks with mutated witnesses with a keyed mac that chooses
> the mutation. The key is shared by conspirators or customers, and now
> collectively we have a propagation advantage (since we know the
> mutated version before it shows up).  Not the _biggest_ concern, since
> parties doing this could just create their own new transactions to
> selectively propagate; but doing that would require leaving behind fee
> paying public transactions, while using malleability wouldn't.
>

[-- Attachment #2: Type: text/html, Size: 2545 bytes --]

  reply	other threads:[~2016-08-17  0:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16 17:53 [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH 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 [this message]
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='CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com' \
    --to=roconnor@blockstream.io \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=greg@xiph.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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