Earlier quoted context omitted.
It's not really a tiny bit... ~30% of the networks value was fabricated.
And every coin owner took a tiny bit of that loss.
The currency is down more than 12%.
Zerocoin implementation bug
111–120 of 142 posts
Re: Zerocoin implementation bug
#112Earlier quoted context omitted.
This type of challenge is implicit in any cryptocurrency with strong confidentiality (i.e. which conceals the amount being transferred from public view) unless you trust the "inputs-equal-outputs" proving mechanism (which, in Zcash's case, is the zk-SNARK that accompanies a shielded transaction). One potential solution is to periodically require that all coins be unshielded (i.e. sent to a t-address) and passed throu…
What? This is totally incorrect. It is perfectly possible to build systems that verify total issuance while concealing amounts. Blockstream's Confidential Transactions does this, for example.
So you trust Pedersen commitments and range proofs to prove that the inputs to a Confidential Transaction equals its outputs?
Re: Zerocoin implementation bug
#113Earlier quoted context omitted.
While I don't feel that your argument generalizes (e.g. Bitcoin actually probably is the best extant value exchange mechanism in many ways), the whole Ethereum thing was embarrassing. People fell for the mumbo-jumbo and then the whole project rendered itself pointless by going back on its "code is law" principle.
In a way, they did actually prove that code is law - but they proved that "currently consensus-agreed-upon code is law." That old buggy code was law until the new code became law and changed the rules :). But of course its redundant to say "current code is law" because it's obvious by the logic of how consensus works. The confusion for people was their belief that code at one point in history would forever remain "th…
"code is law" and "currently consensus-agreed-upon code is law" are not the same though, not even close. One allows for human intervention and the other one doesn't.
Moreover, consensus means that it's possible that >50% participants can one day to decide and take the money from the other participants. By declaring them hackers / evil / etc, for example. Which is basically what happened.
Re: Zerocoin implementation bug
#114Re: Zerocoin implementation bug
#115Earlier quoted context omitted.
Or alternatively, the developers designed this hard-to-find typo/bug years ago and have now just quietly cashed out.
Seems very unlikely since it would inevitably cause many to lose faith in the currency. If they really want to cash out, they can just do what almost every other upstart cryptocurrency founder does and make it clear they're taking some of the pie.
You're assuming the one who introduced the bug was a founder with the ability to do that.
Re: Zerocoin implementation bug
#116Earlier quoted context omitted.
What? This is totally incorrect. It is perfectly possible to build systems that verify total issuance while concealing amounts. Blockstream's Confidential Transactions does this, for example.
So you trust Pedersen commitments and range proofs to prove that the inputs to a Confidential Transaction equals its outputs?
As much as the elliptic curve discrete logarithm problem can be trusted to be intractable, yes.
For which bitcoin has some billion dollar in bounties:-)
Re: Zerocoin implementation bug
#117Earlier quoted context omitted.
So you trust Pedersen commitments and range proofs to prove that the inputs to a Confidential Transaction equals its outputs?
As much as the elliptic curve discrete logarithm problem can be trusted to be intractable, yes. For which bitcoin has some billion dollar in bounties:-)
The crypto used in Confidential Transactions, or any implementation of it, does not only rely on ECDLP. There's plenty of scope for potential protocol or implementation errors. (The Zcoin issue, remember, is an implementation error.)
Re: Zerocoin implementation bug
#118Earlier quoted context omitted.
As much as the elliptic curve discrete logarithm problem can be trusted to be intractable, yes. For which bitcoin has some billion dollar in bounties:-)
The crypto used in Confidential Transactions, or any implementation of it, does not only rely on ECDLP. There's plenty of scope for potential protocol or implementation errors. (The Zcoin issue, remember, is an implementation error.)
The CRYPTO relies only on ECDLP. That word, as it is usually used as a term of art, indicates the underlying mathematical assumptions. to say "it does not only rely on ECDLP" is to indicate that there are other trusted mathematical security assumptions, such as harness of EC pairing or the knapsack problem. This is not the case with confidential transactions, whose Pedersen commitments and Back-Maxwell rangeproofs rely on the exact same cryptographic assumptions as any bitcoin signature. It even uses the same library to create and check these commitments, with a minimal amount of new code.
Is there scope for new implementation errors? Yes, but only in the fully generic sense of it involving _some_ new code. Anything that is different involves changes, and any change brings the possibility of an implementation error. However Blockstream has tried to keep confidential transactions as close to the underlying bitcoin code base as possible to minimize that error, and unlike other solutions CT has been subject to academic review and external security audit.
Re: Zerocoin implementation bug
#119what went wrong: TLDR probably Ctrl-C,Ctrl-V. (Just to be clear, this is about Zcoin, not Zcash/Zerocash. The two are completely different) The fix is here. https://github.com/zcoinofficial/zcoin/commit/33796c839f7d4d... What happened? First, some stylized facts about ZCoin: 0) ZCoin is a fork of Bitcoin that uses a 4 year old academic research library, libzerocoin, to make anonymous payments using the Zerocoin proto…
Just to clarify, the code that was duplicated per denomination is not part of libzerocoin itself, it's in main.cpp. I'm not sure who wrote it; it may or may not have been part of the academic prototype Ian refers to. In any case, this amount of duplication (in security-critical code, no less) should never have passed the necessary code review to release a cryptocurrency. Also note that there are still unexplained differences between the copied code branches after the security fix.
(In contrast, Zcash did have duplicated code in the prototype we inherited, but we rewrote that entirely well before the Zcash launch.)
[Edit: I confirmed that the duplicated validation code in main.cpp was not present in libzerocoin. Some of the code in main.cpp including some stale comments, appears to have been pasted from https://github.com/Zerocoin/libzerocoin/blob/master/Tutorial... , but that tutorial code does not have the bug. So it appears that it was introduced by the Moneta/Zcoin developers.]
Disclosure of interest: I am a Zcash developer.
Re: Zerocoin implementation bug
#120Earlier quoted context omitted.
"they get a hold of your private keys, you lose everything." Hardware wallets solve this (Trezor, Keepkey, etc.) This makes Bitcoin more secure than cash. Most people accept the (imperfect) level of security of cash, so they would be OK with the higher level of security of hw wallets.
Serious question: if you're using a hardware wallet, can people accept payment from you without worrying about double spends?
How is it any different compared to software wallet?