public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: Chris Pacia <ctpacia@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
Date: Tue, 30 Jun 2015 10:53:09 -0400	[thread overview]
Message-ID: <20150630145309.GC17984@savin.petertodd.org> (raw)
In-Reply-To: <55929E7F.8020301@gmail.com>

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

On Tue, Jun 30, 2015 at 09:49:51AM -0400, Chris Pacia wrote:
> 
> 
> On 06/30/2015 09:12 AM, Adam Back wrote:
> > It is correct to view first-seen miner and relay policy as
> > honour-based, though it is the current default.
> >
> >
> What would be the effect of IBLT on the first seen policy? It seems that
> if a miner has to broadcast extra data with his blocks because he's
> using full RBF and everyone else is using first-seen then his blocks are
> at a disadvantage in terms of propagation. That wouldn't make first-seen
> a hard consensus rule, but rather one rational miners are likely to
> follow. Or is this effect likely to be minimal?

The disadvantage can be calculated compensated for by higher fees; if
the disadvantage is so large that the higher fees are unaffordable we're
in big trouble as the guarantees that mempools are in sync are pretty
poor. (why doublespending zeroconf txs is easy!) For instance, that'd
imply that sending two simultaneous transactions will cause profit
losses to all but the largest miners - who are unaffected - and that
upgrades that change IsStandard() will cause profit losses, among many
other problems.

Bitcoin just doesn't work if blocks aren't relayed quickly in the worst
case.

-- 
'peter'[:-1]@petertodd.org
00000000000000000c51793e1f2f6b9bd82dd1579b3e4207e70a0aa8fb953c80

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

  reply	other threads:[~2015-06-30 14:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-29  5:07 Peter Todd
2015-06-29  5:40 ` Luke Dashjr
2015-06-29  5:43   ` Gregory Maxwell
2015-06-29  5:51     ` Luke Dashjr
2015-06-29  5:56       ` Peter Todd
2015-06-29  5:53     ` Peter Todd
2015-06-29  6:00       ` Luke Dashjr
2015-06-29  6:16 ` sickpig
2015-06-30  0:21 ` Tom Harding
2015-06-30  0:51   ` Natanael
2015-06-30  1:00     ` Tom Harding
2015-06-30  1:10       ` Natanael
2015-06-30  1:18         ` Tom Harding
2015-06-30  1:37   ` Peter Todd
2015-06-30 13:12     ` Adam Back
2015-06-30 13:49       ` Chris Pacia
2015-06-30 14:53         ` Peter Todd [this message]
2015-06-30 14:02       ` David A. Harding
2015-06-30 16:05       ` Peter Todd
2015-06-30 18:23         ` Chris Pacia

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=20150630145309.GC17984@savin.petertodd.org \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=ctpacia@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