Hampus Sjöberg [ARCHIVE] on Nostr: 📅 Original date posted:2019-08-13 📝 Original message: While I do agree that ...
đź“… Original date posted:2019-08-13
đź“ť Original message:
While I do agree that this is a problem that we needs to be addressed
somehow, I don't agree on your proposal because I don't think we should
connect two end-users this way. It won't work out in the long run because
if you connect say mobile wallets this way, one mobile could be offline,
which locks the funds for the other part.
Another approach could be that wallets start using the already existing
fallback tag (`f`) on BOLT11 invoices, where you can embed a Bitcoin
address.
This way, the sender could send the funds on-chain should it fail to send
over Lightning.
This however requires the sender to have off-chain funds available which is
probably not the case. What could be done here is a splice out or a
submarine swap, but they are not well established yet unfortunately.
Another way is to set up a "temporary" custodian channel if the receiver
doesn't have enough inbound capacity.
How it would work is that you have a third party custodian (i.e the wallet
provider) receives the money on your behalf. The next time you want to send
something, this channel takes top priority.
This way the on-boarding process is pretty much solved, if you are OK with
some trust.
What do you think?
Cheers
Hampus
Den mĂĄn 12 aug. 2019 kl 05:43 skrev Ecurrencyhodler Blockchains <
ecurrencyhodler at gmail.com>:
> Hi. I'd like to propose a way for instant inbound liquidity to be
> automated via invoices and would appreciate your feedback. It's similar to
> Thor's instant channel but this proposal would only be valuable if it
> becomes a standard across all lightning implementations and wallets. It
> won't work if it's limited to just one Lightning wallet.
>
> *Proposal:* Automated Inbound Liquidity With Invoices
>
> *For Who:* Full Lightning Network nodes
>
> *Problem:* Waiting for inbound liquidity as channel establishes when you
> first come online and want to receive a LN payment.
>
> *Solution: *Embedding the node uri of the invoice creator, along with
> amount to be routed.
>
> *Scenario: *
>
> 1. Bob wants to send me 100,000 sats.
> 2. My node just came online and has 0 inbound liquidity.
> 3. I create an invoice for 100,000 sats. My LN node recognizes I have
> 0 inbound liquidity so my wallet also embeds my URI in the invoice.
> 4. Bob’s wallet sees an invoice + uri. Maybe even tries to route.
> When it doesn’t see anything, it auto opens a channel + pushes 100,000 sat
> payment.
> 5. I now own and can spend 100,000 sats instantly.
>
> *Considerations:*
>
> - This auto establishing of channels and pushing payments isn’t for
> all LN nodes. Just routing nodes.
> - Bob doesn’t need to be the one to establish the channel. He can
> push the information down the line until a node dedicated to routing is
> found. The routing node can then be the one to establish the channel with
> me.
> - Certain specifics need to be flushed out such as the size of Bob’s
> channel. Right now I think Bob can manually set the size of the channels
> to be established on his end. Should be smaller channels at first. If the
> person gets paid again, just establish another channel towards the same
> node if there isn't enough capacity.
> - Routing nodes who provide this service can charge a premium.
> - Bob, as a liquidity provider, won't cheat against himself so I can
> make LN payments instantly.
> - The beauty behind this proposal is that I can receive a payment
> instantly, I can send payments instantly, and that it hides everything from
> me as an end user.
> - Can possibly be extended to neutrino LN wallets if they are public.
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190813/7f534589/attachment.html>;
đź“ť Original message:
While I do agree that this is a problem that we needs to be addressed
somehow, I don't agree on your proposal because I don't think we should
connect two end-users this way. It won't work out in the long run because
if you connect say mobile wallets this way, one mobile could be offline,
which locks the funds for the other part.
Another approach could be that wallets start using the already existing
fallback tag (`f`) on BOLT11 invoices, where you can embed a Bitcoin
address.
This way, the sender could send the funds on-chain should it fail to send
over Lightning.
This however requires the sender to have off-chain funds available which is
probably not the case. What could be done here is a splice out or a
submarine swap, but they are not well established yet unfortunately.
Another way is to set up a "temporary" custodian channel if the receiver
doesn't have enough inbound capacity.
How it would work is that you have a third party custodian (i.e the wallet
provider) receives the money on your behalf. The next time you want to send
something, this channel takes top priority.
This way the on-boarding process is pretty much solved, if you are OK with
some trust.
What do you think?
Cheers
Hampus
Den mĂĄn 12 aug. 2019 kl 05:43 skrev Ecurrencyhodler Blockchains <
ecurrencyhodler at gmail.com>:
> Hi. I'd like to propose a way for instant inbound liquidity to be
> automated via invoices and would appreciate your feedback. It's similar to
> Thor's instant channel but this proposal would only be valuable if it
> becomes a standard across all lightning implementations and wallets. It
> won't work if it's limited to just one Lightning wallet.
>
> *Proposal:* Automated Inbound Liquidity With Invoices
>
> *For Who:* Full Lightning Network nodes
>
> *Problem:* Waiting for inbound liquidity as channel establishes when you
> first come online and want to receive a LN payment.
>
> *Solution: *Embedding the node uri of the invoice creator, along with
> amount to be routed.
>
> *Scenario: *
>
> 1. Bob wants to send me 100,000 sats.
> 2. My node just came online and has 0 inbound liquidity.
> 3. I create an invoice for 100,000 sats. My LN node recognizes I have
> 0 inbound liquidity so my wallet also embeds my URI in the invoice.
> 4. Bob’s wallet sees an invoice + uri. Maybe even tries to route.
> When it doesn’t see anything, it auto opens a channel + pushes 100,000 sat
> payment.
> 5. I now own and can spend 100,000 sats instantly.
>
> *Considerations:*
>
> - This auto establishing of channels and pushing payments isn’t for
> all LN nodes. Just routing nodes.
> - Bob doesn’t need to be the one to establish the channel. He can
> push the information down the line until a node dedicated to routing is
> found. The routing node can then be the one to establish the channel with
> me.
> - Certain specifics need to be flushed out such as the size of Bob’s
> channel. Right now I think Bob can manually set the size of the channels
> to be established on his end. Should be smaller channels at first. If the
> person gets paid again, just establish another channel towards the same
> node if there isn't enough capacity.
> - Routing nodes who provide this service can charge a premium.
> - Bob, as a liquidity provider, won't cheat against himself so I can
> make LN payments instantly.
> - The beauty behind this proposal is that I can receive a payment
> instantly, I can send payments instantly, and that it hides everything from
> me as an end user.
> - Can possibly be extended to neutrino LN wallets if they are public.
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190813/7f534589/attachment.html>;