public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Russell O'Connor" <roconnor@blockstream.io>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
Date: Mon, 5 Sep 2016 10:55:10 -0400	[thread overview]
Message-ID: <CAMZUoKnNHkUtiwT=PKg25HmiEFZQfXxY8P2G=QZ+NJZBQDTTcg@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBhykn8BU1LAr1izH0z6nFuOv0PzWjuqq7YJX5r35LDa9Q@mail.gmail.com>

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

For sake of example, suppose we have a marginal fee rate of 50 satoshis per
byte.  At that rate reducing the size of the witness data by 1 byte is
approximately equivalent from a miner and relayer's perspective as a
replace by fee that increases the fee by 50 satoshis.  In both cases miners
get an extra potential of 50 satoshis in revenue.

So in this sense replacing witness data with smaller witness data can pay
for its own relay cost as much as RBF can simply by requiring that the
smaller witness be smaller enough to cover the same RBF threshold.

On Tue, Aug 16, 2016 at 6:39 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

> On Aug 17, 2016 00:36, "Russell O'Connor" <roconnor@blockstream.io> wrote:
>
> > Can I already do something similar with replace by fee, or are there
> limits on that?
>
> BIP125 and mempool eviction both require the replacing transaction to have
> higher fee, to compensate for the cost of relaying the replaced
> transaction(s).
>
> --
> Pieter
>

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

  parent reply	other threads:[~2016-09-05 14:55 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
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 [this message]
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='CAMZUoKnNHkUtiwT=PKg25HmiEFZQfXxY8P2G=QZ+NJZBQDTTcg@mail.gmail.com' \
    --to=roconnor@blockstream.io \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pieter.wuille@gmail.com \
    /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