[bitcoin-dev] summarising security assumptions (re cost metrics)

Adam Back adam at cypherspace.org
Fri Nov 6 14:08:10 UTC 2015

You're right that it is better that there be more APIs than fewer,
that is less of a single point of failure.  It also depends what you
mean by APIs: using an API to have a second cross-check of information
is quite different to building a wallet or business that only
interfaces with the blockchain via a 3rd party API.  There are
different APIs also: some are additive eg they add a second signature
via multisig, but even those models while better can still be a mixed
story for security, if the user is not also checking their own
full-node or checking SPV to make the first signature.

Power users and businesses using APIs instead of running a full-node,
or instead of doing SPV checks, should be clear about the API and what
security they are delegating to a third party, and whether they have a
reason to trust the governance and security competence of the third
party: in the simplest case it can reduce their and their users
security below SPV.

The bigger point however, which Erik explained, was: widespread use of
APIs as a sole means of interfacing with the blockchain also
contributes to reducing network security for everyone, because it
erodes the consensus rule validation security described under
"Validators" in the OP.


On 6 November 2015 at 09:05, Chris Priest <cp368202 at ohiou.edu> wrote:
> On 11/5/15, Eric Voskuil via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote:
>>> ...
>>> Validators: Economically dependent full nodes are an important part of
>>> Bitcoin's security model because they assure Bitcoin security by
>>> enforcing consensus rules.  While full nodes do not have orphan
>>> risk, we also dont want maliciously crafted blocks with pathological
>>> validation cost to erode security by knocking reasonable spec full
>>> nodes off the network on CPU (or bandwidth grounds).
>>> ...
>>> Validators vs Miner decentralisation balance:
>>> There is a tradeoff where we can tolerate weak miner decentralisation
>>> if we can rely on good validator decentralisation or vice versa.  But
>>> both being weak is risky.  Currently given mining centralisation
>>> itself is weak, that makes validator decentralisation a critical
>>> remaining defence - ie security depends more on validator
>>> decentralisation than it would if mining decentralisation was in a
>>> better shape.
>> This side of the security model seems underappreciated, if not poorly
>> understood. Weakening is not just occurring because of the proliferation
>> of non-validating wallet software and centralized (web) wallets, but
>> also centralized Bitcoin APIs.
>> Over time developers tend to settle on a couple of API providers for a
>> given problem. Bing and Google for search and mapping, for example. All
>> applications and users of them, depending on an API service, reduce to a
>> single validator. Imagine most Bitcoin applications built on the
>> equivalent of Bing and Google.
>> e
> I disagree. I think blockchain APIs are a good thing for
> decentralization. There aren't just 3 or 4 blockexplorer APIs out
> there, there are dozens. Each API returns essentially the same data,
> so they are all interchangeable. Take a look at this python package:
> https://github.com/priestc/moneywagon

More information about the bitcoin-dev mailing list