the first time I used lightning on Cashapp was when I realized Bitcoin was the winner.
and every platform (like coinbase) that didn't have it already was trying to fool their customers into every other scam.
i don't know what the challenges with it are, but it seems to work about as efficiently as most online credit card purchases nowadays
yeah, lightning was a big part of what turned on the lightbulb for me and turned me maxi, that and watching cosmos chains fall in a heap in the Terra/Luna crash, the two things happened concurrently for me
the simple fact that lightning's total capital tied up in channels already exceeded 5000BTC two years ago tells the story
if 10% of that is moving back and forth every day that means the liquidity of lightning network is literally 50 million USD worth of payments taking place... PER DAY, then at that point the annual volume of lightning was already 1.8 billion per year, and i think this is a conservative estimate of things but it's getting close to the size of a small country just lightning, and bitcoin itself was already bigger than denmark 2 years ago concurrently to that
bitcoin is now almost as big as Amazon, also, btw, just to remind people
good to hear from a tech person that it's working. otherwise I would be thinking "oh it must be failing at some point".
it's not enough to make me doubt bitcoin. if Lightning doesn't work, bitcoin will just be Hodled by banks and used for settlement between them and the current financial stuff will stay in place.
however it would be nice if lightning also disrupts banks and payments and all that. that 2% fee for transfers on credit card is a big resistance. so velocity would go up and i've heard that's a good thing
yeah, lightning's competition is credit cards and interbank transfers
there is ALREADY more nodes in the network than all of the interbank and credit card clearinghouse industry combined, of course the total settled value is a lot lower but if the question is "can it scale" it's absurd to say it isn't already scaled beyond what the fiat payment networks are, it's definitely bigger than they are already
and what's even more absurd is that i can run my own channel to two or more of these bigger, routing nodes, and not even have to depend on anyone else most of the time to move my sats around
i use onchain once a month when i get paid, i flip that into lightning balance usually on WoS and then zap it to load up my personal channels, which are big enough to swallow all of my monthly income, so after that, i don't even see onchain fees, and i'm sure i am one of maybe tens of thousands already doing this and we are the reason why there is profit and the number of public routing nodes on the network continues to increase, i don't know what the total liquidity of the network is now, of PUBLIC channels but it's probably nearing 10k bitcoin for sure, if not more
i can see this trend continuing for at least another 5 years if the only major competition for block space is oRdInAlS and dRiVeChAiNs... bless fiatjaf, he's a smart guy but this thing about drivechains, idk what to say, i been in shitcoins since 2016 and exchanges and mining my experience tells me that LN is going to displace all of the online decentralised money movement the number of vendors adopting it and setting up to use these rails is increasing every year, these people just haven't looked into it deeply enough to understand what is going on
nor do they get why nostr's core userbase is so tenacious and committed
one other question i have is if Apple Pay/Google Pay/Samsung Pay use a lightning node on each of their sides similar to CashApp, wouldn't that solve 99% of the problems?
if this is true, i assume the only reason they haven't is because Bitcoin is open source and they can't charge the fees. But once the attack from small operators is big enough, then they will be forced to join ecosystem.
similar to how free Wifi came to airplanes.
but i don't know if my understanding is correct
yeah, they are resisting it because they have to compete with a field of players who are already competing very efficiently to offer routing services, and they can't charge monopoly margins
but eventually they will have to cave in to the pressure when the liquidity of lightning starts to get uncomfortably close to the size of one of their operations, because this is a more efficient competitor, it naturally has the advantage and they have to join in and hope they can survive at that point
anyway, that's the whole point of bitcoin, to eat the entire money business and spit out all of the usury
I figured once banks were free of the regulatory nightmare surrounding bitcoin they would naturally become LSPs. They have the vendor, and intrabank connections and they LOVE taking transaction fees every five minutes so, it's a match made in financial heaven. The one down side is they have similar (though not complete) control over transactional freedom like they have now. The ability to close channels on people they deem undesirable suck but you could always go one hop away and connect through a friend who has a channel with them.
I am more of an economic nerd than the cypher punk variety but I do have an affinity for code and privacy. But it feels like more of these coder nerds need to read some Rothbard and Mises before commenting on the monetary aspects. (Not so much you but the "Needs more features" crowd)
yeah, i read Human Action twice lol... does not need more features, just needs more routing algorithms, IMO... right now we have simple straight routes, we have keysend and AMP, it's lightning, where is the fan-out-fan-in multipath redundant routing!!!!???
to me, after examining all the info about the protocol that seemed like the direction that would be most important to explore, how to do redundant paths, and the other part, improving network state data propagataion, because the other problem is congestion - clients pick routes randomly from what they know was last known to be operational, but this whole thing of hiding channel state is a real problem, there needs to be some way to reveal enough channel state to help nodes making invoices avoid currently congested paths, this is almost the main problem, nodes being offline or unreachable is less of a problem than nodes getting too much traffic in one direction at the same time that they can't route
i like that... FOFI i think that would be the thing
if i were to contribute this as a routing algorithm to LND, which is a tire fire of buggy shit, but if i was, it would have to be based off the AMP, but AMP only solves the capacity problem, by parallelizing channels in a path, it doesn't solve the problem of route failure
it uses a cryptographic technique that enables the atomicity of the transmission, and the same thing should be possible to leverage to do multi-path REDUNDANT routing and thus enable failure resistance
this would kill the main weakness in the protocol that its haters point at the most
hell, i know exactly where to look to add this feature to LND, which is the main codebase deployed, but fuck those fuckers and especially fuck roasbeef... i tried to commit like 3 different PRs to get myself in the commit history fixing some legit problem that was in the issues, nope, nada, nix, not one got actioned, by the time someone noticed i was trying to help 3 more commits had clobbered parts of my commit and i needed to update it again... went through that cycle like 4 times with a simple one that isolated the generated protobuf protocols and that was enough for me, 3 times i am being really persistent and they fucked me the fourth time
that blackpilled me on the whole project
the only way i would even try to contribute to lightning at this point would be to be in charge of a LND fork and we would blow them away and within 2 years everyone would be running our node instead, even CLN users
Reading Man, Economy and State for the second time. Only like 500 more pages than human action it feels less poetic, if I can use that term.
Honestly from my perspective it always made more sense to me that lightning would have a more federated model. Small group of channels with the wealthiest member (or a pooled fund for outbound funds) connecting to each adjacent economic group. Then larger actors would connect adjacent towns, Then adjacent cities, and so on enveloping the world. Routing would nearly always go [Individual-Group-Town-State-State-Town-Group-Individual] for the longest hops. Maybe I just think to much like an econ guy and not enough in the practical limits of the code.
i tried to read ME&S but it felt like he was trying to just distill HA for dumb people, i think i got through about 1/4 of it before giving up
but yes, lightning is an open federated design, i can imagine building a redundancy protocol so that multiple providers could aggregate and fan out their infra to provide highly available big channel infra... it can already be done with plain simple network failover protocols that already exist, just a matter of tailoring one to do it with LN... the other thing it needs is a shared, highly consistent shared state data system so the multiple channels don't clobber each other's movements when a channel gets to the edge of capacity in one direction
see, that's the thing, i can see the network tech and the econ at the same time, really, it's just a matter of me finding someone with the money who is satisfied that i have the capacity to engineer it, and it would be my job for a decade to make this shit rock solid
but instead i'm here building a shitty middleware for a shitcoin gaming social platform, such is life
Maybe channel states could work like counting cards? Max capacity, minus X% equals +1 get over 5-6 and you become an "Outbound preferred" channel? I dunno if that is possible I'm not a code guy buy channel mode preference might be smart.
that's along the kind of lines i'm thinking, the thing is currently the protocol has near zero propagation of anything about channel state, the best you could do with a node right now is for it to literally just pretend to be offline but then it can't rebalance, as i see it, it just has to say what direction it's better to send payments through it
giving capacity info is probably a harder sell for the LN devs, but at least a sign of preferred direction would be great
Yeah, that's why I thought percentage would be more apt. 30% spend capacity could mean 30k or 3mil but it would signal to the network that it prefers to receive while routing. Again, I'm not a dev but this feels too obvious to have not been thought of or at least considered.
yeah, i'm not sure why there isn't a simple binary directional bias info propagated in the p2p node data
they really do hide the capacity though, and it's really lame because routing payments REQUIRES some estimate of at least the direction to send them over a path
Is this a feature that can be client side through LND or Core? Or would it have to be a whole BOLT iteration?
no, it's a peer to peer network thing
lightning is based on Sphinx https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf
it uses a source-routed onion encryption layering scheme
https://github.com/indra-labs/indra was my attempt to turn that into a whole network transport protocol, i did that work from late 2022 to 2023
one of the things that i figured out during that research and development work i was doing was that in order to make this into a network transport, it needed a very fast converging, but decentralised mechanism for propagating network state... congestion is the biggest risk, nodes being offline is the obvious but congestion is the real danger, and this is exactly the same dynamic with Lightning
people don't know what i'm doing, or where i come from, or what i do, it almost seems like i have the curse of Cassandra
Most people are just surviving. It's tough to focus on very beneficial tech if the benefit isn't immediately tangible. Cypherpunks have a bias toward the privacy and anonymity value. Most people see that (incorrectly) as a shady want to hide malfeasance. As an anarchist, I understand your feeling completely. So many problems that if people listened to my distrust for the government, would have been avoided.
