
A tale of two cryptocurrencies: Ethereum and Bitcoin’s ongoing challenges - bascule
https://tonyarcieri.com/a-tale-of-two-cryptocurrencies
======
EthanHeilman
>So really “Segregated Witness” is about segregated signatures. Why the wacky
name with the word “witness” then? I’m not sure… I think Bitcoin people just
love inventing jargon.

Witness is standard term in cryptography, Bitcoin people did not invent it.
For instance a signature can be a witness to the fact that you hold a
particular private key[0].

>I am also confused about the security properties of the Lightning Network.
What happens when one of the hubs gets popped? Can someone steal all of the
unsettled transactions? Suddenly this proposed scaling element starts taking
on the security properties of Bitcoin exchanges, which are notorious for being
popped.

If "a hub gets popped" the attacker should be not be able to steal the
unsettled transactions. If we were trusting the hubs, like say how we trust
coinbase, the LN would be much much easier to design.

[0]:
[https://en.wikipedia.org/wiki/Proof_of_knowledge](https://en.wikipedia.org/wiki/Proof_of_knowledge)

------
aminok
>I am also confused about the security properties of the Lightning Network.
What happens when one of the hubs gets popped? Can someone steal all of the
unsettled transactions? Suddenly this proposed scaling element starts taking
on the security properties of Bitcoin exchanges, which are notorious for being
popped.

No, the whole point of LN transactions is that you do not need to trust
intermediary nodes, or 'hubs', as he calls them. Every transactor has a copy
of a valid Bitcoin transaction that will settle payments owed to them and
these debts are collaterized by lock-timed money on the blockchain. It is
theoretically totally secure.

------
darawk
The whole blocksize debate is pretty strong evidence IMO that bitcoin's
leadership is completely broken. They took what was a trivial to implement,
obviously correct (in the sense of program correctness) fix: double the block
limit. And turned it into two complicated solutions that do little to address
the underlying issue.

It's hard to imagine a more clearcut example of exactly the sort of bad
engineering practices that will doom any project.

Ethereum on the other hand has serious issues, but they seem fixable. If
Vitalik is willing to seriously rethink the design of Solidity and make
greater efforts towards formally verifiable contracts, and then they get proof
of stake working, I think there's some chance it could actually achieve some
of the hopes of cryptocurrency enthusiasts. Unfortunately i'm not sure how
willing they are to modify the language to make it more verifiable.

~~~
riprowan
> They took what was a trivial to implement, obviously correct (in the sense
> of program correctness) fix: double the block limit.

Not to mention, 2MB was a _compromise_ from 8MB which was a _compromise_ from
20MB.

Where's the compromise from the other side?

~~~
darawk
Ya. It's absolute silliness. Rushing in these complicated solutions just to
avoid some half-baked slippery slope argument about the block size. You don't
need to keep raising the block size forever, just do it until you have a good,
clean solution to the scaling problem.

~~~
riprowan
Agree about slippery slope. There has been so much misinformation and
propaganda spread that some people are now convinced that a fork to change any
consensus rule could lead to the change of _any_ consensus rule - even the 21M
coin cap. The result is that the community has become polarized and toxic over
something that ought to be noncontroversial.

------
sigil
I tried to read and understand the Lightning Network paper recently. Glad I'm
not the only one:

 _If I’ve gotten anything wrong here, it’s because the Lightning Network is
ridiculously complex: the paper is some 57 pages written in blockchainiac
gobbledygook terminology. I’m the sort of person who reads academic papers for
fun, and can attest that this is not a paper I remotely purport to understand
or enjoyed reading. I think there are very few people on Planet Earth who have
read this paper and understand it._

If you're one of these Very Few People and you're reading this, a question: do
Lightning's channels only reduce on-chain transaction volume in the case of
recurring payments (eg subscriptions)? What is the anticipated savings if the
Lightning Network is rolled out -- how much of current transaction volume
could be handled in channels?

~~~
DennisP
I don't know Bitcoin well enough to understand the LN paper, but I've read
articles on the basic ideas and think I understand enough to implement LN on
Ethereum, where it's much easier.

If channels were not networked together, then they'd only be good for
recurring payments.

But there's a trick that lets you network them, so A can have recurring
payments to B, and B can have recurring payments to C, D, and E, and now A can
pay all the others via his one channel to B. And it's done in a way that
prevents B from being able to run away with money intended for C,D,E.

~~~
RustyRussell
> LN on Ethereum, where it's much easier.

Genuine question? What makes it easier? Thanks!

~~~
zmanian
Bitcoin script provides a no elegant way to invalidate old states. There are
various solutions to this in lightning network tx but they end up requiring
actively watching the network in case an old state is broadcast. If you have a
better mechanism for invalidate the previous state, the whole system can be
massively simplified.

~~~
RustyRussell
You mean, every transaction causes an on-chain ethereum change? That seems to
miss the point?

------
alcio
Tallying pages, flowcharts and formal specifications is no basis for
scientific evaluation.

Coming from a Bitcoin background, I found the Lightning paper quite a
refreshing read compared to pure academia papers. The ideas behind are very
clever, several implementations are under way and implementors are building
interoperability standards along the way ([https://github.com/lightning-
core/lightning](https://github.com/lightning-core/lightning)).

------
j1vms
Somewhat off topic, could someone post a list or examples of non-trivial (or
relatively, non-trivial) decidable languages that have implemented
compilers/interpreters? I should say no requirement on supported hw
architectures, nor currently active development/maintenance.

~~~
grapevines
Agda is a programming language where "each program in it must terminate and
all possible patterns must be matched. Without this feature, the logic behind
the language becomes inconsistent, and it becomes possible to prove arbitrary
statements."

Since all programs terminate, reasoning about arbitrary properties about said
programs becomes decidable.

~~~
j1vms
Thanks for the pointer. It appears that proof assistants [0], like Aqda as you
mentioned and one of its influences Coq [1], have the properties I were
describing and indeed are examples of total functional programming [2].

[0]
[https://en.wikipedia.org/wiki/Proof_assistant](https://en.wikipedia.org/wiki/Proof_assistant)

[1] [https://en.wikipedia.org/wiki/Coq](https://en.wikipedia.org/wiki/Coq)

[2]
[https://en.wikipedia.org/wiki/Total_functional_programming](https://en.wikipedia.org/wiki/Total_functional_programming)

------
Aelinsaar
Bitcoin's challenges seem to be a matter of current implementation, while
Ethereum just seems like a bad idea, implemented as well as a fundamentally
bad idea could be.

~~~
heliumcraft
Ethereum is a platform for decentralised applications, it has far more
pratical use than a simple blockchain like Bitcoin, but far more risks as
well. Give it a chance, it's just starting, there is a lot more development to
do, don't throw it away the first bad thing that happens. Can you imagine if
the early internet architects thought this way? "Oh this computer in the
network got hacked, lets give up on this whole internet thing, it's a
fundamentally bad idea". There will be ups and downs. IMO, right now Ethereum
is the best chance we got at a truly decentralised web.

~~~
timmytokyo
The idea of smart contracts is a good one. The design of this particular
implementation (Ethereum) is a bad one, mostly for the reasons identified in
the original post. The complexity -- and more importantly the undecidability
-- of the contract language ensures that ethereum will never take off as a
working solution. People will never be able to trust that a DAO-like attack
isn't lurking just under the surface of their contracts.

~~~
heliumcraft
Well that's the same with any software and service isn't.. If I put my company
precious data on AWS, there is a chance it will get hacked, it's a matter of
taking precautions and trade offs.

We need to think of better tools & practices to secure contracts. It's still
all new, there will be issues, there will be improvements. The end goal is
worth it IMO. My main Interest in Ethereum (and Maidsafe) like most developers
in the community is not so much money but the dream of having a truly
decentralised web one day. Impossible? maybe, but I'm willing to try.

~~~
nickparker
As I understand it:

It's true of any platform, but Etherium is at a far higher risk of getting
hacked because the language is Turing complete. There could conceivably be a
smart contract blockchain with a simplified language that was still capable of
most of Etherium's good sides with the safety net of static verification
tools.

~~~
heliumcraft
ALL general purpose programming languages (C++, Java, etc..) are Turing
Complete and this is an essential feature for creating decentralised
applications (or any software really).

~~~
PeCaN
Um, no, that's just factually incorrect. You can do very, very many useful
things without Turing completeness. You cannot be fully general, but there's
active research on how far you can get. Restricted subsets of query languages
like SQL and Datalog are perhaps the most common (though more or all SQL
implementations are Turing complete) and indeed quite useful.

I can easily imagine a system built on a non-Turing complete logical query
language that defines data and rules for presentation. You could get pretty
far with that. You can't create _any_ application, but calling Turing
completeness “essential … for decentralized applications” is incorrect. It's
essential for a _subset_ of applications that require Turing completeness.

I've been saying ETH is broken for a while. Its computational ability means
contracts _cannot_ be formally verified. This is why I didn't buy into the
DAO, and sure enough there's a bug in the DAO (ironically recursion related).

~~~
pron
People are under the impression that _not_ being Turing complete is somehow
enough to be feasibly verifiable. If we place (realizable) computational
models on a scale, with 0 being no computation at all, and 10 being Turing
completeness, then the computational models we can generally verify are
somewhere between 0 and 1 (with 1 being, say, FSMs). A language with no loops,
no recursion and just subroutines and binary variables -- i.e. it's an FSM --
is already PSPACE-complete to verify, meaning we can only verify only very
short programs in that language. In other words, you need to get _very_ far
from Turing completeness to be generally verifiable.

This is why in general software verification doesn't try to come up with
languages where _all_ programs are verifiable, but aims to verify specific
programs, sometimes regardless of the computational strength. Some programs in
Turing complete languages can be verified (but certainly not all), just as
some programs in FSM-strength languages can be verified (but certainly not
all).

While it is certainly possible that a much bigger subset of, say, FSM programs
can be verified than a subset of programs in TC languages, placing the bar at
"Turing complete" is somewhat of a red herring.

Indeed, the LANGSEC link in the post[1] seems to understand that, noting that
even verifying PDAs is undecidable, but it fails to note that even decidable
verification tasks (for FSMs) are very often intractable, which -- for all
practical purposes -- is just as bad as being undecidable.

[1]: [http://langsec.org/occupy/](http://langsec.org/occupy/)

------
mrep
Can someone explain to me how these decentralized systems make our current
system more economically efficient? I just cannot see why anyone would
actually use it outside of the illegal market.

~~~
toomim
It takes 3-5 business days for a bank transfer. Bitcoin takes 10 minutes, and
ethereum takes seconds.

10 minutes is more efficient than 3-5 days.

~~~
Rikstam
Except that if you fail to include a transfer fee big enough, your transfer
may take weeks, or never even get confirmed at all. Case in point: I've been
trying to actually buy something with my BTC in the last few days, but because
my wallet is an older version or something (with a small default transfer
fee), my transfers are seen by just one peer and then are not confirmed. I
dunno, last time , 2 years ago, when I paid / transfered bitcoins, it took 10
mins max. I guess the mining business has increased or changed since then.

~~~
mikekchar
Your "wallet" is a key. It's data. Upgrade your client.

