Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zerocoin implementation bug

zcoin.io

Post reply on HN
Print view View original

101–110 of 142 posts

Re: Zerocoin implementation bug

#101

Post by rtpg »

mrb wrote: post #99
rtpg wrote: post #77

Earlier quoted context omitted.

I am not 100% sure, but my understanding is that the bank is liable for those losses unless they can prove gross negligence on your part. I've heard that legal argument, at least. [0] Though this is not worse from your cryptocurrency. If they get a hold of your private keys, you lose everything. At least in the classical banking system you have some legal recourse. [0]: I might just be thinking of this comedy sketch…

"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?

Re: Zerocoin implementation bug

#102

Post by legohead »

blunte wrote: post #94
rtpg wrote: post #68

Earlier quoted context omitted.

it's the ultimate irony. It feels like anonymity because you decouple the "get a bunch of BTC" from "cash out to USD", so it's the worst of both worlds. It's anonymous at first, so fraud can't easily be reversed. But it's "eventually completely public", so people who might want to use it for anonymity are sitting on a ticking time bomb. Eventually, their identities will be revealed.

Indeed, but people just don't seem to get this. As long as people are converting fiat to crypto at the front end, and then crypto back to another fiat at the back end, then there is no anonymity. There may be a lot of obfuscation in the middle, but ultimately the guy who converts back to fiat will be asked the question by his government, "Where did this money come from?" Then he needs a provable paper trail. Maybe so…

"I found a printout of the bitcoin key."

Re: Zerocoin implementation bug

#103

Post by rtpg »

mrb wrote: post #98
rtpg wrote: post #71

Earlier quoted context omitted.

wait a sec. Someone steals my credit card, and if I notice within 2 months, I can get everything back. Another advantage is that it doesn't take several hours (and huge amounts of wasted electricity) for a transaction to go through. My bank hasn't been siphoning my funds either. I wouldn't trust any cryptocurrency exchange with holding even 10% of my monthly salary. Sure, governments can get my bank records. But my b…

"Someone steals my credit card, and if I notice within 2 months, I can get everything back." No. You may still be liable for $500 if you fail to report it within 48 HOURS: http://consumer.findlaw.com/credit-banking-finance/are-you-l... "Another advantage is that it doesn't take several hours" You hold a common misconception of how transactions work. Bitcoin transactions are transmitted/notified instantly (like credit…

that argument about bitcoin mining not being wasteful just shows it's not wasteful compared to other decentralized, trustless currencies. It still loses out to traditional payment methods.

"It will only use 1% of the world's electricity consumption". We can only do that for 100 things. Does "decentralisation of currency" belong in the top 100 things to devote electricity generation to?

EDIT: do you have a link to a fuller explanation about transaction speeds? I do not understand how transfers can happen so quickly without introducing a risk of double spend

Re: Zerocoin implementation bug

#104

Post by wyager »

blunte wrote: post #95
wyager wrote: post #43

Earlier 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…

Most people consider ex post facto enforcement to be a trademark of a thoroughly broken legal system.

Re: Zerocoin implementation bug

#105

Post by dnautics »

meowface wrote: post #52
GrinningFool wrote: post #47

Earlier quoted context omitted.

If they just want out, the things that happen to the currency don't matter to them - they're already gone.

That's true, but if this was the epic exit scam they were planning for so many years, it's a bit disappointing.

410 BTC is half a million dollars.

Re: Zerocoin implementation bug

#107

Post by kobeya »

jackgavigan wrote: post #60
josu wrote: post #38

Earlier quoted context omitted.

You are completely right, I hadn't considered that. This is what Zcash has to say about it: Since the value sent between shielded addresses is private, how can we determine the number ZEC in circulation? Currently, we know that every miner validates every transaction, and each transaction comes with a zero-knowledge proof that it doesn't violate conservation-of-money (i.e. a proof that the money coming out of the tra…

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.

Re: Zerocoin implementation bug

#108

Post by alvarosevilla95 »

miguelrochefort wrote: post #11
wmf wrote: post #2

What's better that stealing magic Internet money? Creating anonymous magic Internet money out of thin air, then selling it. Brilliant. But seriously, I'm not sure which is worse: Watching your stolen money move around the blockchain knowing you are helpless to do anything about it, or being provably unable to even tell the difference between "real" and "counterfeit" coins.

> out of thin air You don't understand economy.

But that's literally what happened...

Re: Zerocoin implementation bug

#109

Post by alvarosevilla95 »

oh_sigh wrote: post #35
thinkloop wrote: post #20

Earlier quoted context omitted.

Every owner eats a tiny bit of it with the downward pressure on value caused by the artificially increased supply. Also, decreased trust reduces demand pressure further lowering value for everyone.

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.

Re: Zerocoin implementation bug

#110

Post by wuschel »

skolsuper wrote: post #89
ianmiers wrote: post #67

what 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…

Another major bug caused by copy+paste. I seem to remember a security researcher article months (years?) ago that identified this theme, showed a way to grep a codebase for likely c+p errors and found a load of bugs in real production code that had remained hidden for years. I think I landed there from HN, but my google-fu is failing me now, can anyone else remember it?

Interesting.

How would you minimize these type of errors by design or best practice?

I guess languages with a lack of higher order abstractions and no strong type system might be more prone to this type of errors.

Post reply on HN