Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] multi: add new draft key send mode for spontaneous payments #2455

Open
wants to merge 14 commits into
base: master
from

Conversation

Projects
None yet
@Roasbeef
Copy link
Member

commented Jan 11, 2019

In this commit, we add new feature to lncli sendpayment (and the RPC): the ability to send a payment to a destination without first needing to have an invoice. This allows users to start exploring a new set of use cases that benefits from this type of spontaneous payment. The payment can also carry additional application-specific data such as an account ID, API call, etc. This new feature requires the new EOB (extra onion blob parsing) implemented here. The coolest part about this new feature is that it can be used today in the wild as long as both nodes are updated to this branch!

An example run on the cli:

⛰   lncli --network=simnet sendpayment --dest=02788242941915ed5a101511b8dfeb6db81e0fcd7546f6a55ef4dedf590a7d7ff4 --final_cltv_delta=144 --amt=100 --key_send
{
    "payment_error": "",
    "payment_preimage": "0b1661fb77071fa5efd2217e380c93068bc3dc6e40e302673ff6373ecd8997b5",
    "payment_route": {
        "total_time_lock": 3299,
        "total_amt": 100,
        "hops": [
            {
                "chan_id": 3610796185681920,
                "chan_capacity": 15000000,
                "amt_to_forward": 100,
                "expiry": 3299,
                "amt_to_forward_msat": 100000,
                "pub_key": "02788242941915ed5a101511b8dfeb6db81e0fcd7546f6a55ef4dedf590a7d7ff4"
            }
        ],
        "total_amt_msat": 100000
    }
}

NOTE: This is only a draft implementation and while it works today on mainnet out of the box (if both sides are upgraded) much this will likely change. Notably the modifications in the link are very hacky and will likely be refactored in preparation of AMP and the like.

Fixes #132.

@Roasbeef Roasbeef changed the title multi: add new draft sphinx send mode for spontaneous payments [WIP] multi: add new draft sphinx send mode for spontaneous payments Jan 11, 2019

@ghanavati27

This comment has been minimized.

Copy link

commented Jan 12, 2019

This is the best feature that we have in lightning !!
Thanks a lot @Roasbeef

@junderw

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2019

Looks very VERY cool.

  • I would suggest disabling this by default, and wallets like Zap etc. that link with LND can then silently enable them, or offer to enable them.
  • Also, I guess there would be some way to ping the node and check and make sure it's still currently supporting the feature.
  • Another thing I would recommend is adding an optional password/blinding key of some sort. That way you could make a "Sphinx Address" that is basically your node key, IP, and password all bech32 encoded or something, and anyone who sees that address can send payments willy nilly, and anyone who doesn't know the password (hasn't seen the "address") won't be able to send.
  • Bonus points, the "Sphinx Address" format could encode all those invoice ID etc. things you spoke of.

This would be bullish for exchange adoption.

@junderw

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2019

Imagine we have 3 users on our exchange:

Make 3 "Sphinx Addresses":

  1. bech32(nodekey = 02... || ip:port = x.x.x.x:yyyy || password = acbdefg... || accountID = 0)
  2. bech32(nodekey = 02... || ip:port = x.x.x.x:yyyy || password = acbdefg... || accountID = 1)
  3. bech32(nodekey = 02... || ip:port = x.x.x.x:yyyy || password = acbdefg... || accountID = 2)

Then we could just fetch our received payment history, check the accountID, and attribute the amount to the user's balance on our DB.

Super awesome. Can't wait. I highly recommend standardizing an "address" format though.

)

needUpdate = true
continue
// An empty EOB means they didn't send su any special

This comment has been minimized.

Copy link
@JimmyMow
@molxyz

This comment has been minimized.

Copy link

commented Jan 14, 2019

I'm running two nodes on testnet and spamming myself with tiny amounts (sphinx send ftw!) ... So I'm wondering if there's a way not to allow these spamming txs if the receiving end does not wish to be spammed?

Second question: Before making a Sphinx send should there be a question like You are about to send X amount without an invoice. Are you sure you want to do this? [yes/no]

@prusnak

This comment has been minimized.

Copy link

commented Jan 15, 2019

So I'm wondering if there's a way not to allow these spamming txs if the receiving end does not wish to be spammed?

Is there a reason why I should not want these payments although very small? Does this somehow corrupt my channel's fitness? If possible (D)DoS is the reason, there might be a better way how to perform it on a LN node.

@junderw

This comment has been minimized.

Copy link
Contributor

commented Jan 15, 2019

@Roasbeef are you writing up a BOLT for this? I'd like to collaborate on some functionality that exchanges would like. Starting with the points I made above.

@molxyz

This comment has been minimized.

Copy link

commented Jan 15, 2019

@prusnak Hi,

Is there a reason why I should not want these payments although very small? Does this somehow corrupt my channel's fitness? If possible (D)DoS is the reason, there might be a better way how to perform it on a LN node.

In the past we tested this on testnet and my node's constant stream of sending payments for several hours did crash another tester's node. I haven't tested this with Sphinx send yet, but I'm planning to test it, you can help too if you want to. (I've been only spamming myself with about 30 txs at a time. To test crashing maybe should do a few thousands of txs or more overnight... lol)

However, even with no crashing I am just wondering if someone might not like it (just wondering never know), so for caution I'm just raising the question. As for me, I would not mind to receive streams of satoshis though, the more the merrier! Haha ... :D

@Roasbeef

This comment has been minimized.

Copy link
Member Author

commented Jan 15, 2019

. So I'm wondering if there's a way not to allow these spamming txs if the receiving end does not wish to be spammed?

Nodes can reject this at will. You can already spam a node by sending them an HTLC with an unknown payment hash. If someone is spamming you by giving you free money then well....🤑

are you writing up a BOLT for this? I'd like to collaborate on some functionality that exchanges would like. Starting with the points I made above.

The main point of synchronization would be finalizing the EOB format (see the PR linked in the description). From there, we'd reserve a type, and then star to specify the behavior/encoding around that type.

@molxyz

This comment has been minimized.

Copy link

commented Jan 16, 2019

@Roasbeef First crash report!
My node crashed when I tried to Sphinx send to a node that didn't have this PR compiled. This node is running on Tor: https://paste.ee/p/rjlQZ#i9Z26p8QL9f5ZSb6MCdy0AAusFKRL8nl

Strange that my node didn't crash before when I tried the same with a non-sphinx-send node that wasn't running on Tor.

EDIT: The other node got the PR compiled after, then tried to Sphinx send to my node (we both didn't know my node crashed at the time), so he tried a sendpayment and his node crashed too, with same error.

@Roasbeef

This comment has been minimized.

Copy link
Member Author

commented Jan 16, 2019

Yeah that's a known bug due to a change in the way I handle pubkeys, easy fix, remember that this PR isn't final at all.

@Roasbeef Roasbeef force-pushed the Roasbeef:new-eob-sphinx-send branch from 5300038 to 552f239 Jan 18, 2019

@Roasbeef

This comment has been minimized.

Copy link
Member Author

commented Jan 18, 2019

Latest diff patches that issue.

@molxyz

This comment has been minimized.

Copy link

commented Jan 20, 2019

@Roasbeef It's fixed, Thank you!

Suggestion: Could we have an option to set the minimum amount that we would accept? Something like minchansize=. Maybe minsphinxsize=, or minautopayaccept=, or minsphinxaccept=, etc.. What do you think?

EDIT: And the default is 1 sat like it is now.

@jojkaart

This comment has been minimized.

Copy link

commented Jan 23, 2019

Is there a reason why I should not want these payments although very small? Does this somehow corrupt my channel's fitness? If possible (D)DoS is the reason, there might be a better way how to perform it on a LN node.

Companies are likely to prefer to reject payments which are from unknown senders to limit their legal liabilities and paperwork. If they're accepted, they have to be accounted for. The worst case is if they're accepted and not accounted for.

@sahanakk

This comment has been minimized.

Copy link

commented Apr 1, 2019

I get the following payment error when i try to send using sphinx mode.

HP-ProBook-440-G4:~/lndNodes/nodeA$ lncli --network=regtest --lnddir=./ --rpcserver=localhost:10009 sendpayment --dest=032c6076cc088982b8c72a5190c1540fedac606e8910771ba9fce890beffe16ffe --amt=1 --final_cltv_delta=500 --sphinx
{
"payment_error": "FinalExpiryTooSoon",
"payment_preimage": "",
"payment_route": null
}
`
And the other node if i try the same thing i am getting the following result

HP-ProBook-440-G4:~/lndNodes/nodeB$ lncli --network=regtest --lnddir=./ --rpcserver=localhost:11009 sendpayment --dest=03b952d074d45d0bf12634cba1d8a08a73affe3f2dd7d3531bc62c9b900a2ed585 --amt=100 --sphinx { "payment_error": "unable to find a path to destination", "payment_preimage": "", "payment_route": null }

@sahanakk sahanakk referenced this pull request Apr 3, 2019

Closed

error during payment #2877

@jooray

This comment has been minimized.

Copy link

commented Apr 21, 2019

When calling this through API on simnet, the channel is closed. On sending node, I have:

2019-04-21 12:07:53.392 [DBG] HSWC: ChannelLink(1622:1:0) Queueing keystone of ADD open circuit: (Chan ID=0:0:0, HTLC ID=12)->(Cha
n ID=1622:1:0, HTLC ID=7)
2019-04-21 12:07:53.392 [DBG] PEER: Sending UpdateAddHTLC(chan_id=c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcdebaefce
, id=7, amt=100000 mSAT, expiry=1769, hash=2b9e98c2814cc9bcb22f0ade64a95092c3fefd7ea2204759aecc6eb01df3cec2) to 172.21.0.4:9735
2019-04-21 12:07:53.448 [DBG] HSWC: ChannelLink(1622:1:0) removing Add packet (Chan ID=0:0:0, HTLC ID=12) from mailbox
2019-04-21 12:07:53.460 [DBG] PEER: Sending CommitSig(chan_id=c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcdebaefce, nu
m_htlcs=0) to 172.21.0.4:9735
2019-04-21 12:07:53.463 [DBG] PEER: Received RevokeAndAck(chan_id=c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcdebaefce
, rev=bba0d0e21cddc0ed635f9029a0c2a902e1a242f57d58f866c7c2b61842564bf2, next_point=0367647fc90b90b30983d9fa2638626722df81bfbe791dd
e32a4bda812a20a711f) from 172.21.0.4:9735
2019-04-21 12:07:53.478 [DBG] PEER: Received CommitSig(chan_id=c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcdebaefce, n
um_htlcs=0) from 172.21.0.4:9735
2019-04-21 12:07:53.485 [DBG] PEER: Sending RevokeAndAck(chan_id=c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcdebaefce,
 rev=d88d8783b7e4d460c15cff72c1d62bbd358fe8eceb8204e0ef45b5a7d4b7b4d8, next_point=0267019d91b4808ca2774bae2ea7d95eaa04adc81886778b
866c203a65d9bf2d20) to 172.21.0.4:9735
2019-04-21 12:07:53.603 [DBG] PEER: Received Error(chan_id=c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcdebaefce, err=i
nternal error) from 172.21.0.4:9735
2019-04-21 12:07:53.603 [ERR] HSWC: ChannelLink(1622:1:0) Failing link: ChannelPoint(ceefbadebc8e9c1af7fac66c28ffeeed4db8d7ad76f35
75b88848ce2b65539c9:0): received error from peer: internal error
2019-04-21 12:07:53.603 [ERR] HSWC: ChannelLink(1622:1:0) link failed, exiting htlcManager
2019-04-21 12:07:53.603 [INF] HSWC: ChannelLink(ceefbadebc8e9c1af7fac66c28ffeeed4db8d7ad76f3575b88848ce2b65539c9:0) has exited
2019-04-21 12:07:53.603 [INF] HSWC: Removing channel link with ChannelID(c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcd
ebaefce)
2019-04-21 12:07:53.603 [INF] HSWC: ChannelLink(ceefbadebc8e9c1af7fac66c28ffeeed4db8d7ad76f3575b88848ce2b65539c9:0) is stopping
2019-04-21 12:07:54.371 [INF] RPCS: Sphinx payment! preimage=2f08a1a36c9d8571bc248f144e7da73217fa80bba5fc94ccd152ad1a399f29ed

The receiving node:

2019-04-21 12:07:53.393 [DBG] PEER: Received UpdateAddHTLC(chan_id=c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcdebaefc
e, id=7, amt=100000 mSAT, expiry=1769, hash=2b9e98c2814cc9bcb22f0ade64a95092c3fefd7ea2204759aecc6eb01df3cec2) from 172.21.0.3:4791
6
2019-04-21 12:07:53.460 [DBG] PEER: Received CommitSig(chan_id=c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcdebaefce, n
um_htlcs=0) from 172.21.0.3:47916
2019-04-21 12:07:53.463 [DBG] PEER: Sending RevokeAndAck(chan_id=c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcdebaefce,
 rev=bba0d0e21cddc0ed635f9029a0c2a902e1a242f57d58f866c7c2b61842564bf2, next_point=0367647fc90b90b30983d9fa2638626722df81bfbe791dde
32a4bda812a20a711f) to 172.21.0.3:47916
2019-04-21 12:07:53.477 [DBG] PEER: Sending CommitSig(chan_id=c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcdebaefce, nu
m_htlcs=0) to 172.21.0.3:47916
2019-04-21 12:07:53.485 [DBG] PEER: Received RevokeAndAck(chan_id=c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcdebaefce
, rev=d88d8783b7e4d460c15cff72c1d62bbd358fe8eceb8204e0ef45b5a7d4b7b4d8, next_point=0267019d91b4808ca2774bae2ea7d95eaa04adc81886778
b866c203a65d9bf2d20) from 172.21.0.3:47916
2019-04-21 12:07:53.501 [DBG] INVC: Settling invoice 2b9e98c2814cc9bcb22f0ade64a95092c3fefd7ea2204759aecc6eb01df3cec2
2019-04-21 12:07:53.501 [ERR] HSWC: ChannelLink(1622:1:0) Failing link: unable to settle invoice: unable to locate invoice
2019-04-21 12:07:53.501 [ERR] HSWC: ChannelLink(1622:1:0) link failed, exiting htlcManager
2019-04-21 12:07:53.502 [INF] HSWC: ChannelLink(ceefbadebc8e9c1af7fac66c28ffeeed4db8d7ad76f3575b88848ce2b65539c9:0) has exited
2019-04-21 12:07:53.502 [INF] HSWC: Removing channel link with ChannelID(c93955b6e28c84885b57f376add7b84dedeeff286cc6faf71a9c8ebcd
ebaefce)

Both nodes run this branch.

API called with destString=nodepubkey, amt=100, final_cltv_delta=144, sphinx:true

@rikur

This comment has been minimized.

Copy link

commented Apr 27, 2019

I'd love to put invoice-free payments to use :)

@Roasbeef Roasbeef force-pushed the Roasbeef:new-eob-sphinx-send branch from 552f239 to 2b0fec8 May 17, 2019

@Roasbeef

This comment has been minimized.

Copy link
Member Author

commented May 17, 2019

Just updated this branch to use the latest version of the EOB encoding format and TLV! Tested locally and it works just the same as before, and the API is also unchanged as well. The current format is what will likely end up being used in BOLT 1.1, so it shouldn't change any longer.

@Roasbeef Roasbeef force-pushed the Roasbeef:new-eob-sphinx-send branch from 2b0fec8 to 2cd0f9b May 17, 2019

@Roasbeef

This comment has been minimized.

Copy link
Member Author

commented May 17, 2019

To avoid any confusion, I renamed the "sphinx" options to "keysend", it's more descriptive of the new payment mode as it only needs a pubkey to send a payment to another node.

@Roasbeef Roasbeef changed the title [WIP] multi: add new draft sphinx send mode for spontaneous payments [WIP] multi: add new draft key send mode for spontaneous payments May 21, 2019

@HugoDoyon

This comment has been minimized.

Copy link

commented Jun 13, 2019

Love this new feature! So many more use case will be possible with it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.