public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] soft-fork security (Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!)
@ 2015-10-07 23:07 Adam Back
  0 siblings, 0 replies; only message in thread
From: Adam Back @ 2015-10-07 23:07 UTC (permalink / raw)
  To: Jonathan Toomim (Toomim Bros)
  Cc: Jonathan Toomim (Toomim Bros) via bitcoin-dev, Anthony Towns

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


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2015-10-07 23:07 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-07 23:07 [bitcoin-dev] soft-fork security (Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!) Adam Back

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox