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"...
next parent 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 ` 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$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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