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.
> 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.
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.
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.
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.
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.
I thought it was interesting that BSV seemed to scale just fine, and you could also store entire files on it, including JSON, HTML or even music or videos.
This seemed like an amazing innovation to me, made even more amazing by the fact that it was, by all accounts, the original protocol.
You could do some pretty amazing stuff with it, for example store a SPA on chain and then store individual posts on chain, and have the SPA read the app.
Unfortunately, the ecosystem was completely greed focused, and nobody is interested in technological advancement in the slightest.
>BSV seemed to scale just fine, and you could also store entire files on it, including JSON, HTML or even music or videos
This doesn't pass the sniff test. Everyone must store the full blockchain in order to verify it. So to run a full node you would have to store everyone's JSON, HTML, music, videos. Full mirroring for every node in a distributed system is about as close as you can get to the definition of doesn't scale.
> Someday a new startup will piggy bank on Netflix and probably buy it later.
Netflix got it's start shipping CDs, which was only possible due to the first-sale doctrine. The rights landscape hasn't adjusted for the new technologies. How could an new player disrupt a streaming world when everything is so locked down?
The entire page is underwhelming. For someone in the US, I walked away with basically no new information other than some stuff will enter public domain at new years.
I'm in the same boat. I mostly write Rust and Python. Using serde_json and Pydantic, you get deserialization and validation at the same time. It allows you to de-serialize really "tight" types.
Most of my APIs are internal APIs that accept breaking changes easily. My experience with protobufs is that it was created to solve problems in large systems with many teams and APIs, where backwards compatibility is important. There are certainly systems where you can't "just" push through a breaking API change, and in those cases protobufs make sense.
> My experience with protobufs is that it was created to solve problems in large systems with many teams and APIs
Also significant distribution such that it’s impossible to ensure every system is updated in lockstep (at least not without significant downtime), and high tail latencies e.g. a message could be stashed into a queue or database and processed hours or days later.
Righting Wrongs by Kenneth Roth said something along the same lines, except in this case he said as director of human rights watch he was able to get the attention of despots and change their behavior by posting on twitter. It's clear there are some benefits. Roth's messaging would probably not be impacted by revealing his nation of origin, so it doesn't seem like have to throw the baby out with the bathwater.
reply