From: Justus Ranvier <justus@openbitcoinprivacyproject•org>
To: Monarch <monarch@cock•li>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Your Gmaxwell exchange
Date: Mon, 31 Aug 2015 18:24:25 -0500 [thread overview]
Message-ID: <55E4E229.2030105@openbitcoinprivacyproject.org> (raw)
In-Reply-To: <a02ace48700ff443b8904f14b23486c4@cock.li>
[-- Attachment #1.1: Type: text/plain, Size: 3579 bytes --]
On 08/31/2015 05:53 PM, Monarch wrote:
>
> Bitcoin is a decentralized currency which allows any person the
> ability to transact in a way that does not require specific trust in
> any particular party. Users can independently verify that
> transactions they receive are valid and confirmed, with strong
> confidence that they can not be reversed or modified. A third party
> does not hold these same properties, there is no reason to believe the
> information they present other than trust they will not lie, cheat, or
> violate privacy at their own will. Given information by a trusted
> third party (such as a balance or existance of transaction), a person
> has no ability to independently validate their claims as you do in a
> decentralized system.
This is on the right track, but still falls short in a few areas.
It's a false dichotomy to say that our choices are: Bitcoin as it exists
today (or in some theoretical perfect state of decentralization), or an
Excel spreadsheet edited by a trusted third party who can change any
number to be any other number they want.
Imagine there was only one miner in the network. In spite of being the
sole entity creating the blockchain there would still be many actions
they could *not* do:
* Falsify ECDSA signatures
* Generate proof of work without expending energy
* Produce blocks that non-mining nodes would recognize as including
invalid transactions (including printing themselves unlimited balances)
* Force other people to purchase the coins they mine so that they can
pay their electric bills
What they *can* do is:
* Defraud recipients of transactions by including a payment transaction
in a block, then orphaning that block with another block that contains a
conflicting transaction (double spend).
There is usually*** a cost to performing this attack, so miners would
only be expected to do it if the benefit exceeds the cost.
* Prevent the inclusion of valid transactions into any block using any
criteria they want.
The worse case scenario for mining monopolization is that the risk of
profitable double spends means that transactions might require more
confirmations to be reliable, and that some entity can censor
transactions at will.
Those aren't exactly end-of-the world failure cases. They are certainly
undesirable and every means of preventing them should be investigated,
but it does mean that it should be possible to dial back on the
catastrophe language when analysing possible failure modes.
The weakest area for Bitcoin to be attacked is via censorship enforced
by miners.
The first line of defence is to improve the privacy features of wallets
to the point at which blacklists are not effective. I'm confident that
this can be achieved.
That leaves the censors with the choice of whether or not to escalate to
whitelisting, which ultimately can be countered by users switching to a
new system which does not have that particular anti-feature.
tl;dr: Bitcoin security does not lie on a one-dimensional "centralized
vs decentralized" axis. Treating it as if it does removes the clarity
that is needed in order to effectively solve problems.
***Exploring the exact conditions under which this is true is an
interesting exercise and relevant to long term discussions vis a vis the
block subsidy and transaction fees in the future.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus@openbitcoinprivacyproject•org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2015-08-31 23:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-31 20:06 Monarch
2015-08-31 20:27 ` Justus Ranvier
2015-08-31 20:48 ` Monarch
2015-08-31 21:24 ` Allen Piscitello
2015-08-31 21:42 ` Monarch
2015-08-31 21:54 ` Justus Ranvier
2015-08-31 22:53 ` Monarch
2015-08-31 23:24 ` Justus Ranvier [this message]
2015-09-01 0:02 ` Milly Bitcoin
2015-09-01 9:25 ` Jorge Timón
2015-08-31 23:32 ` Peter R
2015-08-31 23:47 ` s7r
2015-09-01 2:16 ` [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes Peter R
2015-09-01 2:25 ` Gregory Maxwell
2015-09-01 8:42 ` Adam Back
2015-09-01 10:16 ` Chris D'Costa
2015-09-01 11:20 ` Monarch
2015-09-01 12:24 ` Wladimir
2015-09-01 22:06 ` s7r
2015-09-01 11:44 ` [bitcoin-dev] Your Gmaxwell exchange Monarch
2015-09-01 11:11 ` Monarch
2015-09-01 15:59 ` Dave Collins
2015-09-01 16:51 ` Monarch
2015-09-01 18:37 ` Eric Voskuil
2015-09-01 20:08 ` Monarch
[not found] <CAEgR2PFB3h_8fr=d8HegRSD0XdooimhFKtLR4vKr2QXv+EwBfQ@mail.gmail.com>
[not found] ` <AD284610-4F40-445C-A074-CC94EDFFCBA8@gmx.com>
2015-08-30 3:25 ` Gregory Maxwell
2015-08-30 4:13 ` Peter R
2015-08-30 4:57 ` Gregory Maxwell
2015-08-30 6:38 ` Adam Ritter
2015-08-31 18:55 ` Justus Ranvier
2015-08-31 19:11 ` Mike Hearn
2015-09-01 20:29 ` Wladimir J. van der Laan
2015-09-02 18:51 ` Justus Ranvier
2015-09-01 2:30 ` Oliver Petruzel
2015-08-30 7:41 ` Peter R
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=55E4E229.2030105@openbitcoinprivacyproject.org \
--to=justus@openbitcoinprivacyproject$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=monarch@cock$(echo .)li \
/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