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

Roasbeef · 2019-01-11T05:40:12Z

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.

ghanavati27 · 2019-01-12T05:24:19Z

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

junderw · 2019-01-12T13:15:08Z

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 · 2019-01-12T13:19:17Z

Imagine we have 3 users on our exchange:

Make 3 "Sphinx Addresses":

bech32(nodekey = 02... || ip:port = x.x.x.x:yyyy || password = acbdefg... || accountID = 0)
bech32(nodekey = 02... || ip:port = x.x.x.x:yyyy || password = acbdefg... || accountID = 1)
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.

JimmyMow · 2019-01-12T15:02:47Z

htlcswitch/link.go

 				)

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


molxyz · 2019-01-14T21:22:55Z

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 · 2019-01-15T08:37:02Z

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 · 2019-01-15T09:29:15Z

@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 · 2019-01-15T23:17:40Z

@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 · 2019-01-15T23:48:33Z

. 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 · 2019-01-16T13:09:24Z

@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 · 2019-01-16T20:55:25Z

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 · 2019-01-18T00:28:41Z

Latest diff patches that issue.

molxyz · 2019-01-20T15:33:29Z

@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 · 2019-01-23T10:54:12Z

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 · 2019-04-01T11:32:22Z

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 }

jooray · 2019-04-21T12:28:02Z

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 · 2019-04-27T03:42:04Z

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

Roasbeef · 2019-05-17T04:14:25Z

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.

…ly if valid

Roasbeef · 2019-05-17T20:49:03Z

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.

HugoDoyon · 2019-06-13T16:20:19Z

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

stridentbean · 2019-07-30T16:45:05Z

@Roasbeef Is there a target release date for this feature? Will it be released this quarter and will be in lnd 0.8.0?

whiteyhat · 2019-07-30T20:28:02Z

@Roasbeef Is there a target release date for this feature? Will it be released this quarter and will be in lnd 0.8.0?

I wish that too 🙏

araujobsd · 2019-08-13T07:50:21Z

Neat feature!!! Is there any plan, progress or BOLT for it? @Roasbeef @junderw

junderw · 2019-08-13T11:40:06Z

@Roasbeef features such as a password and extra ID space would be awesome for exchanges.

RubenWaterman · 2019-10-01T12:46:07Z

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 I'm playing around with this feature and I'm wondering if it's possible to make a REST API call to do a payment like this (https://api.lightning.community/rest/?shell#v1-channels-transactions)?

RubenWaterman · 2019-10-12T15:14:51Z

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 I'm playing around with this feature and I'm wondering if it's possible to make a REST API call to do a payment like this (https://api.lightning.community/rest/?shell#v1-channels-transactions)?

So I never got this to work with the gRPC API but it works fine with the REST API. For anyone else running into this problem, this is how you do a spontaneous payment from the API:

curl -X POST \
  https://ip-address:8080/v1/channels/transactions \
  -H 'Grpc-Metadata-macaroon: DECODEDMACAROON' \
  -d '{ 
    "dest_string": "03499b48b8fbbbb4d0ba86042030f86275a746bc34d5ce6dcebde771cc2a21c1a4", 
    "amt": "1",
    "final_cltv_delta": 144, 
    "key_send": true
}'

My next question using this experimental new feature; the invoice that's created when doing a spontaneous payment is not stored anywhere, i.e.:

2019-10-12 14:26:31.330 [INF] INVC: TLV packet other: 8000203e886982049d3ebf1ae4eae84fac05c13c466cafed234cde8704fb9a9bda3ad5ff0000000000000000000000000000000000000000000000000000000000
2019-10-12 14:26:31.330 [DBG] INVC: Invoice(fdbd745e11fe417fb584506c1174a43227c959b2a19efec5a756cec24edfb672): settled, amt=65242000 mSAT, expiry=1582964
2019-10-12 14:26:31.330 [DBG] HSWC: ChannelLink(1582812:61:1) Received hodl settle event for fdbd745e11fe417fb584506c1174a43227c959b2a19efec5a756cec24edfb672

At first, I thought this was an issue with Zap wallet (which is connected to my receiving node) as the spontaneous payments never show up, but in fact, if I just call https://ip-address:8080/v1/invoice/fdbd745e11fe417fb584506c1174a43227c959b2a19efec5a756cec24edfb672 I get "unable to locate invoice" or if I call https://ip-address:8080/v1/invoices/ the spontaneous payment invoices don't show up :(

Has anyone else ran into this issue?

Roasbeef · 2019-12-25T00:00:23Z

Superseded by #3795.

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

JimmyMow reviewed Jan 12, 2019

View reviewed changes

Roasbeef added payments Related to invoices/payments spec P3 might get fixed, nice to have incomplete WIP PR, not fully finalized, but light review possible labels Jan 16, 2019

Roasbeef force-pushed the new-eob-sphinx-send branch from 5300038 to 552f239 Compare January 18, 2019 00:27

baebb mentioned this pull request Jan 21, 2019

Redeem voucher to wallet donnerlab1/lightning-voucher#3

Open

joostjager mentioned this pull request Jan 22, 2019

htlcswitch: hodl invoice #2022

Merged

Roasbeef mentioned this pull request Jan 23, 2019

Implement non-interactive payments by including the preimage in the Sphinx e2e payload #132

Closed

5 tasks

phm87 mentioned this pull request Feb 21, 2019

Lightning Network (testnet) tpruvot/yiimp#292

Open

sahanakk mentioned this pull request Apr 3, 2019

error during payment #2877

Closed

Roasbeef mentioned this pull request Apr 30, 2019

router+build: update to the latest version of lightning-onion #3027

Merged

watchtower/wtwire/wtwire: extend ReadElement to check read length

936bcc4

Roasbeef added 3 commits May 16, 2019 21:08

build: temporarily point to roasbeef's lightning-onion fork

c90e5eb

routing: extend LightningPayment to allow user specified EOB data

ffe1eba

htlcswitch: expose ExtraOnionBlob in HopIterator

c222d86

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

Roasbeef added 7 commits May 17, 2019 13:47

lnrpc: add new KeySend option to SendPayment for spontaneous payments

4fe85ba

cmd/lncli: add parsing for new key_send option to sendpayment

9eef712

rpc: add keysend payment preimage generation

2265ca3

multi: extend NotifyExitHop to accept an opauqe EOB

c9a38a8

routing/route: update to use new sphinx.NewHopPayload API

57e59a2

watchtwoer/wtire: add case for *[32]byte to WriteElement

b5e64fb

invoices: detect pre-images encoded in the EOB TLV and settle instant…

2cd0f9b

…ly if valid

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

kincaidoneil mentioned this pull request May 19, 2019

Add support for spontaneous payments interledgerjs/settlement-lightning#33

Open

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

kilrau mentioned this pull request Jul 24, 2019

Add sendpayment calls to SwapClient ExchangeUnion/xud#1118

Closed

2 tasks

gakonst mentioned this pull request Aug 29, 2019

Redemption via Lightning keep-network/tbtc#262

Open

ossel mentioned this pull request Sep 29, 2019

[Feature Request] enable contact book payment experience #3555

Closed

molxyz mentioned this pull request Nov 4, 2019

[Feature Request] mutually funded channels implementation #3673

Closed

joostjager mentioned this pull request Dec 5, 2019

lncli+invoices: experimental key send mode #3795

Merged

Roasbeef closed this Dec 25, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

Roasbeef commented Jan 11, 2019 •

edited

Loading

ghanavati27 commented Jan 12, 2019

junderw commented Jan 12, 2019

junderw commented Jan 12, 2019

JimmyMow Jan 12, 2019

molxyz commented Jan 14, 2019

prusnak commented Jan 15, 2019

junderw commented Jan 15, 2019

molxyz commented Jan 15, 2019 •

edited

Loading

Roasbeef commented Jan 15, 2019

molxyz commented Jan 16, 2019 •

edited

Loading

Roasbeef commented Jan 16, 2019

Roasbeef commented Jan 18, 2019

molxyz commented Jan 20, 2019 •

edited

Loading

jojkaart commented Jan 23, 2019

sahanakk commented Apr 1, 2019 •

edited

Loading

jooray commented Apr 21, 2019

rikur commented Apr 27, 2019

Roasbeef commented May 17, 2019

Roasbeef commented May 17, 2019

HugoDoyon commented Jun 13, 2019 •

edited

Loading

stridentbean commented Jul 30, 2019 •

edited

Loading

whiteyhat commented Jul 30, 2019

araujobsd commented Aug 13, 2019

junderw commented Aug 13, 2019

RubenWaterman commented Oct 1, 2019 •

edited

Loading

RubenWaterman commented Oct 12, 2019

Roasbeef commented Dec 25, 2019

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

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

Conversation

Roasbeef commented Jan 11, 2019 • edited Loading

ghanavati27 commented Jan 12, 2019

junderw commented Jan 12, 2019

junderw commented Jan 12, 2019

JimmyMow Jan 12, 2019

Choose a reason for hiding this comment

molxyz commented Jan 14, 2019

prusnak commented Jan 15, 2019

junderw commented Jan 15, 2019

molxyz commented Jan 15, 2019 • edited Loading

Roasbeef commented Jan 15, 2019

molxyz commented Jan 16, 2019 • edited Loading

Roasbeef commented Jan 16, 2019

Roasbeef commented Jan 18, 2019

molxyz commented Jan 20, 2019 • edited Loading

jojkaart commented Jan 23, 2019

sahanakk commented Apr 1, 2019 • edited Loading

jooray commented Apr 21, 2019

rikur commented Apr 27, 2019

Roasbeef commented May 17, 2019

Roasbeef commented May 17, 2019

HugoDoyon commented Jun 13, 2019 • edited Loading

stridentbean commented Jul 30, 2019 • edited Loading

whiteyhat commented Jul 30, 2019

araujobsd commented Aug 13, 2019

junderw commented Aug 13, 2019

RubenWaterman commented Oct 1, 2019 • edited Loading

RubenWaterman commented Oct 12, 2019

Roasbeef commented Dec 25, 2019

Roasbeef commented Jan 11, 2019 •

edited

Loading

molxyz commented Jan 15, 2019 •

edited

Loading

molxyz commented Jan 16, 2019 •

edited

Loading

molxyz commented Jan 20, 2019 •

edited

Loading

sahanakk commented Apr 1, 2019 •

edited

Loading

HugoDoyon commented Jun 13, 2019 •

edited

Loading

stridentbean commented Jul 30, 2019 •

edited

Loading

RubenWaterman commented Oct 1, 2019 •

edited

Loading