Holy Shit! This should be required reading for everyone. I learned a hell of a lot, and not just about the Mutiny Wallet. Fantastic article.
reply
❤️❤️❤️
reply
Wicked article. But I think I'm missing some base layer knowledge that I'd appreciate if someone could explain.
Honestly when I think about it I'm not entirely certain how lightning gets validated...
The article mentions offline payments. But BTC requires a consensus of nodes to agree that the ledger is correct right? But if you've got nodes trying to put (let's go with legitimate for the moment rather than delve into foul play) a bunch of transactions onto the block at one time that the other nodes knew nothing about would that bunch of transactions not essentially just get rejected by the network. Meaning offline transactions could never work? I must be missing something as lightning seems to work but that's making probably millions of transactions a minute, not 1 block every 10mins. So I think I'm getting my wires crossed somewhere. If someone could explain this in simpleton terms I'd greatly appreciate it.
reply
Constructing and signing a transaction is not the same as broadcasting it. For the former you don't need to be connected to the Bitcoin network. Lightning takes advantage of that in the form of so-called commitment transactions.
reply
I see kinda how lightning does it. In simpleton thoughts because it's "hot" it's able to inform all the nodes that these transactions have been constructed and are ready to be processed fully. So no nodes should disagree the validity of those transactions. But for an offline transaction I don't get it as that's "cold" and I'm a little lost how that could be broadcast with a consensus if it's been "cold" the whole time. I mean it must work somehow else how would cold wallets be able to transact without keeping the network permanently appraised of its transactions... Making it no longer a cold wallet. I'm going to need to look into this more as I think my understanding of transacting on the network with lightning or offline is just missing some fundamentals. Thanks for taking the time to respond and help me out. I appreciate it.
reply
The offline payment solution is essentially just having LSPs on both side of the transaction (one on the sending side, one on the receiving side) and routing the payment from the sender to the sender's LSP. Then the LSPs will talk to each other to determine whenever the receiver comes back online. It's really just the illusion of offline, but payments can be "held" a lot longer without it hurting the network.
reply
Ok. I think I'm starting to piece this together. Kinda like pinging an IP address over and over until you eventually get a response. I think it's starting to become clearer for me. Thanks a lot.
reply
I understand why you don't include suggestions for soft forks in here, but there are soft forks that solve these problems. BIPs that enable channel factories would have been great suggestions rather than going straight for fedimints as an example
reply
I had a whole section on alternative layers but took it out since it was too long and didn't really feel like it fit for the objective of this article. Essentially how lightning will still be the thing that brings them all together unless they can stand on their own.
Regarding channel factories, I've stopped talking about them since 2020 and I don't think I'll ever bring them up again until it happens. I don't think it will be useful for end users either way.
reply
Oh really? I thought you just gave up on soft forks deciding to focus instead on working with what you got (nothing wrong with that, its for the better actually), but I didn't know that you thought it wouldn't be useful for end users. Have you expressed those thoughts in more detail somewhere?
reply
I think channel factories are great for routing nodes, not necessarily for end users. There's always online requirements associating with adjusting the factories iirc.
reply
Right, which is something I remember being resolved if CTV got implemented.
They call them "non-interactive channels" https://utxos.org/uses/non-interactive-channels/
Oh, but I know, people think CTV is recursive even though it isn't because Androp speculated it might be and people took him saying "I don't know" as if it were fact of reality which is silly and its going to be a real uphill battle to get people to see that ugh.
reply
thank u for your insights
reply
Late reply, but this is the best Lightning article I've read thus far.
reply
Appreciate that!
reply
I just found out about his site. Do you have to contribute information on bitcoin to get sats. I read Bitcoin Magazine which is very informative.
reply
You get sats from other users. So you have to think about what other users might like to guess what they might tip. You can check the various subs and see what posts got tipped and which ones didn't to figure it out.
There are also helpful resources at the bottom of the page, such as this one: https://stacker.news/guide
reply
This is a fantastic write up. Thanks!
reply
And growing!
reply
Great article thanks!! Federated custody for small amounts as a less risky custodial service seems nice and easy for newcomers. I did not know that a multisig address could open lightning channels, and process the updates of a lightning payment. Sweet. If that works, maybe it can also work a federated custody as a good solution for lightning escrows, instead of hodl invoices that freeze capital. This way when you need to pay with money upfront for a service, you can pay it to the escrow and not straight to the counterparty.
I can see now that Visa, Mastercard all of those do play a role as escrows in Ecommerce operations.
reply
Federated custody cant do lightning channels yet. The way lightning integrates them is by having lightning gateways that do swaps between lightning and ecash from the federation. Lightning gateways can be any lightning node that wants to offer their services to federation users and trust the federation enough to exchange LN for ecash.
reply
reply
Great thanks! We are winning!
reply
Awesome!
reply
deleted by author
reply