public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Sergio Lerner <sergiolerner@certimix.com>
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
Date: Tue, 07 Oct 2014 16:04:40 -0300	[thread overview]
Message-ID: <54343948.1030400@certimix.com> (raw)
In-Reply-To: <543438E4.8080501@certimix.com>



On 06/10/2014 08:43 p.m., Tom Harding wrote:
> On 10/5/2014 4:00 PM, Sergio Lerner wrote:
>> If everyone acts rationally in his own interest, then the best choice
>> for the remaining miners is to try to mine a competing block at the
>> same height n including the high-fee transaction, to collect the fee
>> for themselves.
>
> Sergio --
>
> Just some thoughts on your interesting problem.
>
>
> Since everybody but M10 is on equal footing, I would expect M10 to
> have some fixed advantage depending on assumptions, and the bigger the
> advantage, the shorter the "freeze time".
>

Yes, that's how simulation works. The problem is that the existence of
high-fee delays the decision to switch to M10. Since the network is
moving slower (because of fragmentation) the effect of the high-fee is
twofold: it delays the convergence because it promotes selfishness and
it delays convergence because it promotes fragmentation.

During that time window where the network is frozen, any other high-fee
transaction only makes things worse.  This is a very rare example where
a well distributed network (100 miners having 1% each) is much much
worse than 3 miners having 33% each.

Using the my previous terminology, automatic fee-sharing ("ORBS") is a
solution to the freeze problem ("FRONT") but opens the windows to
"CHAKIDO" double-spending. and CHAKIDO double-spending is a much worse
problem than FRONT.
But as Tamas pointed out, sooner or later someone will implement
something like ORBS, get over the critical mass of miner adoption, and
then the CHAKIDO problem will be inevitable.

The only clean solution to this problem is the DECOR+ protocol, which
shares block-rewards by including "uncles" (as GHOST does) and splitting
the reward between all miners at the same height until coinbase maturity
is over. This way the best choice is always cooperative.

PS: Using so many acronyms makes arguments much more concise, but
suggest we should have all the attack terminology described in a single
"Bitcoin Security Wiki"...
















       reply	other threads:[~2014-10-07 19:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <543438E4.8080501@certimix.com>
2014-10-07 19:04 ` Sergio Lerner [this message]
2014-10-07 19:16   ` [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT) Gregory Maxwell
2014-10-07 20:04     ` Sergio Lerner
2014-10-08 10:19       ` Mike Hearn
2014-10-05 23:00 Sergio Lerner
2014-10-05 23:40 ` Gregory Maxwell
2014-10-05 23:50   ` Gregory Maxwell
2014-10-05 23:54   ` Jorge Timón
2014-10-06  0:01     ` Gregory Maxwell
2014-10-06 11:02       ` Mike Hearn
2014-10-06 12:22         ` Tamas Blummer
2014-10-06  6:42 ` Alex Mizrahi
2014-10-06 13:21   ` Sergio Lerner
2014-10-06 13:29     ` Tamas Blummer

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=54343948.1030400@certimix.com \
    --to=sergiolerner@certimix.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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