ecurrencyhodler [ARCHIVE] on Nostr: đź“… Original date posted:2019-08-13 đź“ť Original message: Hi Hampus! >It won't work ...
đź“… Original date posted:2019-08-13
đź“ť Original message:
Hi Hampus!
>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.
Hmm I didn't consider mobile wallets being offline for a long period of
time. That's a good point. But if smaller channels are preferred and they
are charging a premium, I wonder if the opportunity cost here would be
worth it. It's also possible to set shorter HTLC's for unilateral closures
for these specific channels.
>Another approach could be that wallets start using the already existing
fallback tag (`f`) on BOLT11 invoices, where you can embed a Bitcoin
address.
You know I actually really like this feature of LN invoices. It's very
practical and a great stop gap. My only gripe is that it keeps the user
off the LN and they still would have to wait confirmations in order for
their BTC to be "confirmed". Automating inbound liquidity with push
payments would make it instant as well as keep users on the LN.
>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.
Yea. This is a great suggestion. And probably where things will end up
for mobile neutrino Ln wallets in the near future. But the benefits to
automating inbound liquidity with invoices is that it would be
non-custodial while offering almost the exact same experience.
On Tue, Aug 13, 2019 at 6:31 AM Hampus Sjöberg <hampus.sjoberg at gmail.com>
wrote:
> 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/5a9a3fbd/attachment-0001.html>;
đź“ť Original message:
Hi Hampus!
>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.
Hmm I didn't consider mobile wallets being offline for a long period of
time. That's a good point. But if smaller channels are preferred and they
are charging a premium, I wonder if the opportunity cost here would be
worth it. It's also possible to set shorter HTLC's for unilateral closures
for these specific channels.
>Another approach could be that wallets start using the already existing
fallback tag (`f`) on BOLT11 invoices, where you can embed a Bitcoin
address.
You know I actually really like this feature of LN invoices. It's very
practical and a great stop gap. My only gripe is that it keeps the user
off the LN and they still would have to wait confirmations in order for
their BTC to be "confirmed". Automating inbound liquidity with push
payments would make it instant as well as keep users on the LN.
>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.
Yea. This is a great suggestion. And probably where things will end up
for mobile neutrino Ln wallets in the near future. But the benefits to
automating inbound liquidity with invoices is that it would be
non-custodial while offering almost the exact same experience.
On Tue, Aug 13, 2019 at 6:31 AM Hampus Sjöberg <hampus.sjoberg at gmail.com>
wrote:
> 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/5a9a3fbd/attachment-0001.html>;