
Parity's Wallet Bug Is Not Alone - scarhill
http://hackingdistributed.com/2017/07/20/parity-wallet-not-alone/
======
Animats
The article points out that the database community discovered that application
programmers can't handle too much power. That's why databases have things like
atomic transactions. Those are hard to do in the general case, but all SQL
database systems now do it.

Blockchain contracts for real money need at least the assurance level of
database transactions. The DAO attack involved causing a transaction to happen
only in part; one part happened, then the transaction aborted. That needs to
be prohibited by the underlying system. As with database transactions, either
everything goes right and the transaction commits, or something goes wrong and
the data is unchanged.

~~~
amygdyl
In summary, the block chain is great for use as a ledger.

But forgetting that the wheel is not only not reinvented, but the market or
industry or hype chain has not yet advanced to appreciation of wheels, is
potentially a costly error.

~~~
amygdyl
For that matter bitcoin is not exactly a fast cheap transaction system, is it?

This is how I explained to myself why I found it so hard to first get a
understanding of what it was about : nobody wanted to say what it is.

------
foepys
And again, an interesting story about crypto currencies ends with a fight of
egos instead of concentrating on the technical details. Why do those crypto
enthusiasts almost always have to throw dirt at each other? Especially when
it's completely out of place like in this blog post.

~~~
codeflo
I don't any cryptocurrencies, but my perception observing the field somewhat
casually is that these kinds of discussion sometimes only appear to be about
technical details on the surface level. In reality, one or more of people
involved can personally lose a huge amount of money if a certain policy is or
isn't adopted. For example, it's usually understood that the inventors of any
particular cryptocurrency hold a large sum of "pre-mined" money, but somewhat
taboo to state it because the appearance of a benevolent dev team that acts in
the best interest of the community has to be maintained.

~~~
amygdyl
It is so indistinguishable from how street junkies fight to continue one
another when one has made a mark, the realisation of this clarified the matter
for me finally. I was made homeless result of a fraud and got to be robbed and
conned plenty enough to be not mistaken I'm seeing the exact same behavior.

------
ithought
It's amazing BitGo whould shrug off Emin's help when he helped fix their
software. Emin's super smart, ignoring his offer to serve as a technical
advisor is ridiculous.

And then BitGo goes on to be partially responsible for a $320,000,000 loss
(current value) that almost destroyed BitFinex.

It's just sad that so much fighting and ego has prevented technical
collaboration. I'm a supporter of the Core devs but Emin is a genius who
should be respected.

~~~
petertodd
> It's just sad that so much fighting and ego has prevented technical
> collaboration. I'm a supporter of the Core devs but Emin is a genius who
> should be respected.

Emin has a bad track record of lying about his work.

For example, he claimed in the announcement(1) for his Teechan payment channel
scheme that it could do 2480 transactions per second, but neglected to mention
that it achieved that by failing to actually write those transactions to disk
and storing them in RAM only. If your computer crashes, you can lose money in
Teechan. This is not unlike advertising the high performance figures achieved
by making a new RAM-only database, without advertising the fact that you
achieved them by storing everything in RAM.

Similarly, Emin's announcement and paper also gave the impression that payment
channels weren't currently possible to implement on Bitcoin without segwit,
when in payment channels with similar properties to Teechan have been possible
to implement for multiple years now via BIP65. Oddly, BIP65 _is_ cited in the
Teechan paper, but for an unrelated reason.

Then there's how Emin's PR around that announcement presented Teechan as
something that could be implemented right away as a replacement for segwit via
Intel SGX, without mentioning that Intel required SGX users to get licenses to
use it in production, and Teechan didn't have one.

I could go on, but that's just a single project... The sad thing is Emin is
often right and can do good work, but with a track record like that it's no
surprise that people aren't interested in working with him.

1)
[https://web.archive.org/web/20161223143716/http://hackingdis...](https://web.archive.org/web/20161223143716/http://hackingdistributed.com/2016/12/22/scaling-
bitcoin-with-secure-hardware/)

~~~
el33th40r
That's classy, trying to hijack the top comment to spread lies, ad hominems
and smears.

>For example, he claimed in the announcement(1) for his Teechan payment
channel scheme that it could do 2480 transactions per second, but neglected to
mention that it achieved that by failing to actually write those transactions
to disk and storing them in RAM only.

First of all, our actual deployments showed that Teechan can do more than
30,000 tx/sec across the Atlantic, __in fully fault tolerant mode __.

Second, the Teechan paper made clear exactly how we reported the initial,
unoptimized numbers, which is precisely why you're here writing these bogus
critiques.

>Emin's announcement and paper also gave the impression that payment channels
weren't currently possible to implement on Bitcoin without segwit

We learned after publication that there are rumors of a "Lightning Network"
implementation without Segwit. Unless you can point to a protocol
specification, however, these remain unbacked and uncharacterized assertions,
of the kind "I believe I can fly."

>Then there's how Emin's PR around that announcement presented Teechan as
something that could be implemented right away as a replacement for segwit via
Intel SGX, without mentioning that Intel required SGX users to get licenses to
use it in production, and Teechan didn't have one.

This is HN, and I usually try to be more diplomatic, but this is stupid.
First, Teechan is a protocol, it isn't tied to SGX. We are working with HSM
vendors to deploy it on non-Intel hardware. Second, Teechan does NOT require
the users to obtain licenses, it just needs to be signed by an entity. Third,
Peter Todd has no idea about the nature and scope of academic work and how it
differs from industrial deployments, which explains why he feels so threatened
as to indulge in personal smears.

I could go on, but tearing down a known Bitcoin troll is pointless.

~~~
petertodd
> First of all, our actual deployments showed that Teechan can do more than
> 30,000 tx/sec across the Atlantic, in fully fault tolerant mode.

I'd appreciate if you linked to those actual deployments, something with a
description of how they worked.

As you know, actual remote attestation capable hardware has severe limitations
on persistent anti-replay mechanisms due to the fact that they are implemented
in hardware. Your Teechan performance figures reported in your paper and
initial announcement were recorded with those counters implemented in RAM, in
such a way that a power outage would put users in a position where they can
lose funds. Meanwhile, the actual SGX anti-replay counters that are currently
available limit counter updates to as infrequent as multiple _minutes_ between
updates.

> We learned after publication that there are rumors of a "Lightning Network"
> implementation without Segwit. Unless you can point to a protocol
> specification, however, these remain unbacked and uncharacterized
> assertions, of the kind "I believe I can fly."

Payment channels != Lightning network.

Specifically, you presented Spilman payment channels as state of the art, when
you are well aware of the fact that they have been made obsolete by
CheckLockTimeVerify/CheckSequenceVerify payment channels.

Teechan as presented in your paper that I was criticizing wasn't a Lightning
network competitor, it's a _payment channel_ competitor. So obviously an
apples-to-apples comparison would be appropriate.

> Second, Teechan does NOT require the users to obtain licenses, it just needs
> to be signed by an entity.

What do you mean by "signed by an entity" in your statement here? To be clear,
by "SGX users" I am referring to developers of SGX-using products, not end-
users.

Also to be clear, you claimed - based on the fact that SGX was widely deployed
- that "[Teechan] side-steps a controversial proposal to change the underlying
Bitcoin protocol, and provides all of the much-touted benefits of Lightning
Networks _today_ , without having to modify the base protocol at all."
(emphasis mine)

To say that without making it clear that SGX is _not_ in fact something that
can be deployed on a whim due to the necessity of getting a license to use a
SGX application in production is quite dishonest, especially in the context of
the Bitcoin segwit debate that you positioned Teechan within.

~~~
cryptonerding
Hi, I don't normally comment on HN but this thread intrigued me. As someone
who was quite interested in the Teechan work when it first came out, I have a
couple thoughts/questions:

> I'd appreciate if you linked to those actual deployments, something with a
> description of how they worked.

I'm not sure if this is it, but it looks like something was recently put
online (seems to match the authors names):
[https://arxiv.org/abs/1707.05454](https://arxiv.org/abs/1707.05454)

> Your Teechan performance figures reported in your paper and initial
> announcement were recorded with those counters implemented in RAM, in such a
> way that a power outage would put users in a position where they can lose
> funds.

I don't think they disputed that, in fact iirc, they made that quite clear and
even under failure cases where a user's CPU loses power, funds are not
completely lost; two options remain, either the counterparty can settle the
channel (meaning no funds are lost), or the refund tx comes into play. Of
course this isn't ideal, but the point remains, for channels where the
difference between the most recent state and the refund state is not enormous,
this deployment model can make sense. If you want to avoid this, it can be
circumvented with backup power generators etc. But they never tried to hide
this fact. If you read the paper, they were clear that Teechan did not use
hardware counters.

> Teechan as presented in your paper that I was criticizing wasn't a Lightning
> network competitor, it's a payment channel competitor. So obviously an
> apples-to-apples comparison would be appropriate.

Surely for an "apples-to-apples" comparison as you request, CLTV/CSV payment
channels don't even compare with LN/Teechan: CTLV/CSV are only unidirectional
and they suffer the exhaustion problem. In addition they can only be funded by
a single party, so to compare them to bidirectional payment channels like
these would be unfair too, no? Also, if you want to compare LN/Teechan pre-
segwit, you have the same problem: LN payment channels can only be funded by a
single party, in addition, they also require monitoring the blockchain (at the
moment). I'm not saying Teechan is the better, I'm saying it has it's own set
of advantages/disadvantages and as someone who seems to be pushing back
against Teechan a lot, you should know these trade-offs?

> To say that without making it clear that SGX is not in fact something that
> can be deployed on a whim due to the necessity of getting a license to use a
> SGX application in production is quite dishonest, especially in the context
> of the Bitcoin segwit debate that you positioned Teechan within.

Granted, although this might be the biggest challenge in deploying Teechan
today, it's by no means impossible: I know of a few companies who have
licenses with Intel. Intel didn't create this stuff to sit on a shelf. And
even if you ignore Intel, it seems to me that several companies are now
looking into deploying payment channels with trusted hardware. e.g. I'm sure
you are aware of Blockstream :)

To summarize, Peter, sometimes you have to give credit where credit is due. I
know you might have personal differences with Gun, and I don't want to get
between you, but for outsiders who don't really have much technical insight
here, you seem to be twisting the facts a little? Sure, you might not agree
with the work, but hey, the company you work for seems to like it enough to
pay someone to do it
([http://jobs.khoslaventures.com/jobdetail.php?jobid=698427](http://jobs.khoslaventures.com/jobdetail.php?jobid=698427))

------
e79
Great article.

I recently wrote a tool to help find bugs like this:

[https://ericrafaloff.com/introducing-the-solidity-
function-p...](https://ericrafaloff.com/introducing-the-solidity-function-
profiler/)

------
coolbreeze
Great read.

------
dibbsonline
I don't always get mobile visitors, but when I do I use 750k images.

~~~
el33th40r
Fixed, thanks.

