←back to thread

681 points Anon84 | 8 comments | | HN request time: 0s | source | bottom
Show context
spicyusername ◴[] No.46181533[source]
I've never understood the initial arguments about Bitcoin, no matter how many times they've been explained to me.

The block chain is, and always was, an extremely inconvenient database. How anyone, especially many intelligent people, thought it was realistic to graft a currency on top of such a unwieldy piece of technology is beyond me. Maybe it goes to show how few people understand economics and anthropology and how dunning-krueger can happen to anyone.

Now the uninformed gambling on futuristic sounding hokum? THAT is easy to understand.

That being said, I'm sorry the author had to go through this experience, the road of life is often filled with unexpected twists and turns.

replies(48): >>46181550 #>>46181552 #>>46181565 #>>46181570 #>>46181587 #>>46181592 #>>46181595 #>>46181598 #>>46181626 #>>46181627 #>>46181644 #>>46181650 #>>46181665 #>>46181684 #>>46181692 #>>46181705 #>>46181710 #>>46181747 #>>46181851 #>>46182086 #>>46182181 #>>46183207 #>>46183326 #>>46184155 #>>46188845 #>>46188916 #>>46189281 #>>46189390 #>>46189635 #>>46189752 #>>46190184 #>>46190277 #>>46190352 #>>46190438 #>>46190551 #>>46190980 #>>46192357 #>>46192629 #>>46192718 #>>46192829 #>>46193037 #>>46193082 #>>46193531 #>>46193609 #>>46194845 #>>46194934 #>>46195115 #>>46203155 #
serial_dev ◴[] No.46181650[source]
Blockchain is a very inconvenient database, for sure, but there is a good reason Bitcoin uses it. It had to solve to double spend problem and create a trustless p2p digital cash, while being censorship resistant and having no central authority.

Some people around a decade ago started using blockchain for everything where a SQLite db would have been better, because blockchain was the buzzword around that time, and they were charlatans who wanted funding and hype, or signal how cutting edge they are (kind of how the last two years everybody became an AI company).

It doesn’t mean that Bitcoin using blockchain is stupid.

replies(3): >>46182064 #>>46188526 #>>46189636 #
dreamcompiler ◴[] No.46188526[source]
It's stupid because blockchains don't scale. In most other respects they're quite clever.
replies(1): >>46188744 #
Seattle3503 ◴[] No.46188744[source]
In theory a L2 network coukd solve the scaling problem, but every time I've looked at L2 solutions theve had terrible UX.
replies(2): >>46189134 #>>46189461 #
1. tsimionescu ◴[] No.46189461[source]
L2 networks achieve scale by... Not being blockchain. And by not offering the double-spend protection guarantees of blockchains.

So this statement is "you can scale blockchain tech by using another tech in its place that doesn't offer the same guarantees".

replies(1): >>46190224 #
2. copirate ◴[] No.46190224[source]
With the Lightning network, L2 is basically a database between only 2 parties that are required to be online during the transaction. It's not possible to double spend in that situation.

There's the possibility of double spending by committing to the bitcoin blockchain an old version of your "database", but then you would face the penalty of having your entire balance confiscated by the other party.

More details here: https://bitcoin.stackexchange.com/questions/67141/how-is-a-d...

replies(1): >>46190421 #
3. tsimionescu ◴[] No.46190421[source]
> but then you would face the penalty of having your entire balance confiscated by the other party.

Only if the other party notices in time that you did this. You are reliant on active monitoring of the blockchain to know that your transactions actually happened. And the more you want to scale (i.e. the more transactions you do on a single Lightning channel without settling it on the BTC blockchain), the bigger the risk becomes.

replies(2): >>46190567 #>>46190681 #
4. npoc ◴[] No.46190567{3}[source]
If monitoring really is a problem isn't simple automation the solution?
replies(1): >>46191673 #
5. copirate ◴[] No.46190681{3}[source]
Yes, but as long as you monitor, double spending is not possible. And it's possible to use tools to do that somewhat passively.

There are conditions on every payment system. With bitcoin you also have something to do to prevent double spending: wait for some number of confirmations (and making sure you're on the right chain).

And "double-spend protection guarantees of blockchains" is very dependent on the cost of doing a 51% attack, so it's not strong by itself. It's very strong in bitcoin only because the quantity of hashrate/money required to do one is astronomical. It's not so strong on small blockchains.

And I fail to see how the risk increases with more transactions on a single lightning channel.

replies(1): >>46191711 #
6. tsimionescu ◴[] No.46191673{4}[source]
This is automated, no one is proposing to manually look at BTC blocks to see if you are getting cheated. The problem is that you need to explicitly run code constantly to check if this happens - which means that if your monitoring agent goes offline for any reason (which an attacker could perhaps force), your BTC that you received in a Lightning channel may be stolen.
replies(1): >>46192418 #
7. tsimionescu ◴[] No.46191711{4}[source]
My point is that Lightning has additional failure modes that BTC does not, and Lightning in itself does not offer the guarantees that Bitcoin does. It of course also suffers from all of BTC's failure points - if someone successfully does a 51% attack on BTC, they can implicitly also steal any Lightning funds as well. If you close a Lightning channel and then don't wait for enough confirmations, or you broadcast your cheating transaction and don't wait for enough confirmations, you can clearly lose your money.

The risk doesn't increase with the number of transactions on a channel, that was a wrong statement from my side. What I was thinking of is that the risk increases the more your transact through Lightning instead of regular BTC. Basically, the more of your BTC is caught up in Lightning channels, the higher the value of attacking you with a double spend attempt.

8. npoc ◴[] No.46192418{5}[source]
Okay, so it's an attack vector but one that can be mitigated against by implementing redundancy.

I would argue that Lightning's biggest security issue is having to store your private keys on an Internet connected device. I don't know if further improvements can be made in this area, for example allowing for some kind of 2FA, like multi-sig on the base layer.