From: Adam Back <adam@cypherspace•org>
To: "Jonathan Toomim (Toomim Bros)" <j@toom•im>
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!)
Date: Thu, 8 Oct 2015 01:07:48 +0200 [thread overview]
Message-ID: <CALqxMTGs7ro5_TeHAQjB_s1qa+GjQcaLrA5QwODCQOOgDPVP6Q@mail.gmail.com> (raw)
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
reply other threads:[~2015-10-07 23:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=CALqxMTGs7ro5_TeHAQjB_s1qa+GjQcaLrA5QwODCQOOgDPVP6Q@mail.gmail.com \
--to=adam@cypherspace$(echo .)org \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=j@toom$(echo .)im \
/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