Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

1. Passing keys around risks the original sender (or anyone listening in) grabbing the money after 'payment', and voids any guarantees Bitcoin etc. might be able to make - the transaction isn't even listed on the chain.

This would turn a 'trustless blockchain' to a 'non-blockchain relying on trust'. Assuming this transition can even be done (what would be the point of cryptocurrency in that case?), the result would be like the known hawala networks, which at least do not enable so much criminal activity and have some decent uses.

2,4. Bitcoin had an aura around it. Something experimental not really concerned with money or big crime, maybe a way to buy light drugs. Later on as a magnet for speculation. Remove the official cover, and laundering would become way more difficult.

3. There's terrible UX, and there's 'terrible horrible UX when one could easily lose money because the ISP closes your lightening connection'.

So I think this is possible to enforce, not completely, but there's no need for 100% enforcement to have a positive effect.



That implementation of offline transactions is a poor one, so the rebuttal would be too, but the reality is that bitcoin can work with offline transactions.

You can create the transaction object and hand that over. Transferrable literally as a file.

Instead of having over notes with the private key on them.

Eventually that transaction will need to be settled onchain. This can work in a world without a familiar looking ubiquitous internet. Regional internet cafes or even radio stations can settle signed transactions. People can have stocks of transactions and they just go to the cafe to settle those and also get their updated balance.

This capability always undermines a "ban crypto" thesis, or even a "crypto doesn't survive the apocalypse when the power goes out" thesis. It is merely a concept, just like computers communicating to each other is a replicable concept even if the head of state has an internet kill switch.


Well, that was a simple scenario with a simple answer. But there are many other things powerful adversaries could do. For example, what happens when miner traffic itself is disrupted and the network is forcibly split between China and the rest of the world? Leaving everyone at risk of having their transactions overwritten when the network is allowed to reintegrate?

Anyway, we don't need a 100% effective ban to get an effect. A 90% ban may well be good enough for any practical purpose. Your example is a good one - sure, there are ways to get around 'internet kill switches' several countries have, but in practice these (unfortunately) work.

The fact that some people in a cafe can get one cryptocurrency transfer going is no defeat for a ban, so long as the ban is effective enough to reach its intended effects (e.g. making ransomware useless).


> what happens when miner traffic itself is disrupted and the network is forcibly split between China and the rest of the world?

How would this be done? It only takes a single node capable of connecting to both networks to keep the whole thing working. There are already many nodes working with satellite connections so I'm pretty sure this can't be done even by state actors.


A satellite connection is still dependent on BGP routing to get to China/RoW and still goes via the Great Firewall to connect to China (if outside of China, not sure on how the miners in China do it - possibly they don't have satellite equipment at all). Poisoning BGP routes is well within the capability of state actors, and China could of course decide to block its firewall.


sure yeah, a deflationary currency crashes back to $2.50 and institutions are turned off of it for good

but the utility stays the same at $2.50 or $25,000 (offline-for-most, stateless monetary system with managed/predictable supply)

the same utility is inherited by most of other blockchain technologies


If you only upload your transactions infrequently how do you prevent double spend attacks?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: