
On the dangers of a blockchain monoculture - bascule
https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoculture
======
nickpsecurity
Refreshing to see a critique talking alternatives instead of another fanboy
post on Bitcoin's blockchain. Monoculture is a good word for it. Almost all
the research and attention is going in one direction when there are _many_
valid directions worth exploring with _fewer_ issues than Bitcoin. Some
leverage proven approaches in finance, databases, or transaction processing.
Just need extensions, more analysis, open implementations, etc.

So, I look forward to more articles like this to draw attention to solutions
other than Bitcoin architecture. Another thing I look forward to are links to
interesting alternatives like SCP and Interledger in this. I haven't reviewed
them yet but brief descriptions seemed more exciting than "Cut-and-Pasted-Coin
launched yesterday while promising to change the world."

~~~
brighton36
If there's no work - it's not a blockchain. Distributed ledgers are a
completely parrallel movement that was taken up by those who wanted to
leverage the marketing momentum of blockchain, for their own database
projects. Which is fine, but shouldn't get confused with blockchain
innovations.

~~~
mikeyouse
There can be proof-of-stake blockchains, proof-of-use, proof-of-minimum-aged-
time, etc. etc. The blockchain is just a chain of blocks, there are
innumerable ways to protect it, verify it, and distribute the data.

~~~
brighton36
If the blockchain is just a chain of blocks, then every database designed
after 1985 is also a blockchain. Is that what you believe?

Also- proof of stake always forks due to work attacks, so that's probably not
a secured database.

~~~
mikeyouse
I think the core value of a blockchain (as opposed to any general database) is
that the most recent blocks contain a hash of the state of the system up to
that point. This provides a tamper-resistant historical record of what's
occurred previously.

I think your second point is what some of the critics of the bitcoin obsession
are talking about. Not every blockchain _needs_ to be as attack-resistant as
the bitcoin network. Many of the speculative blockchain uses like for the
Internet of Things could benefit from a history of all transactions but don't
depend on it. Proof-of-stake might work fine for many cases.

~~~
CyberDildonics
What you are describing has been a core of any ledger/immutable database. It
isn't new and in fact has been around for ages. You don't really think a bank
keeps all you money in a sacred database cell do you?

~~~
lmm
Plenty of banks use pretty horrifying technology. Append-only databases have
been a cool research project for ages but I've never seen one in production.

~~~
lambdadmitry
You can find some here:
[http://www.datomic.com/customers.html](http://www.datomic.com/customers.html)

~~~
lmm
Are any of those dividend-paying companies? At the risk of no true
scotsmanning, I wouldn't count it as "production" if the company isn't making
money off it yet.

------
geofft
It took me a while to understand why Certificate Transparency is sound without
requiring proof-of-work, and Bitcoin is not, but the answer turns out to be
fairly simple: you can merge two CT log entries without conflicts, but you
can't merge two Bitcoin transactions. If I want to log "Certificate A exists
for bitcoin.org" and you want to log "Certificate B exists for mtgox.com",
both of our data items are valid on their own (and can be independently
verified, just by checking the signature on the cert) and the ordering doesn't
matter. So as soon as a write goes to _some_ log server, as long as I trust
the log server to propagate writes via the gossip protocol, I'm done; I don't
need to care about merges or retries. (Also, it's possible for the log server
to send me a signed promise to propagate writes, that I can later use to prove
its misbehavior if that entry never shows up.)

On the other hand, if I have a transaction "Transfer 1 BTC to bitcoin.org" and
you have a transaction "Transfer 1 BTC to mtgox.com", they don't necessarily
commute or merge because of the double-spend problem: they might both be
trying to spend the same 1 BTC.

There are a number of nifty decentralized systems you can build that don't
have to think about double-spend problem, where all transactions
commute/merge. Associating names with public keys _seems_ to be one of them,
as long as you allow a name to be validly bound to multiple keys. (A Keybase-
style binding of external service usernames to public keys would permit this,
since you simply have multiple valid Keybase proofs; the external usernames
are arbitrated by the various centralized services. A Namecoin-style approach
doesn't, since names are first-come-first-serve, and you don't want multiple
people to be served the same name.)

There appear to be ways to make a money-transfer system avoid the double-spend
problem: as I understand Stellar, it simply just makes the spending account
legitimately owe both people money (and puts limits on how much each link can
transfer at a time, so that the money is actually recoverable). But for non-
money-transfer systems, if you can arrange your problem statement such that
double-spending isn't a concern in the first place, you can use regular Merkle
trees and avoid the entire proof-of-work overhead.

~~~
murbard2
Blockchains can count, and thus handle mutations. That's the key difference:

[https://medium.com/@arthurb/what-do-blockchains-
accomplish-e...](https://medium.com/@arthurb/what-do-blockchains-
accomplish-e9a5efa246bf)

~~~
geofft
Thanks, that post is very clear.

------
thescriptkiddie
Roughly half of the author's criticisms of the bitcoin blockchain are just
growing pains, which will solve themselves with time. The other half are just
feature requests that are outside of the blockchain's scope. Blockchains are
distributed consensus networks, not databases. It's like asking MySQL to fix
email spam.

------
tracker1
At least now I have something resembling an understanding of how this is being
applied. The concept always seemed a bit odd when I'd hear how banking
establishments planned to use bitcoin for contract transactions, etc, without
bitcoin being the currency of the transaction.

Such a bad implementation of a potentially good idea.

------
kushti
Blockchain shouldn't include Proof-of-Work. Proof-of-Retrievability at least
provides the same properties(paper:
[http://cs.umd.edu/~amiller/permacoin.pdf](http://cs.umd.edu/~amiller/permacoin.pdf)
impl: [https://github.com/ScorexProject/Scorex-
Lagonaki/tree/master...](https://github.com/ScorexProject/Scorex-
Lagonaki/tree/master/scorex-perma) ). And Proof-of-Stake also could do the
same under some assumptions(please see a new paper of mine
[http://arxiv.org/abs/1601.00275](http://arxiv.org/abs/1601.00275) ). Formal
model of a lottery with anti-Sybil identity tools is definitely needed to
shape borders.

------
brudgers
Bitcoin is one protocol that establishes trust between two parties for an arms
length transaction. That it uses cryptographic hashing is an implementation
detail to the same degree that pieces of paper are an implementation detail of
Wells Fargo money orders. What matters is that one person can reliably pay
another person. The fact that people speculate on Bitcoin and not on Wells
Fargo money orders should not cloud our thinking.

The Bitcoin protocol strives for absolute consistency to mitigate risk. Other
cryptographic hash based protocols that are described as "blockchains" may
trade the overhead of absolute consistency for speed and lower computational
overhead, e.g. Ripple [1] uses consensus between `n - c*n` nodes as the basis
of trust along with transaction costs to mitigate the odds of Byzantine
failure that would result in double spend; in exchange transactions execute
more rapidly and with less computational overhead. Again, there's nothing
magical about the implementation details. What matters is reliable trusted
transactions of value. Bitcoin transfers can happen on the order of minutes,
Ripple transactions can happen on the order of seconds.

What technologies that are described as "blockchains" tend to provide is low
transaction fees. The time and expense of moving value via blockchain from
Berlin to Cartagena is low compared to wire transfer independent of the
blockchain's provenance...provided of course that the end units of the
exchange are suitable to all parties. There's nothing magical beyond it being
easier than using goats as the medium of exchange.

[1]: [https://ripple.com/](https://ripple.com/)

~~~
XorNot
People seem to vastly over-estimate the time and expense of moving money
internationally. It is not difficult, nor expensive at the moment. Bitcoin has
very poor liquidity and enormous volatility compared to regular currencies at
scale.

~~~
brudgers
Volatility doesn't matter much if Bitcoin is just a medium for transferring
value within a transaction in normal business circumstances, i.e. slight
fluctuations in exchange rates over the course of an hour can be built into
the offer. Forex style arbitrage and speculative investments are of course
another matter...one in which Bitcoin is no different from other currencies.

The liquidity constraints of Bitcoin may ultimately limit its general adoption
and perhaps encourages speculation over use. And is why, despite my lack of
clarity, I did not intend to suggest that Bitcoin was better than Wells Fargo
money orders for moving money internationally. That doesn't mean that
blockchains may not prove to be significantly better.

~~~
erikpukinskis
I agree liquidity is a weakness.

However it's a classic disruptive technology scenario. Bitcoin is weaker than
other currencies in almost every way, but it has its few very special
advantages.

For now the only users are people for whom those advantages are paramount.
That small group of dedicated users will use it dedicatedly and slowly the
ecosystem builds up around it until other limitations are mitigated.

At that point we'll need to reassess its competitiveness.

------
yarrel
"But perhaps my concerns are overblown"

They're certainly not new or unaddressed. Or politically neutral within
Bitcoin.

------
derefr
So, a blockchain is just a special kind of distributed ledger; and a ledger is
just a particular thing to store in a distributed database. What makes a
blockchain special (and thus, I think, what informs the common usage more than
any technical definition involving proofs of work) is basically what it
accomplishes, that a regular distributed database cannot: a blockchain allows
N mutually-untrustworthy parties—that is, people who would pick one-anothers'
pockets if they could—to co-author a history they're all happy with, without
having to put their trust in any particular party (who, again, might want to
pick everyone's pockets), but instead only in the system as a whole.

My favorite comparison is to leaderboard ranking in competitive games (let's
use Starcraft 2 as an example.) This is another place where everyone would
love to cheat if they could.

Let's say you set up a blockchain where each "transaction" contained someone's
SCII 1v1 gameplay-record from their perspective (i.e. their own input events,
and the received network movement- and action-events from their opponent) for
a ladder match they played. You'd get two "transactions" in a pair for each
match—each submitted by one player—and each one would would move the players'
ladder rankings and leaderboard positions around (though in an idempotent way,
if both records happen to be valid.)

In this model, instead of having to have an authoritative "ladder server" that
simulates all the game's physics for the players, or building any sort of
anti-cheating tech into the game-client, each player would just be part of the
_ladder blockchain_ and therefore would "audit" each entered game-record after
the fact, by running the game's physics engine against the gameplay-records to
determine their validity, and translating the valid records into changes in
the ladder-ledger.

Every player that bothers to run the ladder-chain daemon (which might-as-well
just be embedded into the game-client as a nice'd background process) would be
auditing every other player's game-record for physics discrepancies. Records
from matches where either player was using a hacked game-client would simply
be dropped from history rather than affecting the ladder (or could be encoded
as a forfeit for the hacker.)

The game's manufacturer _could_ have server-nodes of their own, purely for
auditing—but they likely wouldn't need to. In fact, there wouldn't even need
to _be_ a game company; the game could be completely abandonware with no
server infrastructure, yet the ladder and leaderboard system would continue to
function indefinitely.

The properties that let you do this are what make a blockchain a blockchain.
The other properties are implementation details.

------
kanzure
Article seems to quickly call "Lightning Network" a "sidechain". Not only is
this wrong, it's similar to calling "zero-confirmation Bitcoin transactions" a
"sidechain". It's not anything like a sidechain. Examine the evidence
yourself,

sidechains:
[http://blockstream.com/sidechains.pdf](http://blockstream.com/sidechains.pdf)

Lightning Network stuff:
[http://lightning.network/](http://lightning.network/) like
[http://lightning.network/lightning-network-
paper.pdf](http://lightning.network/lightning-network-paper.pdf)

For a high-level overview of Bitcoin scalability proposals, see my 2015
scalingbitcoin.org Montreal presentation:
[http://diyhpl.us/~bryan/irc/bitcoin/scalingbitcoin-
review.pd...](http://diyhpl.us/~bryan/irc/bitcoin/scalingbitcoin-review.pdf)

Lightning Network and Bitcoin payment channels are more like restrictions
around the permissible possible undefined behavior of zero-confirmation
transactions (which otherwise have more broadly undefined behavior), which are
inherently unconfirmed in the Bitcoin system. By using an initial committed
transaction, rules around the behavior of zero-conf transactions spending the
UTXOs can be locked down, while still using Bitcoin transactions, not a
separate consensus system and not a sidechain.

For an overview of criticism regarding the "consensus" mechanism in non-
fuggerian Ripple (aka Ripple 2?) and Stellar, see
[https://news.ycombinator.com/item?id=9342348](https://news.ycombinator.com/item?id=9342348)
and [https://botbot.me/freenode/bitcoin-
wizards/msg/36135395/](https://botbot.me/freenode/bitcoin-
wizards/msg/36135395/)

For an overview of why proof-of-stake doesn't sem to be secure, see
[https://download.wpsoftware.net/bitcoin/pos.pdf](https://download.wpsoftware.net/bitcoin/pos.pdf)
and
[https://download.wpsoftware.net/bitcoin/alts.pdf](https://download.wpsoftware.net/bitcoin/alts.pdf)
and [https://download.wpsoftware.net/bitcoin/asic-
faq.pdf](https://download.wpsoftware.net/bitcoin/asic-faq.pdf)

For an overview of what Bitcoin Core developers are working on regarding
capacity increases, see the recent [https://bitcoin.org/en/bitcoin-
core/capacity-increases-faq](https://bitcoin.org/en/bitcoin-core/capacity-
increases-faq) which is regarding
[https://lists.linuxfoundation.org/pipermail/bitcoin-
dev/2015...](https://lists.linuxfoundation.org/pipermail/bitcoin-
dev/2015-December/011865.html)

------
jaekwon
Tendermint founder here. What we're doing with Tendermint _is_ creating a new
protocol. See TMSP from the tutorial from Tendermint.

[http://tendermint.com/posts/tendermint-socket-
protocol/](http://tendermint.com/posts/tendermint-socket-protocol/)

Yes, we're moving away from "PoS" from the time being, because our clients are
more interested in posting collateral external to the blockchain. That said,
the original security properties still hold. It's the combination of three
things that create security on a non-PoW blockchain, for Tendermint.

* Validators have posted collateral (either on chain or off chain) that is not immediately transferrable, so there is something at stake.

* The BFT consensus algorithm ensures that at least +1/3 of validators must deviate from the protocol to attack the network.

* If there is a fork, then we can find out who had caused the fork. The validator-set is held accountable.

That hasn't changed. What has changed is our client base. We don't want to
launch a cryptocurrency ourselves because as US/Canadian residents, that's a
legal gray area. On the other hand, fin-tech clients and banks _are_
interested in utilizing this technology for creating a distributed multi-write
database. Thus the change in direction.

That said, we're very much interested in support the original PoS design.
Other designs as well. For example, we're building out an experimental
governance app that allows for arbitrary proposals. Perhaps we can use that to
empower users or designated administrator groups to decide on updates to the
validator set.

[https://github.com/tendermint/governmint](https://github.com/tendermint/governmint)

There are many ways to update the validator-set, PoS just being one of them.
We will build out our platform to accommodate a wide variety of strategies for
managing the validator set. For all strategies, they will make use of our
robust BFT consensus algo.

Finally, there are sound technical reasons why a BFT ledger should utilize a
hash-chain of blocks (list of txs). It is both a speed optimization
(validators only need to sign block hashes, not each tx) as well as a security
requirement. To expound on the latter, note that the original PBFT
implementation does not provide any guarantees when more than 1/3 are
Byzantine (see
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.9617&rep=rep1&type=pdf)).
But the hash-chain ensures fork consistency. So there you have it, a chain of
blocks of transactions is fundamentally important for non-PoW ledgers. That's
why we use the term "blockchains".

------
kang
> or some transactions could be moved to “sidechains” as proposed in systems
> like the Bitcoin Lightning Network. But the Lightning Network is useful only
> for a ledger that is denominated in Bitcoin, and we still have to deal with
> the “central” Bitcoin blockchain, whose size is likely to continue to
> increase despite the addition of various “sidechain” mechanisms.

This is incorrect for multiple reasons.

> "Takes over 10 minutes to “commit” a transaction"

Incorrect. Average wait time would be less than 5 minutes.

> "Turning your Bitcoins into cold hard cash denominated in the currency of
> your choice is perhaps the cryptocurrency’s biggest problem"

It is author's world view based on pre-bitcoin times that cold hard cash is
better. It can be said that turning cash to bitcoins is fiat's biggest
problem.

>"moving money between ledgers actually involves integrating with those ugly
legacy systems"

Assets on different blockchains can be swapped using various methods and does
not need third parties.

> "there are far more efficient distributed consensus algorithms than this
> which don’t involve a proof of work."

Author gives the example of Interledger and SCP. Without proof-of-work origin
of money will always be controversial. Both Ripple and SCP create money out of
thin air.

>a very cool feature I will acknowledge exists and give a quick hat tip to
Ethereum

There is NOTHING that ethereum can do that you can't do with bitcoin.

> Bitcoin-NG (paper), a protocol that inverts the ordering of Bitcoin
> consensus: a miner is first elected leader by winning the proof-of-work
> “lottery” by mining a “key block”, and then once elected leader becomes a
> transaction broker who can mint “micro-blocks” via digital signature until
> the next leader is elected.

Many problems linked
[https://www.reddit.com/r/Bitcoin/comments/3or365/bitcoinng_p...](https://www.reddit.com/r/Bitcoin/comments/3or365/bitcoinng_proposal_for_a_secure_faster_better/cvzoha1)

I did not read last 3 paras. The author is damn right that Blockchains are
world's shittiest databases and should not be used so.

In my personal understanding of what blockchain is, the author didn't mention
it as a DMMS(Dynamic membership multiparty signature). This has been explained
in the sidechains whitepaper, which most people do not read due to another
myth that the employees of a private company 'blockstream' are majority of
Bitcoin Core devs. Anyone trying to understand the blockchain should read the
introduction of that paper.
[https://www.blockstream.com/sidechains.pdf](https://www.blockstream.com/sidechains.pdf)

~~~
geofft
> Both Ripple and SCP create money out of thin air.

So does fiat, and fiat _works_. It may not work well all the time for 100% of
use cases, but in general it works well.

As long as the mechanisms by which money is created out of thin air are well-
understood by the people receiving this money (which they are for fiat) and
the recipients give informed consent to that (which they... sorta do for
fiat), this doesn't seem like a negative.

~~~
XorNot
Fiat money works because governments pay for services in it, and demand taxes
in it.

If you are not a government, fiat money does not work for you.*

* Quasi-government entities have a long history of issuing currency like this - company scrip was one such practice, but its important to note that this is a situation of a company becoming more government-like.

~~~
geofft
I'm a little confused, I think I paid for groceries last night in fiat
currency and I certainly got goods in exchange for them, and I don't believe
the grocery store was run by the government. Can you clarify what you mean by
"does not work for you"? I suspect we mean different things by the phrase.

~~~
XorNot
The general "you". You (some entity) can't issue your own fiat currency
successfully unless you are sufficiently government-like.

~~~
geofft
Sure, but a) I have no interest in _issuing_ Bitcoin or any other currency,
just using it as long as it works, and b) if I were to issue an altcoin, I
would be creating money out of thin air!

------
sarciszewski

        †Note to “that guy” on Hacker News: yes, there were cryptocurrencies before 
        Bitcoin. I’m aware. You don’t need to educate me on them. But they don’t count, 
        sorry.
    

[https://www.youtube.com/watch?v=bMOzvxQHywM](https://www.youtube.com/watch?v=bMOzvxQHywM)

~~~
nickpsecurity
Btw, did you know that... in addition to cryptocurrencies... there were
distributed, resilient database and transaction processing designs without
Bitcoin's biggest problems (esp scalability & commit time)? And that people
ignored them until a large gold rush appeared in 2008 using a clever, but
inefficient, version of the ideas? And it took many years for people to
rediscover some of the old work and start making wiser investments of
developer time?

I know, it all blew my mind too.

~~~
erikpukinskis
This would be a valuable comment if you included names. As it is the only
thing I can glean from this is that you know things other people don't?

I guess... congratulations?

~~~
nickpsecurity
Can't do that _every_ Bitcoin post on HN as too little time. Instead, I
included some of the terms to Google in that and other comments here. Googling
such things, especially with "pdf," is how I found the work. Following the
references and related work sections helps, too.

Doing their homework for them just ain't productive. Not people riding a fad
that is.

Note: A quick Google in response to one comment here led me to two, new papers
with one having pretty awesome properties. Just goes to show how easy it is.

