--- Log opened Wed May 29 00:00:26 2019
00:16 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
00:25 -!- ccdle12 [~ccdle12@218.189.35.1] has quit [Remote host closed the connection]
00:34 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has joined #lightning-dev
00:36 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
00:55 -!- siom [~siom@165.84.231.26] has joined #lightning-dev
00:59 -!- ccdle12 [~ccdle12@218.189.35.1] has joined #lightning-dev
01:12 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #lightning-dev
01:15 -!- ccdle12 [~ccdle12@218.189.35.1] has quit [Remote host closed the connection]
01:36 -!- trueptolemy [2d0b002b@gateway/web/freenode/ip.45.11.0.43] has joined #lightning-dev
01:37 -!- trueptolemy [2d0b002b@gateway/web/freenode/ip.45.11.0.43] has left #lightning-dev []
01:39 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:40f6:40c9:a5d8:162e] has joined #lightning-dev
01:45 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #lightning-dev
01:53 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:40f6:40c9:a5d8:162e] has quit [Quit: Sleep mode]
02:00 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
02:10 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:9cb1:d590:ddfa:6098] has joined #lightning-dev
02:14 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:9cb1:d590:ddfa:6098] has quit [Client Quit]
02:14 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds]
02:33 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 258 seconds]
02:33 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
02:35 -!- ir0nbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has joined #lightning-dev
02:37 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
02:38 -!- ironbutt [~LiberLive@82.142.166.82] has quit [Ping timeout: 248 seconds]
02:45 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev
02:45 -!- michaelfolkson [~textual@host109-156-0-155.range109-156.btcentralplus.com] has joined #lightning-dev
03:07 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
03:07 -!- michaelfolkson [~textual@host109-156-0-155.range109-156.btcentralplus.com] has quit [Quit: Sleep mode]
03:12 -!- riclas [riclas@148.63.37.111] has joined #lightning-dev
03:12 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
03:35 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
03:38 -!- robzon [~robzon@037008237243.warszawa.vectranet.pl] has quit [Ping timeout: 245 seconds]
03:39 -!- robzon [~robzon@037008237243.warszawa.vectranet.pl] has joined #lightning-dev
04:07 -!- oneark [uid254801@gateway/web/irccloud.com/x-xlprvonrtprgksnd] has quit [Quit: Connection closed for inactivity]
04:36 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
04:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]
05:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
05:17 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 258 seconds]
05:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
05:24 -!- siom [~siom@165.84.231.26] has quit [Ping timeout: 248 seconds]
05:37 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has joined #lightning-dev
05:40 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
05:53 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection]
06:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
06:15 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
06:25 -!- siom [~siom@165.84.231.26] has joined #lightning-dev
06:55 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
07:18 < ariard> To avoid spam by long-held HTLCs or malicious always-fail HTLCs, are there any implementations working on some kind of ban policy on previous processing node, like after X failed htlcs in window time Y refuse new htlcs from it for time Z (or close channel if too severe) ?
07:25 -!- shesek [~shesek@5.22.134.171] has joined #lightning-dev
07:25 -!- shesek [~shesek@5.22.134.171] has quit [Changing host]
07:25 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
07:35 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
07:35 -!- ccdle12 [~ccdle12@109.154.150.203.sta.inet.co.th] has joined #lightning-dev
07:42 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #lightning-dev
07:53 -!- davterra [~tralfaz@178.128.106.205] has quit [Ping timeout: 246 seconds]
08:10 -!- ulrichard [~richi@dzcpe6300borminfo01-e0.static-hfc.datazug.ch] has quit [Remote host closed the connection]
08:21 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
08:35 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has joined #lightning-dev
08:49 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
08:54 < jtimon> rusty: Not sure I understand, you only need that for the neighbour channels, no? I'm assuming the LN node with channels of different chains has full nodes for all chains it supports. I guess that would mean the neighbour  node needs to run the other chain too?
08:54 < jtimon> Let's say we Have A <-BTC-> B <-BTC-> C <-ZZZ-> D <-ZZZ-> E, who needs to run a BTC and a ZZZ full node with that change?
08:54 < jtimon> Ideally only C would need to run both and the rest only one. Does the payer (say, E) need to run the recipient's (say, A) full node?
08:55 < jtimon> sorry for not answering earlier and thanks for the feedback
09:00 < jtimon> if I understand correctly, you're saying that with that change, B and C would aslo need to run the 2 nodes, or all the nodes?
09:06 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving]
09:19 -!- ir0nbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has quit [Remote host closed the connection]
09:36 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has quit [Ping timeout: 246 seconds]
09:41 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has quit [Quit: Sleep mode]
09:45 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has joined #lightning-dev
09:51 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds]
09:56 -!- sfhi [~sfhi@178.255.154.106] has joined #lightning-dev
09:57 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]
09:57 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev
09:59 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has quit [Quit: Sleep mode]
10:01 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has joined #lightning-dev
10:03 -!- davterra [~tralfaz@178.128.106.205] has joined #lightning-dev
10:14 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
10:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]
10:16 -!- enemabandit [~enemaband@16.77.54.77.rev.vodafone.pt] has joined #lightning-dev
10:37 -!- enemabandit [~enemaband@16.77.54.77.rev.vodafone.pt] has quit [Ping timeout: 245 seconds]
10:49 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
11:06 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
11:07 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
11:07 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
11:08 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has quit [Quit: Sleep mode]
11:11 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
11:12 -!- michaelfolkson [~textual@host109-156-0-155.range109-156.btcentralplus.com] has joined #lightning-dev
11:15 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
11:32 -!- michaelfolkson [~textual@host109-156-0-155.range109-156.btcentralplus.com] has quit [Quit: Sleep mode]
11:36 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has joined #lightning-dev
11:37 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has quit [Client Quit]
12:05 -!- lndbot [~lndbot@138.197.213.35] has quit [Remote host closed the connection]
12:05 -!- lndbot [~lndbot@138.197.213.35] has joined #lightning-dev
12:20 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
12:53 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has quit [Read error: Connection reset by peer]
12:56 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has joined #lightning-dev
13:26 -!- rdymac [uid31665@gateway/web/irccloud.com/x-fnvlvakosbtagdqs] has joined #lightning-dev
13:36 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has quit [Quit: ZNC 1.7.1 - https://znc.in]
13:38 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds]
13:40 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has joined #lightning-dev
13:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]
13:56 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
14:15 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has joined #lightning-dev
14:24 -!- sfhi2 [~sfhi@178.255.154.106] has joined #lightning-dev
14:27 -!- sfhi [~sfhi@178.255.154.106] has quit [Ping timeout: 246 seconds]
14:30 -!- sfhi2 [~sfhi@178.255.154.106] has quit [Ping timeout: 272 seconds]
14:48 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
14:49 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
14:54 < bitconner> jtimon: the sender E needs to be aware of block height on BTC so it can construct the CLTV deltas. might be able to use landmark/trampoline routing at C to get around that tho
14:56 < jtimon> in the returning errors section of biolt 4, it says:
14:56 < jtimon> "Note that these error messages are not reliable, as they are not placed on-chain
14:56 < jtimon> due to the possibility of hop failure."
14:56 < jtimon> what does it mean by "on-chain"?
14:57 < jtimon> bitconner: oh, ok, so it's just the sender and C that need to operate both nodes? and well, I guess some of the assumptions for cltv_expiry stuff would be broken
14:59 < bitconner> in general, i like the idea of having a fee matrix rather than a vector. the thing that's unclear is if it's worth the quadratic increase in bandwidth for each node to disseminate fee updates. it also means that the routing state per vertex is quadratic in its degree as opposed to linear
15:00 < jtimon> but beyond that, am I understanding the multi-chain routing problems correctly?
15:01 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has quit [Quit: Sleep mode]
15:02 < jtimon> bitconner: bitconner: regarding that, by assuming a default of 1 for any same-chain channel pair for which the message is not seen (and 0 for different chain pairs), I think we avoid the quadratic increase in bandwidth
15:03 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has joined #lightning-dev
15:03 < jtimon> at least for most cases
15:03 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 258 seconds]
15:03 < bitconner> i think it depends on what era of lightning we're talking about and the tools at hand. but today, yes i think E would need to run BTC and ZZZ, it'd need the BTC-ZZZ exchange rate, and also the relative block emission rates of the two chains (so it can convert CLTV deltas at C). it's also unclear how E would get B's pubkey without also accepting gossip traffic and/or external assistance
15:04 < bitconner> BTC gossip traffic*
15:05 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has quit [Client Quit]
15:05 < jtimon> yeah, I'm assuming E is listening to both BTC and ZZZ gossip traffic, how else could it pay in a node in the BTC gossip network?
15:05 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has joined #lightning-dev
15:05 < bitconner> wdym by 1 for same-chain, 0 for diff-chain?
15:07 < jtimon> for channels i and i+1, today 1 btc spent on c_i gives you 1 btc in c_i+1
15:08 < jtimon> but if c_i is a btc channel and c+1 is a ZZZ channel, you just can't route through them, 1 BTC in c_i gives you 0 ZZZ in c_i+1
15:11 < bitconner> jtimon, i see i think i was mistaken on your proposal. your'e proposal distributes exchange rates rather than fee schedules?
15:12 < jtimon> back to the btc-only example, if you relay the message explicitly, you could allow routing from c_i to c+1 at a different price, for example, charge a 1% fee by setting the price to 0.99, that way, 1 btc from c_i gives you 0.99 btc on c_+1
15:12 < bitconner> > so it's not really a fee, but a price,
15:12 < bitconner> missed that part
15:13 < jtimon> well, it can be used for either fees if they're the same chain or exchange rates (fee included) if they're different chain
15:13 < jtimon> no worries
15:13 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has quit [Quit: Sleep mode]
15:15 < jtimon> the clarification for converting cltv deltas between chains is very useful, somehow I hadn't thought about that yet
15:15 < jtimon> but now that you say it, it seems quite obvious, I guess that's part of what rusty meant too
15:16 < bitconner> in the btc-btc example, this seems very close to the current fee schedule y = mx + b, but with b=0. is there a reason for not having a base fee?
15:16 < jtimon> well, the base fee is currently per channel, so that's orthogonal, no?
15:17 < jtimon> you can have both
15:17 < bitconner> they overlap some, but i think that's why i initially misread the propsoal
15:18 < bitconner> you could have y = r*(mx+b) which is think what you're proposal is suggesting
15:18 < bitconner> when i was initially discussing the fee matrix, i was thinking they'd be merged, and you'd end up relaying y = rm*x + rb similar to the current function
15:19 < jtimon> yeah, I mean, there's one m for each channel and one r for each hop, right?
15:22 < jtimon> mhmm, not sure I follow, if there was no assumed default and a the whole matrix for all channel pairs combinations for a node (noth directions) needed to be relayed, the number of messages would still be quadratic, no?
15:22 < bitconner> if the goal is only for crosschain payments, then yes. what i was imagining is having a pair (rm, rb) for each channel pair. in both same and cross chain cases, it would be useful to have different schedules applied to each channel-pair (but then there's the quadratic blow up)
15:22 < bitconner> yes, i think we're on the same page
15:23 < jtimon> yeah, that's my main goal, if it's useful for same-chain channel pairs, much better
15:24 < bitconner> awesome, i think i have a better understanding of your proposal. i'll take some time to mull it over :)
15:24 < jtimon> I thought of chain_hash:chain_hash prices instead of channel:channel prices but I didn't liked it much
15:25 < jtimon> even allowing both and chain:channel and channel:chain, but that didn't felt like it could work
15:26 -!- siom [~siom@165.84.231.26] has quit [Ping timeout: 268 seconds]
15:26 < jtimon> thanks everyone for the feedback, more welcomed at any time
15:26 < jtimon> the "on-chain" question above is completely unrelated
15:28 < bitconner> yeah i'd think more on if chain:chan chain:chain or chan:chan variants, could see cases where each has pros/cons
15:36 < jtimon> the idea was that you could relay more general things with lower timestamps and immediately overwrite the more specific cases with higher timestamps, you can have fun looking at  https://github.com/lightningnetwork/lightning-rfc/commit/9014bb1f9c42cb581594142ecc39818ad7009a91 if you want, although I I think that approach is broken
15:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
15:57 -!- harding [~harding@li1258-130.members.linode.com] has quit [Ping timeout: 258 seconds]
15:57 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
16:01 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 248 seconds]
16:02 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 248 seconds]
16:23 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has joined #lightning-dev
16:24 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
16:24 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
16:25 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has quit [Client Quit]
16:30 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #lightning-dev
16:50 -!- harding [~harding@li1258-130.members.linode.com] has joined #lightning-dev
16:51 < jtimon> I mean, or at least that approach is borken in the form proposed in that draft
16:54 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
17:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
17:13 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
17:14 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
17:16 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
17:17 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
17:17 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
17:26 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]
17:32 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has joined #lightning-dev
17:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
17:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
17:38 -!- ccdle12 [~ccdle12@109.154.150.203.sta.inet.co.th] has quit [Remote host closed the connection]
17:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
17:41 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
17:41 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has joined #lightning-dev
17:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
17:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
17:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
17:49 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 245 seconds]
17:50 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has quit [Quit: gone]
17:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
17:52 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
17:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
17:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
18:00 -!- riclas [riclas@148.63.37.111] has quit [Ping timeout: 268 seconds]
18:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
18:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
18:01 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 246 seconds]
18:01 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has joined #lightning-dev
18:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
18:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
18:03 < rusty> bitconner: ping?
18:05 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 257 seconds]
18:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 258 seconds]
18:09 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
18:13 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has joined #lightning-dev
18:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
18:18 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
18:18 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 248 seconds]
18:22 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has joined #lightning-dev
18:28 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev
18:35 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has quit [Quit: Sleep mode]
18:38 -!- ccdle12 [~ccdle12@109.154.150.203.sta.inet.co.th] has joined #lightning-dev
18:39 < bitconner> rusty: pong!
18:40 < rusty> bitconner: hey!  Sorry for flaking yesterday, was busy IRL until it was waaay too late in your TZ.
18:41 < rusty> bitconner: let me review the notes and see what we still needed to coinflip on?
18:43 -!- ccdle12 [~ccdle12@109.154.150.203.sta.inet.co.th] has quit [Ping timeout: 245 seconds]
18:44 < rusty> bitconner: I think remaining issues were: 1. type 1 byte or varint. 2. what species of varint to use. 3. exact requirements of canonicalization to use.  I *think* we had agreement to leave odd/even rule, or revisit that too?
18:44 < bitconner> rusty: no worries! had plenty of other things to work on, today is better for me anyway
18:44 < bitconner> yes that sounds right, tho i think even/odd still had some discussion imo
18:45 < bitconner> i think we more or less agreed on using a varint (1), because nesting sounds awful
18:46 < rusty> bitconner: OK.
18:46 < rusty> So, #2. varint Bitcoin style avoid reinventing the wheel, but it's overkill for every imaginable scenario.
18:47 < rusty> Even if we were to assign types > 64k for experimentation, it's still overkill.
18:47 < bitconner> one concern was that we lose allocating everything above 64k for other purprose, couldn't we just say all types greater than 0x8000 are for that purpose?
18:48 < rusty> bitconner: yeah, I think people can self-assign in a 15 bit space with in practice as few collisions as in a 64-bit space.
18:48 < rusty> I think of unofficial port numbers as my metric here.
18:49 < bitconner> haha ill by that :)
18:49 < rusty> (TCP/UDP ports).  In practice, self-assigning works.
18:49 < bitconner> buy
18:49 < rusty> So, definitely overkill, so we just have the are-we-reinventing-wheel q.  Which is harder, TBH.
18:49 < bitconner> cool, so now applications can listen on onion "ports"
18:49 < bitconner> tor v4 coming soon lol
18:50 < bitconner> it's like putting a wheel designed for a tank on a bicycle imo
18:50 < bitconner> just delete some spokes, same thing more efficient for the use case
18:51 < rusty> Well, it's like putting a wheel 1% off the correct size (we lose 253 and 254 as usable values).
18:51 < bitconner> if we're already doing that, why not just only reserve 0xff
18:51 -!- arij [uid225068@gateway/web/irccloud.com/x-ntntodzijfqterkj] has quit [Quit: Connection closed for inactivity]
18:51 < rusty> I worry that we'll eventually increase inter-peer message size above 64k, so I wonder if TLV length > 64k becomes a thing at that point.
18:52 < rusty> bitconner: because existing code wins?
18:52 < bitconner> we probably shouldn't have started building the lightning network then :)
18:52 < bitconner> it's like 10 lines
18:52 < bitconner> increasing message size in the future, yes i'm sympathetic to that argument
18:53 < bitconner> though bolt01 will have to be rewritten entirely
18:53 < bitconner> since the header only supports 65kb
18:53 < rusty> bitconner: unless we come up with some fragmentation hack, yeah.
18:54 < rusty> I certainly wouldn't invent bitcoin varints for this, but I'm synpathetic since it exists.  If there's even a chance we'll want it, I think that sways me?
18:54 < rusty> brb
18:57 < bitconner> agree that using compact size for lengths makes more sense than it does for types
18:59 < rusty> yeah, and the uniformity arg carries type along too.
18:59 < rusty> OK, let's discuss canonicalization: how much do we want?
18:59 < bitconner> arg?
18:59 < rusty> argument, sorry.
18:59 < bitconner> ah, gotcha
19:00 < rusty> I think the reader should insist on minimal compactint on receipt.  I'm not sure they should check ordering of TLV?
19:00 < bitconner> agree on minimal encoding of varint
19:00 < bitconner> i think the two sortings currently are (type) or (type, length, value)
19:01 < rusty> But if they do, we need to decide up-front on whether duplicate-typed entries are allowed (and what lexical order means).  If they don't, we can punt that decision and simply say "writers MUST NOT" until/if we find a case where we want duplicate typed entries in a TLV.
19:02 < bitconner> needing to inspect the encoded types to sort or validate is a big pain point imo
19:03 < bitconner> i think in most cases, it should be clear when something is a vector or not?
19:03 < bitconner> e.g. the arrays returned in extended_gossip_queeries
19:04 < bitconner> are you imagining that would be encoded in one record or N?
19:04 < rusty> bitconner: well, if it's clearly a vector we can't use duplicate TLVs, since order would not be maintained (assuming we want to insist on a canonical ordering, which I think we do).
19:05 < bitconner> how would duplicate records be interpretted if not a vector?
19:05 < rusty> bitconner: I can't think of any TLVs today where we want duplicates.  But I look at bolt11 where duplicates for some fields made perfect sense.  On the Other Other hand(?) they only make sense when writer can control ordering, so....
19:05 < rusty> bitconner: OK, consider if bolt11 were TLV?
19:05 < rusty> (as a design thought experiment, not a proposal!)
19:06 < bitconner> sure
19:06 < rusty> We hve the 'f' field for fallback addresses, which logically there can be more than one.  Creating some internal vector representation is harder than just allowing multiple 'f' types in the TLV.
19:07 < rusty> BUT they're ordered (you're supposed to use the first one you understand), so actually the multiple f fields WOULD NOT WORK.
19:07 < rusty> (sicne order would be actually dictated by our general canonicalization rules).
19:08 < rusty> OTOH, route hints ('r') are unordered, and they're also variable length, so duplicate TLVs for them maps really fine.
19:08 < bitconner> i'm not clear on why it's more difficult to create an internval vector representation, we already do this when writing varbytes?
19:09 < bitconner> i see what you mean on how the ordering would affect things like preference, though you could skirt that by appending an integer preference at the beginning maybe?
19:09 < bitconner> prepending*
19:10 < rusty> Oh, we can, sure.  But obv if we didn't need to it'd win.  This thought experiment has shown me we'd want to do this anyway, so I think you're right: use internal vector representation, ban duplicate types, simplify ordering definition to type-only.
19:11 < bitconner> there's also a bandwidth advantage to encoding everything in one tlv, since we only need 1 T+L instead of N (which adds up quickly for numbers greater than 253)
19:11 < bitconner> awesome, yeah i found enforcing canonical ordering to be quite simple when only concerning types :)
19:11 < rusty> So, should we insist that reader check canonicalization?  Advantages: writers will get this correct or GTFO.  Disadvantages: a little more code.
19:12 < bitconner> when only comparing types, all that's needed is a single if statement to check that the new type is higher than the last
19:12 < rusty> Old-school networking thinking was "be strict in what you send, liberal in what you accept".  But that turned out to make upgrades harder since people hack on crap until it "works", so strict readers help the ecosystem.
19:13 < bitconner> if it's not done during decoding, when should it be checked?
19:13 < rusty> bitconner: you wouldn't check it at all?  You'd just parse whatever.
19:14 < rusty> bitconner: we have asymmetric requirements like this in the spec already in some places, where we insist writers do something, even though readers don't care.  Usually it's because we want to use the thing-it-must-not-do for future upgrades.
19:14 < rusty> eg. zeroing padding.
19:14 < bitconner> so then in the case of gossip messages, if i forward to someone who is enforcing canonical ordering, who's at fault?
19:14 < bitconner> the neighboring peer who didn't verify, or the creater of the messge?
19:14 < rusty> bitconner: good point!
19:15 < bitconner> should i continue to try and validate the signature on a broken message just to figure out who sent it?
19:15 < rusty> OK readers MUST validate ordering; I'm convinced.
19:15 < bitconner> cool :)
19:16 < rusty> bitconner: OK, is there anything else?  I have to get back to being a toxic bitcoiner on Twitter! :)
19:16 < bitconner> lolol
19:17 < bitconner> i think there was some more discussion on even/odd
19:17 < bitconner> are there other cases you imagine where we'd want to partition the gossip network other than for upgrading signatures?
19:17 < bitconner> to me that seems like a once in a blue moon event that could be enforced in a different way
19:18 < bitconner> but it cuts down the number of usable small types, instead of resorting to feature bit negotation
19:19 < bitconner> couldn't that equally be done using schnorr_sigs_required?
19:22 < rusty> Yeah, we'll end up with a new scheme for payment keys vs payment hashes, too, whcih will be a similar network split.
19:23 < rusty> I mean, you'll start by implementing backwards compat, but eventually clients will start assuming it.  Someone starting an ancient client will get " I can't understand TLV field 88!" and be able to google.
19:24 < rusty> Also, funding txs which use taproot will be similar for gossip changes AFAICT.
19:24 < bitconner> in both cases tho, that seems like something that should be done when sending init, rather than happening after receiving some message 10 minutes later
19:25 < bitconner> i request 10k gossip message from you do all the processing and starting writing to the wire only to have the peer realize they don't know what you're talking about
19:25 < rusty> bitconner: sure, but bugs happen.  Obviously, you should *never* receive an unknown even msg today.  But better to abort than continue and go bad.
19:26 < rusty> OTOH some messages really are optional, so you don't want "die if you get anything unexpected!".
19:27 < rusty> Consider some application-level TLV onion thingy.  Is it optional?  Depends on what they're doing, I think.
19:27 < bitconner> i can see the argument applying to onion payloads, since the sender and receiver may not be directly connected
19:27 < bitconner> and thus, don't have the ability to do negotiation up front
19:29 < bitconner> why does the even/odd rule have to be a detail of the low-level parsing requirements?
19:30 < bitconner> to me that seems like a restriction that can be applied after parsing
19:33 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
19:37 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
19:37 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
19:46 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 258 seconds]
20:00 < rusty> bitconner: We do odd/even for packet parsing between peers too, where there's similarly a "unknown even should never happen" case.
20:04 < rusty> bitconner: Do you want me to write up, or do you want to?
20:05 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
20:06 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
20:08 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has joined #lightning-dev
20:10 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 246 seconds]
20:14 -!- moonfunjohn [55cb2f09@gateway/web/freenode/ip.85.203.47.9] has joined #lightning-dev
20:16 < bitconner> rusty: that's fair
20:17 < bitconner> i'm happy to to amend 607 with the results of our discussions today :)
20:17 < rusty> bitconner: OTOH, it's not saved us from any disasters yet.  But it still helps me sleep better at night...
20:18 < rusty> bitconner: cool, thanks!  Always nice to work with you, and I think the result is something we can be pretty happy with.  I'll buy you a beer in Berlin!
20:21 < bitconner> likewise! thank you for the helpful discussion, am glad to be finally wrapping this design phase up and moving on to the more fun 1.1 items :)
20:22 < bitconner> beer sounds great! seems we'll have a lot of those going around with all this spec progress hehe
20:27 -!- ccdle12 [~ccdle12@109.154.150.203.sta.inet.co.th] has joined #lightning-dev
20:28 < rusty> As always, it's been slower than we'd all like/hope, but we're kind of building an entire new industry here, so maybe it's not surprising.
20:29 -!- moonfunjohn [55cb2f09@gateway/web/freenode/ip.85.203.47.9] has quit [Quit: Page closed]
20:30 -!- Kostenko [~Kostenko@dsl-154-81.bl26.telepac.pt] has quit [Ping timeout: 268 seconds]
20:30 -!- mikerah [~mikerah@2607:fea8:875f:f8d0::2] has quit [Ping timeout: 250 seconds]
20:32 -!- ccdle12 [~ccdle12@109.154.150.203.sta.inet.co.th] has quit [Ping timeout: 272 seconds]
20:33 -!- moonfunjohn [~moonfunjo@85.203.47.9] has joined #lightning-dev
20:36 -!- Kostenko [~Kostenko@176.78.154.81] has joined #lightning-dev
20:37 -!- moonfunj_ [~moonfunjo@218.20.11.146] has joined #lightning-dev
20:41 -!- moonfunjohn [~moonfunjo@85.203.47.9] has quit [Ping timeout: 272 seconds]
20:52 < bitconner> indeed, and most of it is upholding the measure-twice-cut-once philosophy, which is what we want long term
21:05 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has joined #lightning-dev
21:16 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has quit [Quit: Sleep mode]
21:19 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
21:29 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 272 seconds]
21:31 -!- ccdle12 [~ccdle12@109.154.150.203.sta.inet.co.th] has joined #lightning-dev
21:32 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has joined #lightning-dev
21:32 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:bc15:cfe4:c593:6429] has quit [Client Quit]
22:22 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 268 seconds]
22:32 -!- rachelfish [~rachel@unaffiliated/itsrachelfish] has quit [Ping timeout: 246 seconds]
22:34 -!- rachelfish [~rachel@unaffiliated/itsrachelfish] has joined #lightning-dev
22:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 272 seconds]
22:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
22:41 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
22:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
22:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 244 seconds]
22:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
23:20 -!- moonfunjohn [~moonfunjo@85.203.47.184] has joined #lightning-dev
23:22 -!- moonfunj_ [~moonfunjo@218.20.11.146] has quit [Ping timeout: 248 seconds]
23:30 -!- moonfunj_ [~moonfunjo@218.20.11.146] has joined #lightning-dev
23:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
23:33 -!- moonfunjohn [~moonfunjo@85.203.47.184] has quit [Ping timeout: 244 seconds]
23:52 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
23:57 -!- laptop500 [~laptop@92.118.153.193] has joined #lightning-dev
--- Log closed Thu May 30 00:00:26 2019