đź“… 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>;
Hampus Sjöberg [ARCHIVE] /
npub10u…hln8t
2023-06-09 12:55:53
in reply to nevent1q…peye
Author Public Key
npub10uzud4rf4636awmfgvarmcfndcmdnv8rfd2y3rx2sqgckv9zur4qahln8tPublished at
2023-06-09 12:55:53Event JSON
{
"id": "5c60c778706005ba58f510e397a51af5e74dd0d4c4080c761b4fe355ddbb0f48",
"pubkey": "7f05c6d469aea3aebb69433a3de1336e36d9b0e34b54488cca80118b30a2e0ea",
"created_at": 1686315353,
"kind": 1,
"tags": [
[
"e",
"1c39eae9671d2c1d6980d1805557b73d6dfe4ed0d66d378b24b3cc4a457ed1ce",
"",
"root"
],
[
"e",
"85f9b914d96e6a3648bc31963e1ace3bab6b7f47eb9b49fa4ca692240169d8a2",
"",
"reply"
],
[
"p",
"82d6077d7e9fc767f79a3b14d0e51d7e73027f37059ce2eed95688c84021cd3a"
]
],
"content": "📅 Original date posted:2019-08-13\n📝 Original message:\nWhile I do agree that this is a problem that we needs to be addressed\nsomehow, I don't agree on your proposal because I don't think we should\nconnect two end-users this way. It won't work out in the long run because\nif you connect say mobile wallets this way, one mobile could be offline,\nwhich locks the funds for the other part.\n\nAnother approach could be that wallets start using the already existing\nfallback tag (`f`) on BOLT11 invoices, where you can embed a Bitcoin\naddress.\nThis way, the sender could send the funds on-chain should it fail to send\nover Lightning.\nThis however requires the sender to have off-chain funds available which is\nprobably not the case. What could be done here is a splice out or a\nsubmarine swap, but they are not well established yet unfortunately.\n\nAnother way is to set up a \"temporary\" custodian channel if the receiver\ndoesn't have enough inbound capacity.\nHow it would work is that you have a third party custodian (i.e the wallet\nprovider) receives the money on your behalf. The next time you want to send\nsomething, this channel takes top priority.\nThis way the on-boarding process is pretty much solved, if you are OK with\nsome trust.\n\nWhat do you think?\n\nCheers\nHampus\n\nDen mån 12 aug. 2019 kl 05:43 skrev Ecurrencyhodler Blockchains \u003c\necurrencyhodler at gmail.com\u003e:\n\n\u003e Hi. I'd like to propose a way for instant inbound liquidity to be\n\u003e automated via invoices and would appreciate your feedback. It's similar to\n\u003e Thor's instant channel but this proposal would only be valuable if it\n\u003e becomes a standard across all lightning implementations and wallets. It\n\u003e won't work if it's limited to just one Lightning wallet.\n\u003e\n\u003e *Proposal:* Automated Inbound Liquidity With Invoices\n\u003e\n\u003e *For Who:* Full Lightning Network nodes\n\u003e\n\u003e *Problem:* Waiting for inbound liquidity as channel establishes when you\n\u003e first come online and want to receive a LN payment.\n\u003e\n\u003e *Solution: *Embedding the node uri of the invoice creator, along with\n\u003e amount to be routed.\n\u003e\n\u003e *Scenario: *\n\u003e\n\u003e 1. Bob wants to send me 100,000 sats.\n\u003e 2. My node just came online and has 0 inbound liquidity.\n\u003e 3. I create an invoice for 100,000 sats. My LN node recognizes I have\n\u003e 0 inbound liquidity so my wallet also embeds my URI in the invoice.\n\u003e 4. Bob’s wallet sees an invoice + uri. Maybe even tries to route.\n\u003e When it doesn’t see anything, it auto opens a channel + pushes 100,000 sat\n\u003e payment.\n\u003e 5. I now own and can spend 100,000 sats instantly.\n\u003e\n\u003e *Considerations:*\n\u003e\n\u003e - This auto establishing of channels and pushing payments isn’t for\n\u003e all LN nodes. Just routing nodes.\n\u003e - Bob doesn’t need to be the one to establish the channel. He can\n\u003e push the information down the line until a node dedicated to routing is\n\u003e found. The routing node can then be the one to establish the channel with\n\u003e me.\n\u003e - Certain specifics need to be flushed out such as the size of Bob’s\n\u003e channel. Right now I think Bob can manually set the size of the channels\n\u003e to be established on his end. Should be smaller channels at first. If the\n\u003e person gets paid again, just establish another channel towards the same\n\u003e node if there isn't enough capacity.\n\u003e - Routing nodes who provide this service can charge a premium.\n\u003e - Bob, as a liquidity provider, won't cheat against himself so I can\n\u003e make LN payments instantly.\n\u003e - The beauty behind this proposal is that I can receive a payment\n\u003e instantly, I can send payments instantly, and that it hides everything from\n\u003e me as an end user.\n\u003e - Can possibly be extended to neutrino LN wallets if they are public.\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190813/7f534589/attachment.html\u003e",
"sig": "7d576851d74cb336a716d7fa2d69a80524902737ec3e220c3981db1f27caa569bf4f2c9de853b24a874f20df8176066edb5318617d1ef1ea35e8bb16dac4d10e"
}