--- Log opened Wed May 06 00:00:14 2020
00:05 -!- achow101 [~achow101@unaffiliated/achow101] has joined #c-lightning
00:23 -!- Educob2 [5a4ae098@90.74.224.152] has joined #c-lightning
00:24 < Educob2> I have decoded an unpaid invoice created by another node and I can see the payment secret. Am I supposed to know the payment secret before paying?
00:24 < zmnscpxj_> there are two secrets involved in payment
00:24 < zmnscpxj_> one is known by the payee only
00:25 < zmnscpxj_> the other is shared by the payee to the payer, and is used to provide payment privacy by preventing third-party probing
00:25 < zmnscpxj_> the payment secret you see in decoding an unpaid invoice is the second one
00:25 < zmnscpxj_> the payee will reject payments unless the payment packet includes the secret it shared in the invoice
00:26 < zmnscpxj_> sorry, confusing terminology, at the BOLT level at that
00:26 < zmnscpxj_> the HTLCs use the first secret, the one that is known by the payee only before payment
00:26 < zmnscpxj_> does that clarify things?
00:27 < zmnscpxj_> Do you want to learn more about why the second secret exists?
00:33 < Educob2> Thanks.
00:34 < Educob2> Yes. Why the 2nd secret?
00:34 < zmnscpxj_> suppose I am an arbitrary forwarding node
00:34 < zmnscpxj_> I receive a forwarding request
00:34 < zmnscpxj_> I do not know who is the final recipient
00:34 < zmnscpxj_> but I do know that there is an outgoing CLTV requirement
00:35 < zmnscpxj_> so the final recipient must be within that outgoing CLTV requirement
00:35 < zmnscpxj_> I can start with the next hop, then try further hops beyond that, as long as the CLTV requirement is not violated
00:35 < zmnscpxj_> if I guess correctly, then I know who exactly is the final payee.
00:36 < zmnscpxj_> I do this not by using the onion packet I receive in the forwarding request
00:36 < zmnscpxj_> I make up my own new onion, as if I was the original payer
00:37 < zmnscpxj_> By requiring a second secret that is known by the payee and which it shared with the original payer, this probing is prevented
00:37 < zmnscpxj_> I also need to guess the second secret, which is basically not going to happen
00:39 < Educob2> Wow. It's convoluted. I have read the bolts three times and there are so many details I don't get. Thanks for the explanation
00:52 -!- sr_gi_ [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has quit [Ping timeout: 265 seconds]
00:54 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-txhnryyccoeyadae] has left #c-lightning []
00:55 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-txhnryyccoeyadae] has joined #c-lightning
01:15 -!- sr_gi [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has joined #c-lightning
02:15 -!- sr_gi [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
02:28 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
02:34 -!- sr_gi [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has joined #c-lightning
02:52 -!- Kostenko [~Kostenko@92.250.100.89] has joined #c-lightning
03:30 -!- Educob2 [5a4ae098@90.74.224.152] has quit [Remote host closed the connection]
03:33 -!- kristapsk___ is now known as kristapsk
03:54 -!- sr_gi [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
03:55 -!- sr_gi [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has joined #c-lightning
04:06 -!- sr_gi [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has quit [Read error: Connection reset by peer]
04:06 -!- sr_gi_ [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has joined #c-lightning
04:14 -!- sr_gi_ [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
04:18 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
04:19 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
04:50 -!- jonatack_ [~jon@37.166.24.197] has joined #c-lightning
04:50 -!- sr_gi [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has joined #c-lightning
04:53 -!- jonatack [~jon@37.164.75.174] has quit [Ping timeout: 256 seconds]
05:02 -!- jonatack_ [~jon@37.166.24.197] has quit [Quit: jonatack_]
05:17 -!- jonatack [~jon@37.166.24.197] has joined #c-lightning
05:21 -!- jonatack_ [~jon@134.19.179.195] has joined #c-lightning
05:21 -!- jonatack [~jon@37.166.24.197] has quit [Ping timeout: 272 seconds]
05:21 -!- jonatack_ [~jon@134.19.179.195] has quit [Client Quit]
05:22 -!- jonatack [~jon@134.19.179.195] has joined #c-lightning
05:39 -!- sr_gi [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
05:39 -!- sr_gi [~sr_gi@128.red-79-154-168.dynamicip.rima-tde.net] has joined #c-lightning
05:42 < fiatjaf> ~
05:43 -!- fiatjaf [~fiatjaf@2804:7f2:2a84:199d:ea40:f2ff:fe85:d2dc] has quit [Quit: WeeChat 2.6]
05:43 -!- fiatjaf [~fiatjaf@2804:7f2:2a84:199d:ea40:f2ff:fe85:d2dc] has joined #c-lightning
05:43 < fiatjaf> can we have multiple rpc_command plugins?
05:58 < fiatjaf> I think no, but structure for having that is in place, right?
05:58 < darosior> fiatjaf: Not atm
05:58 < darosior> Hmm yeah about the structure
06:11 <@cdecker> Yep, just need to switch from a single hook to a chained hook and it should work. Not sure about the semantics though (are hooks allowed to change the command payload, what if we terminate the command in a plugin instead of `continue`, ...)
06:12 <@cdecker> If you have a good idea on how the semantics should work let us know and we can open it up ^^
06:16 < darosior> "Chaining rpc_command hook" or "Double barrel footgun" x)
06:16 <@cdecker> With a scope ^^
06:20 < fiatjaf> well, my humble understanding is that "continue" should cancel that hook and call the next
06:20 < fiatjaf> if one wants to change the command payload it can call the same command from inside the hook
06:20 < fiatjaf> and pass along an extra parameter as a flag that it must be skipped by itself
06:20 < fiatjaf> or some other gimmick
06:21 < fiatjaf> without lightningd having to understand a bunch of different things, it can just know very little and blindly delegate calls to plugins
06:25 < fiatjaf> for example, plugin A register an rpc_command hook like `if method == getinfo and not params[skipmyself] { p = call('getinfo', {skipmyself: true}); change_payload_somehow(p); return p } else { return continue }`
06:26 < fiatjaf> if we terminate it's terminated with and error or result the response is returned, I don't see how it could be different here.
06:34 -!- Kostenko [~Kostenko@92.250.100.89] has quit [Ping timeout: 246 seconds]
06:37 <@cdecker> Issue is that the RPC commands called from the plugin would again end up in the `rpc_command` hook, so it's pretty much `continue` or `fail` from inside the hook, and we can (and I think do) allow the plugin to rewrite the call before telling `lightningd` to `continue`
07:08 -!- Kostenko [~Kostenko@83.223.242.55] has joined #c-lightning
07:11 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
07:19 -!- jasan [~jasan@tunnel509499-pt.tunnel.tserv27.prg1.ipv6.he.net] has joined #c-lightning
07:37 -!- jasan is now known as nisim
07:37 -!- nisim is now known as jasan
07:45 < fiatjaf> cdecker: that's why I gave it that extra param "skipmyself", which would allow the next hook call to just return "continue" without falling into an infinite loop.
07:46 < fiatjaf> that's one way I came up with to allow plugins to effectively modify the payload without having to introduce more complexity on lightningd for just a corner case
07:46 < fiatjaf> doesn't it work?
07:47 < fiatjaf> anyway, if it's easy enough to allow explicit payload modification then that could work too -- but I think it isn't that simple
07:49 < fiatjaf> imagine you have the plugin returning something like {"payload": <new_payload>}, but it wants that modified payload to be applied to the next plugin registering the same hook -- however that was already called before in the lightningd sorting of plugin hooks to call, and now there must be introduced a way for plugin authors to decide on that ordering, and they may not agree among themselves on
07:49 < fiatjaf> particular numbers
07:49 < fiatjaf> I believe my suggestion may have advantages on that aspect too and I'm not seeing the downsides
07:50 < fiatjaf> hmm, maybe the user should decide the plugin ordering instead of plugin authors, that would be better and probably simpler 
07:51 < fiatjaf> the ordering could even be just lexicographical from the plugin file names or something like that
08:45 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
08:51 <@cdecker> Ah, I hadn't seen the `skipmyself` param, that's a good idea ^^
08:52 <@cdecker> For security critical things that should probably be a random (non-guessable) value, so callers can't bypass the rpc_command hook by just adding it initially
08:54 <@cdecker> As for ordering I think we'll eventually add a `priority` field to the registration (making the array of strings for hooks in the manifest a list of objects, or even a dict `"hookname": {'priority': 1000}`) that'd then allow us to sort the hooks before calling them :-)
09:02 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-txhnryyccoeyadae] has left #c-lightning []
09:02 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-txhnryyccoeyadae] has joined #c-lightning
09:03 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
09:19 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
09:22 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
09:22 -!- vasild_ is now known as vasild
09:35 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
09:36 -!- rh0nj [~rh0nj@88.99.167.175] has joined #c-lightning
10:09 < darosior> "For security critical things that should probably be a random (non-guessable) value, so callers can't bypass the rpc_command hook by just adding it initially" > One can still bypass rpc_command by killing the plugin or writing on its fd anyway (almost always possible if you can write to the RPC socket) :/
10:14 < fiatjaf> I got 3 channels closed in the same block (not using any fancy bitcoin backend this time, darosior), why could that be?
10:14 < fiatjaf> 629122
10:18  * darosior looks everywhere for his crystal ball, failing to find any
10:19  * darosior thinks a debug.log would be better anyway
10:20 < darosior> fiatjaf could you https://0bin.net your debug.log please ? :/
10:20 < darosior> Are you running 0.8.2 yet ?
10:21 < darosior> I personally experienced a *lot* of channel closing on reconnection because of our update_fee unsupported by some implems' old clients
10:21 < darosior> (The one sent just after reconnect)
10:22 < fiatjaf> no, I've stopped the logs in debug mode
10:23 < fiatjaf> that thing is very verbose
10:23 < fiatjaf> was driving me nuts
10:23 < fiatjaf> darosior: is that update_fee on 0.8.2?
10:34 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
11:10 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
11:25 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has joined #c-lightning
12:35 -!- Educob2 [5a4ae098@90.74.224.152] has joined #c-lightning
12:35 < Educob2> There is something I don't understand. The funding tx is a 2of2 script with its address. Why is not possible to add funds to that address to increment channel capacity?
12:36 < zmnscpxj_> Because bitcoin is a UTXO-based system, not an account-based one, and the existing commitment state transactions refer to a specific UTXO
12:37 < zmnscpxj_> if you create a new UTXO with the same 2-of-2 script address, that's something of a big problem --- you need to coordinate a heck of a lot more things
12:37 < zmnscpxj_> what we want to push is some kind of splicing proposal, where the existing 2-of-2 UTXO is spent together with incoming funds
12:37 < zmnscpxj_> to create a new 2-of-2 UTXO
12:38 < zmnscpxj_> do you need more information on the coordination needed?
12:40 < zmnscpxj_> does that clarify your question?
12:41 < fiatjaf> Educob2: https://xn--57h.bigsun.xyz/utxo.html
12:41 < zmnscpxj_> yes, something like that
12:41 < zmnscpxj_> an anddress is nothing more than an unlocking condition for a UTXO, the base layer is run on UTXOs
12:43 < zmnscpxj_> one can consider transactions to be nothing more than the deletion of some UTXOs and the creation of some UTXOs, as a single atomic action
12:44 < Educob2> Yes. It explains details I didn't think of. Thanks.
12:44 < zmnscpxj_> a channel funding is not an address, it is a UTXO
12:45 < zmnscpxj_> is a more concise way to say that
12:45 < Educob2> Maybe a new commitment tx could be created reflecting the new utxo?
12:46 < zmnscpxj_> a UTXO is created by deleting other UTXOs.  Until the new funding tx is confirmed onchain, the owners of those other UTXOs (that would be spent) can try to delete (spend) them in a different tx
12:46 < Educob2> Anyway this just  me thinking out loud as obviously my knowledge is much more limited.
12:46 < Educob2> Ok. I see.
12:46 < zmnscpxj_> which is why I say it requires a good bit of coordination to do so
12:46 < zmnscpxj_> which is the hard part of designing and implementing splicing
12:46 < Educob2> I am sure the current protocol will be heavily improved in the future.
12:47 < zmnscpxj_> yes, we hope
12:47 < zmnscpxj_> the current protocol does not really work well with e.g. RBF-ing of funding txes, for example
12:47 < zmnscpxj_> because doing an RBF changes the txid, which changes the identifier for a UTXO
12:48 < zmnscpxj_> there is a new opening proposal, spearheaded by niftynei, that allows dual-funding, and also some other new abilities
12:48 < zmnscpxj_> including RBF
12:49 < zmnscpxj_> etc etc
12:49 < zmnscpxj_> hopefully when niftynei is online maybe she can help you with that, if  you are curious
12:50 < Educob2> ok. I'll gladly read about it but my knowledge doesn't go that far.
13:34 -!- Kostenko [~Kostenko@83.223.242.55] has quit [Ping timeout: 256 seconds]
13:48 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
13:59 -!- Educob2 [5a4ae098@90.74.224.152] has quit [Remote host closed the connection]
14:03 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
14:03 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
14:09 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has quit [Quit: Sleep mode]
14:51 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning
14:53 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]
14:54 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
15:08 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
15:23 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection]
15:24 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #c-lightning
15:43 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has joined #c-lightning
15:51 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has quit [Quit: Sleep mode]
16:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
16:19 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]
16:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
16:39 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
16:48 -!- Kostenko [~Kostenko@2001:8a0:7289:d400:f981:5ee8:f04c:62d3] has joined #c-lightning
16:49 -!- t0mix [~t0mix@78-141-123-99.dynamic.orange.sk] has quit [Ping timeout: 246 seconds]
16:54 -!- jonatack [~jon@134.19.179.195] has quit [Ping timeout: 246 seconds]
16:56 -!- jonatack [~jon@37.173.38.62] has joined #c-lightning
17:16 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
17:20 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-txhnryyccoeyadae] has left #c-lightning []
17:21 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-txhnryyccoeyadae] has joined #c-lightning
19:17 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
19:19 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning
21:19 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
21:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
21:23 -!- vasild_ is now known as vasild
22:00 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:00 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
23:04 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-txhnryyccoeyadae] has left #c-lightning []
23:04 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-txhnryyccoeyadae] has joined #c-lightning
23:05 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-txhnryyccoeyadae] has left #c-lightning []
23:05 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-txhnryyccoeyadae] has joined #c-lightning
23:14 -!- sword_smith [sword_smit@bitcoinfundamentals.org] has quit [Ping timeout: 240 seconds]
23:24 -!- k3tan [~pi@unaffiliated/k3tan] has quit [Ping timeout: 272 seconds]
23:25 -!- k3tan [~pi@unaffiliated/k3tan] has joined #c-lightning
23:38 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
23:38 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
23:46 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
23:47 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
--- Log closed Thu May 07 00:00:14 2020