public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Sergio Lerner <sergiolerner@certimix•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
Date: Mon, 06 Oct 2014 10:21:15 -0300	[thread overview]
Message-ID: <5432974B.4000606@certimix.com> (raw)
In-Reply-To: <CAE28kUTBbT5_Jh-aP_rVkLYMSdY+XeQO39LFh+EFHqSp-wFXOQ@mail.gmail.com>

Comments between lines...

On 06/10/2014 03:42 a.m., Alex Mizrahi wrote:
> .....
>
> This doesn't require protocol changes(*) and can be simply
> incorporated into a piece of code which decides what to do when a
> transaction with unusually large fee appears. (I.e. it will
> automatically share the fee, and others will recognize that). And if
> the biggest miner has 25% of all hashrate, sharing 25% of your loot
> doesn't sound that bad.
The problem with this approach is that once the bitcoind has been
modified to allow this sharing of the high-tx fee by delegation, then
the same system can be used for an attack.
Let's call a system that makes the Optimum Rational Best-chain Selection
for maximizing profit "ORBS", just to give it a name. The system assures
that the best chain chosen is always the optimum in terms of profit,
taking into account fee delegation and all the game-theoretic incentives
derived. It's only a theoretical abstraction, but could be approximated
in practice.

The attack is called Chained Kickback DOuble-spend attack (or “CHAKIDO”)
and is an extension of Bonneau's kickback attack. Basically the attack
is to create the ORBS patch, and start convincing miners to use it,
sending some probe high-fees tx.
Once you have ORBS working in a majority of the mining nodes, you can
perform a double-spend against a target like an exchange by:
- Buy some btc X
- Send those btc to an exchange (suppose the exchange requires 6
confirmations) in a transaction TX
- Immediately convert those btc to an alt-coin, and collect the alt-coins
- Create a high fee tx that is a double-spend of TX having a high fee Y
such that Y < X but Y triggers a ORBS reorganization.
- Profit
(This rollback attack was performed against whitecoin, I think)

This attack gets terrible powerful if there is no subsidy. You may need
500 blocks of confirmation to protect from a 10 BTC spend with current
fees and no subsidy. This is because once 100% of the nodes use ORBS,
the fee delegation is linear (it doesn't grow exponentially with the
number of blocks). So ORBS should never be implemented without
additional protective measures in merchant applications.
If we had a closed formula for ORBS, then all merchants could compute
the minimum confirmation blocks such that always Y > X, but such formula
involves many unknowns which would need to be dynamically estimated, and
also it should take into account the number of simultaneous payment
attempts.

My conclusions are:
- We should never allow ORBS to be implemented unless merchants are also
aware of it. If are aware of ORBS then Bitcoin with no subsidy will be
become a terrible slow payment system so ...
- We could implement the protections that work even if some nodes
implement ORBS, such as fee and burn btc sharing, as I described before
- Or we need some high percentage of miners to be irrational, to force
ORBS fee delegation have an exponential decay.

Best regards,
Sergio.



  reply	other threads:[~2014-10-06 13:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2014-10-06 13:29     ` Tamas Blummer
     [not found] <543438E4.8080501@certimix.com>
2014-10-07 19:04 ` Sergio Lerner
2014-10-07 19:16   ` Gregory Maxwell
2014-10-07 20:04     ` Sergio Lerner
2014-10-08 10:19       ` Mike Hearn

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=5432974B.4000606@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