I don't always get mobile visitors, but when I do I use 750k images.
Fixed, thanks.
Parity's Wallet Bug Is Not Alone
11–20 of 20 posts
Re: Parity's Wallet Bug Is Not Alone
#12Great article.
I recently wrote a tool to help find bugs like this:
https://ericrafaloff.com/introducing-the-solidity-function-p...
Re: Parity's Wallet Bug Is Not Alone
#13And 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.
Considering that you have similar behaviors in open source communities even if only technical details are discussed, it's not surprising it gets even worse if you add money to the mix.
Many people seem to get irrational if they fear to lose their virtual money.
For that matter, I always look closely how people act when the price dips due to some insignificant drama. You can assess beforehand if you want to throw money towards a project depending on those people.
Because when the next real crisis hits, and believe me, in cryptocurrencies there's always a next one, those people won't act better in a real crisis.
Re: Parity's Wallet Bug Is Not Alone
#14Great read.
Re: Parity's Wallet Bug Is Not Alone
#15Earlier quoted context omitted.
> 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…
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 m…
> 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.
Re: Parity's Wallet Bug Is Not Alone
#16Earlier quoted context omitted.
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 m…
> 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. Y…
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
> 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)
Re: Parity's Wallet Bug Is Not Alone
#17The 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…
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.
Re: Parity's Wallet Bug Is Not Alone
#18The 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…
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.
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.
Re: Parity's Wallet Bug Is Not Alone
#19And 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.
Of course, because arguments about the technical detail would undermine both parties interests.
Re: Parity's Wallet Bug Is Not Alone
#20And 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.
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 lar…
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.