MIME-Version: 1.0
Date: Thu, 8 Oct 2015 01:07:48 +0200
Message-ID: <CALqxMTGs7ro5_TeHAQjB_s1qa+GjQcaLrA5QwODCQOOgDPVP6Q@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: "Jonathan Toomim (Toomim Bros)" <j@toom.im>
Content-Type: text/plain; charset=UTF-8
Cc: "Jonathan Toomim \(Toomim Bros\) via bitcoin-dev"
	<bitcoin-dev@lists.linuxfoundation.org>, Anthony Towns <aj@erisian.com.au>
Subject: [bitcoin-dev] soft-fork security (Re: Let's deploy BIP65
	CHECKLOCKTIMEVERIFY!)
Precedence: list

On 7 October 2015 at 18:26, Jonathan Toomim (Toomim Bros) via
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Oct 7, 2015, at 9:02 AM, Eric Lombrozo <elombrozo@gmail.com> wrote:
> If you had a 99% hashpower supermajority on the new version, an attacker
> would still be able to perform this attack once per day.

[ie wait for a non-upgraded miner to win a block]

I dont think that is something strong and new to focus on or worry
about, because in Bitcoin's game theory there are lets say 3 types of
miners we're in aggregate trying to get security from:

a) honest (following protocol) bolstered by financial incentive to
remain honest of subsidy & fees
b) agnostic / lazy (just run software, upgrade when they lose money
and/or get shouted at)
c) dishonest

Bitcoin remains secure with various combinations of percentages.  For
sure you wont have a good time if you assume < 1% are dishonest.

Therefore this attack can already happen, and in fact has.  Users of
bitcoin must behave accordingly with confirmations.

Bitcoin direct is not super secure for unconfirmed (so-called
0-confirm) transactions, or even for 1-confirm transactions.  See also
Finney attack.

That does not prevent people using unconfirmed transactions with risk
scoring, or in high trust settings, or high margin businesses selling
digital artefacts or physical with nominal incremental cost.

But it does mean that one has to keep that in mind.  And it also
motivates lightning network or payment channels (lightning with one
intermediate node vs a network of nodes) - they can provide basically
instant 0-confirm securely, and that seems like the future.

In my opinion anyone relying on unconfirmed transactions needs to
monitor for problems, and have some plan B or workaround if the fraud
rates shoot up (if someone tries to attack it in an organised way),
and also a plan C mid-term plan to do something more robust.  Some
people are less charitable and want to kill unconfirmed transactions
immediately.  The message is the same ultimately.

Adam