jb55's avatar
jb55 _@jb55.com 11 months ago
"look everyone is using custodial lightning so we should embrace that" makes me feel sick. I always thought this was a temporary measure until we had better wallets, TIL the plan now is to embrace it fully for mass onboarding. We're working with a few partners to try an alternative approach. If it fails then it fails, but at least I can sleep at night knowing we tried. Mass onboarding into custody seems like a disaster without a really good non-custodial offboarding plan.

Replies (65)

Silence's avatar
Silence 11 months ago
A custodian got hacked today, so…
Default avatar
npub1s830...2dsf 11 months ago
That's a disaster. Hopefully your alternatives work. Otherwise people might as well use venmo. Non custodial is the only way.
jb55's avatar
jb55 _@jb55.com 11 months ago
it’s difficult to work on, bitcoin L1 is super constrained in what you can do, so it complicates L2 design. This is why covenants would be nice, simplifies a lot of things in L2 space
Default avatar
npub1xg5s...fx2g 11 months ago
Is full worldwide self custody even technically possible? I think optional self custody for the subset of people that care about it is of course important.
jb55's avatar
jb55 _@jb55.com 11 months ago
because for your channel state to update you have to be online to sign the multisig transaction. Think of it as a bar tab with the amount of bitcoin that would go to each party of the channel when it settles onchain.
StevenB's avatar
StevenB 11 months ago
What’s the end goal? Easy payment options that just work, complete sovereignty, some mix of the two? I’m personally ok with running my own node, but I’ve had custodial wallets that I kept the amount of sats I was comfortable losing in. Node managing can be a bit of a pain. I’m not sure having someone do it for you for small amounts to zap with is so bad.
jb55's avatar
jb55 _@jb55.com 11 months ago
There is a plan that makes sense but i have to try it before i can vouch for it. No you shouldn’t have to run a node.
Are we looking for a nostr focused Zeus wallet, I was thinking dual funded applicable channels in a nice UI in something like Albyhub would do the trick.
This is a ideologically small-blocker idea. We don't have a non-custodial L2 onramp, and until we do, everyday people will eventually have to use L1 or have custodial Bitcoin. There's no third option. *Maybe* drive chains can be LN channel machines. For now, the plan must be to eventually scale L1 so people can establish self custody on L2 to scale the rest of the way, or to forget self custody as an everyday people thing.
StevenB's avatar
StevenB 11 months ago
Hopefully it works out. Good luck.
this is NEVER going to work with lightning. We can hope there will be other layer 2s that can do this, but that might be years till we reach this point. I know you already kniw this, but Here is why it doesn't work with lightning: If you want to receive a payment, you need to be part of the lightning network (eg. you need a channel). Also, the channel needs to have inbound liquidity. So how to get to that point? Easy right? Just pay someone to open a channel to you! BUT HOW, IF YOU'RE NOT PART OF THE NETWORK ALREADY??? Do you expect people, to go buy bitcoin on an exchange, send the bitcoin to their lnwallet, open a channel, rebalance their liquidity, only so that they can receive a zap? I know we love to play idealist, but it's never gonna happen for the normal pleb. The more realistic approach is to just start receiving zaps into custody. Once the pleb learns about self custody and has received enough zaps to open a channel, he can move them to self custody. Why are you trying to build the skyscraper from the clouds to the ground?
that's how i've always viewed it too, a stepping stone while better technology was built. please keep trying alternative approaches. non-custodial lightning is too hard for the average human and we need better solutions for them.
jb55's avatar
jb55 _@jb55.com 11 months ago
yeah that's the idea. nice thing about this approach is that you can continue to use lightning normally through the entire process.
jb55's avatar
jb55 _@jb55.com 11 months ago
and the trust relationship with the LSP is very minimal, they could be automatically set up to reduce liability as soon as economically possible.
Well, one could wrap phoenixd and add it to the nostr client. Then we can start switching to bolt12, which has better privacy properties anyway.
Overall I think Acinq is doing some great stuff - channel splicing, trampoline routine, bolt12. The one architecture piece that's missing is how to make it really easy to switch to another LSP and ideally migrate your existing channels. Something like greenlight may be the way?
jb55's avatar
jb55 _@jb55.com 11 months ago
they are definitely leading the way. switching LSPs sounds like a pain.
I am sure you are so because you have thought through it, not because it's the party line, though, right? Small block could mean "minimum needed," or "1MB exactly," or something else. What I meant by "ideological small block" is a mindset that the 1MB is a magic number that cannot be changed without making Bitcoin not Bitcoin, something essential to the definition. I am of a "minimum needed" variety.
Truth. I ran a personal LN for awhile, and since then it's become far easier, but it's not at all as easy as a regular old wallet just a few years into Bitcoin's history.
I think that will make it easier in some regards, but ultimately most humans aren't going to manage their own liquidity. This includes buying it from LSPs. Even though that is easier, most won't do that.
I completely agree. We're trying to build solutions to handle the incoming routing barrier with swaps. Utilizes our liquidity and WoS liquidity to ensure routes. I've been using this method for a few months now with 0 routing issues paying for things at @Mysterious Hamster merchants and others
Super Testnet's avatar
Super Testnet 11 months ago
I recently got sending and receiving working over lightning I'm now integrating hedgehog payments so that anyone in any pool using my protocol can send asynchronous payments to anyone else as long as they are *also* in a pool using my protocol (and they don't even need to be in the *same* pool)
makeasnek's avatar
makeasnek 11 months ago
I agree we should make easier abstraction for this. However, people are used to managing outbound liquidity, and linking their venmo or whatever to their bank and debit card, those are complicated things. Managing liquidity is inherent in all of that. The only difference w lightning is literally one step: manage inbound liquidity instead of just outgoing.
Super Testnet's avatar
Super Testnet 11 months ago
Your understanding is correct, but there are additional benefits. Since each user can create LN invoices and pay LN invoices, one member of the pool can create an invoice which another member of the pool then pays. The result is what you'd expect: money moves from one user of the pool to another. But the way I'm implementing it, the person P (from your description) acts as the routing node for these payments, and that person (who I call "the admin") does not charge a fee for "internal" in-pool payments. I also have him allow free payments to people in *other* pools as long as he manages those pools too. So once you get into the channel factory, you get free transactions to anyone else who used the same admin, and you *also* get to send and receive lightning payments. And thanks to my hedgehog protocol, you can also send money to someone when they are offline, and you can then *go* offline because hedgehog works in such a way that the recipient of a hedgehog transaction (which is just text, you can get it from e.g. an email or a nostr dm) can redeem it even if the creator of that transaction went offline. The way that works is this: the recipient has the preimage to a pending htlc created by the sender, and that pending htlc would, if broadcast, pay the admin, but only if the admin learns the preimage. Since the sender gave the preimage to the recipient (it's contained in the hedgehog transaction text), the recipient just contacts the admin and asks him to pay an invoice for the same amount as the pending htlc, locked to the same preimage. Which means the admin knows that if he pays the recipient's invoice, he will get reimbursed from the sender's htlc, even if the sender is offline. Voila! Asynchronous payments that are free for anyone in any pool managed by the same admin (I call a collection of such pools a "metapool"), and you can use lightning if you want to pay someone *outside* your metapool.
Super Testnet's avatar
Super Testnet 11 months ago
Regarding a diagram, first I have to make it work! Lol I'm happy all the hard parts are done, and I think I am within a few hours of finishing the integration of hedgehog payments. But I plan to release a video shortly and I will probably prepare a diagram for it. I also am presenting how this works at Bitcoin++ Floripa (https://btcplusplus.dev/conf/floripa) and showing developers how *they* can make it too. So I will probably have lots of educational material ready by then.
Aeneas's avatar
Aeneas 11 months ago
Should have used Monero 👀😅🤣
If zaps could be in XMR or BCH or other stable low fee crypto it would be a LOT less complicated than lightning. There are many cryptos that have much faster transactions and ultra low fees and decent lequidity.
Default avatar
npub1ah3a...l76e 11 months ago
Maxi mindset is the limitation here. They think because there IS A NEED for at least one hyper decentralised small blockchain ALL BKOCKCHAINS NEED to be hyper decentralised. When in fact it's enough to have BTC to keep the others in check.
You can: - download Alby Hub for macOS/windows , it uses ldk, and have it on your computer. - have it installed on an umbrel or start9, (or linux server with lnd), using the internal lnd node. - self-mount it on your own cloud using docker. - (get the Alby subscription and have it hosted on Alby Cloud) In all of these variants, each one can create isolated nwc subaccounts for friends and family, using Alby Go app. If you want a private onboarding or have a talk, hello@getalby.com
it's just people who have no patience and endurance... (though I also expected we're much faster a few years ago...)
I thought so 😔 Listen, I don’t know how everything works on your end, but if it is at all possible in the future, I’d gladly pay double in sats over lightning to just get a key on your end and not have any email involved at all. Something like Mullvad does. I love what you guys are doing and at some point might just do as you’re suggesting, but I also feel strongly that email is by and large a legacy point of weakness for both the user and the admin. Keep up the good work! 🙏