--- Log opened Mon Nov 23 00:00:24 2020
00:17 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Quit: Pavlenex]
00:19 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]
00:22 -!- sword_smith [sword_smit@bitcoinfundamentals.org] has joined #lightning-dev
00:34 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #lightning-dev
00:45 -!- laptop [~laptop@ppp-3-32.leed-a-1.dynamic.dsl.as9105.com] has joined #lightning-dev
01:10 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer]
01:22 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Quit: Pavlenex]
01:32 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
01:34 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Client Quit]
01:34 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
01:52 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Quit: __gotcha]
02:07 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev
02:10 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
02:10 < lnd-bot> [lightning-rfc] q-src opened pull request #819: Add specs for offline payments (master...master) https://github.com/lightningnetwork/lightning-rfc/pull/819
02:10 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
02:27 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #lightning-dev
02:27 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Client Quit]
02:34 -!- martindale [ericfabric@gateway/shell/matrix.org/x-hqughkzmhrxeyjgl] has quit [Quit: Bridge terminating on SIGTERM]
02:37 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Quit: leaving]
02:43 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-uzbkbocahofvpvuf] has joined #lightning-dev
02:50 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
02:51 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev
02:55 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #lightning-dev
02:55 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Client Quit]
02:56 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
02:57 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #lightning-dev
03:03 -!- martindale [ericfabric@gateway/shell/matrix.org/x-ogaatqoiqypshlwd] has joined #lightning-dev
03:10 -!- reallll is now known as belcher
03:34 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds]
03:44 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
03:48 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
03:56 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Quit: Pavlenex]
04:44 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
04:56 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #lightning-dev
05:11 -!- doubleqp [~doubleqp@188.166.79.22] has quit [Changing host]
05:11 -!- doubleqp [~doubleqp@unaffiliated/doubleqp] has joined #lightning-dev
05:12 -!- doubleqp [~doubleqp@unaffiliated/doubleqp] has quit [Quit: bye bye]
05:12 -!- doubleqp [~doubleqp@188.166.79.22] has joined #lightning-dev
05:12 -!- doubleqp [~doubleqp@188.166.79.22] has quit [Changing host]
05:12 -!- doubleqp [~doubleqp@unaffiliated/doubleqp] has joined #lightning-dev
05:13 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Quit: No Ping reply in 180 seconds.]
05:14 -!- kloinka [~quassel@2406:3400:21b:ef70:838e:d3aa:5c71:eec3] has joined #lightning-dev
05:18 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:6c06:c056:20b8:f8ee:6530] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
05:24 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:6c06:c056:20b8:f8ee:6530] has joined #lightning-dev
05:33 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
05:35 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
05:39 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
06:38 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #lightning-dev
06:52 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:6c06:c056:20b8:f8ee:6530] has quit [Ping timeout: 264 seconds]
06:52 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:6c06:c056:20b8:f8ee:6530] has joined #lightning-dev
07:15 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
07:15 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
07:16 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
07:22 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-zwrouasmjczcftxr] has joined #lightning-dev
07:29 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev
07:55 -!- tiker[m] [tikerfunky@gateway/shell/matrix.org/x-zysnkhplmgnflikf] has joined #lightning-dev
07:59 -!- Bugz [~pi@035-134-224-053.res.spectrum.com] has quit [Read error: Connection reset by peer]
08:00 -!- Bugz [~pi@035-134-224-053.res.spectrum.com] has joined #lightning-dev
08:05 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:6c06:c056:20b8:f8ee:6530] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
08:24 -!- kexkey [~kexkey@static-198-54-132-134.cust.tzulo.com] has joined #lightning-dev
08:44 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #lightning-dev
09:32 -!- proofofkeags [~proofofke@174-16-212-53.hlrn.qwest.net] has quit [Ping timeout: 240 seconds]
09:41 -!- eugene-ff [~eugene_ff@2604:2000:1383:472b:35d0:a660:e9f3:26b3] has quit [Remote host closed the connection]
09:41 -!- eugene-ff [~eugene_ff@2604:2000:1383:472b:d5dd:106a:4f01:4bca] has joined #lightning-dev
09:41 -!- joostjgr [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev
09:45 -!- eugene-ff [~eugene_ff@2604:2000:1383:472b:d5dd:106a:4f01:4bca] has quit [Ping timeout: 260 seconds]
09:47 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds]
09:53 -!- eugene-ff [~eugene_ff@2604:2000:1383:472b:40e6:cab7:86db:332e] has joined #lightning-dev
09:58 -!- eugene-ff [~eugene_ff@2604:2000:1383:472b:40e6:cab7:86db:332e] has quit [Ping timeout: 264 seconds]
10:03 -!- proofofkeags [~proofofke@174-16-212-53.hlrn.qwest.net] has joined #lightning-dev
10:07 -!- vasild_ is now known as vasild
10:22 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
10:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
10:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
10:35 -!- t-bast [~t-bast@5.50.145.86] has joined #lightning-dev
10:36 -!- eugene-ff [~eugene_ff@cpe-67-247-37-186.nyc.res.rr.com] has joined #lightning-dev
10:54 < niftynei> the agenda for today's spec meeting is up at https://github.com/lightningnetwork/lightning-rfc/issues/816
10:55 < niftynei> courtesy of t-bast
10:55 < t-bast> good morning niftynei!
10:55 < niftynei> hello hello!
10:55 < t-bast> congrats on the c-lightning release
10:56 < niftynei> thanks! i'm glad it's out :)
10:57 < t-bast> can you detail the PSBT part that only works with bitcoin 0.20.1?
10:57 < t-bast> I've been implementing PSBT for eclair as well, curious about tha
11:01 -!- joost [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev
11:02 < cdecker> Morning all ^^
11:02  * t-bast waves at cdecker
11:02 -!- joost is now known as Guest72185
11:02 < t-bast> joost is trying to go anonymous on us
11:03 < joostjgr> Haha, no that is my second IRC client
11:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
11:03 < cdecker> I think it might not be working too well
11:03 < niftynei> sure, briefly we add both the non-witness-utxo and the witness-utxo to all inputs
11:03 < cdecker> :-)
11:03 < niftynei> which fails validation/parsing on bitcoind prior to v0.20.1
11:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
11:04 < t-bast> niftynei: ok interesting, I hesitated to do that as well! I think I'll do it for eclair too and force bitcoin >= 0.20.1
11:04 < niftynei> right. it's 'only' a problem if you try to send the PSBT through bitcoind though ;)
11:05 < cdecker> Since we expect most plugins and users to send through c-lightning that limitation should not be a big issue 👍
11:06 < niftynei> who's chairing today?
11:06 < t-bast> Indeed, and even going through bitcoind it only goes through your own bitcoind, so you might as well update it to 0.20.1
11:06 < niftynei> i hear v0.21.0 is the new hotness anyway
11:06 < t-bast> but 0.21.0 doesn't yet support non-wallet utxo, so lightning PSBTs are not very usable :(
11:07 < t-bast> I've opened https://github.com/bitcoin/bitcoin/issues/19481 to track that
11:07 < t-bast> I can chair tonight if you want
11:07 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
11:08 < niftynei> go for it t-bast!
11:08 < cdecker> Don't have any objections ^^
11:08 < t-bast> #startmeeting
11:08 < rusty> Ack!
11:09 < t-bast> hey rusty!
11:09 < t-bast> The bot is still down, but I'll copy-paste my logs in the github issue
11:09 < t-bast> #topic Previous meeting leftovers
11:09 < t-bast> ariard told me he can't attend tonight, so we'll skip the action items that were assigned to him
11:10 -!- jonatack [~jon@134.19.179.179] has quit [Quit: jonatack]
11:10 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/810
11:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
11:10 < t-bast> This PR was pending a second ACK
11:10 < t-bast> IIUC roasbeef seemed positive about it, but haven't heard back. roasbeef are you there? :)
11:11 < BlueMatt> ACK'd
11:11 < t-bast> great, that does a second ACK then, shall we merge?
11:12 < cdecker> I count 3 acks (assuming you support your own proposal) :-)
11:12 < t-bast> Perfect let's go
11:12 < t-bast> #action Merge 810
11:12 < t-bast> Let
11:13 < t-bast> Let's start today's agenda now
11:13 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/816
11:13  * BlueMatt notes that this *could* be a little looser while not causing force-closes, but I also am not sure its possible to implement practically without just sending in the same order, so whatever.
11:13 < t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/815
11:13 < t-bast> Look likes the spec 1.0 was wrong about the tx size calculations...woops :)
11:13 <+roasbeef> yeh 810 lgtm
11:14 < BlueMatt> I didnt double-check the numbers - is this due to the low-s-sigs-can-only-be-72-bytes thing?
11:14 < t-bast> thanks roasbeef
11:14 < BlueMatt> oh, no, its also cltv_expiry, ok, nvm
11:14 < t-bast> BlueMatt: I don't think so, it's just that we counted an expiry to use 3 bytes whereas it actually uses 4
11:14 < BlueMatt> wellllll...do we *want* to consider that signatures can never be 73 bytes in these numbers?
11:14 < rusty> Meh, it'
11:14 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
11:14 < lnd-bot> [lightning-rfc] t-bast merged pull request #810: Clarify relative order of some messages after reestablish (master...issue-794) https://github.com/lightningnetwork/lightning-rfc/pull/810
11:14 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
11:14 < rusty> s a made-up number anyway.  But yeah, embarrassing.
11:15 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
11:15 < lnd-bot> [lightning-rfc] t-bast pushed 1 commit to master: https://github.com/lightningnetwork/lightning-rfc/compare/dcf6b0f359c2...920e51986d65
11:15 < lnd-bot> lightning-rfc/master 920e519 Bastien Teinturier: Clarify relative order of some messages after reestablish (#810)
11:15 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
11:15 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
11:15 < lnd-bot> [lightning-rfc] t-bast deleted 0 commit to issue-794: https://github.com/lightningnetwork/lightning-rfc/compare/fc07aabd93ff...000000000000
11:15 < cdecker> Just a sanity question: it's not like this will end up causing an incompatibility, is it?
11:15 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
11:15 < rusty> (I did those original numbers, too :(
11:15 < BlueMatt> cdecker: no, we all use the hard-coded numbers there, changing them should not change any implementation, afaiu
11:16 < lndbot> <johanth> yeah, it was just a few inconsitensies I noticed when I wrote some test assertions for the final txs we create
11:16 < lndbot> <johanth> probably not a big deal, but it leads to some head scratching
11:16 < lndbot> <johanth> as long as we all use the same constants
11:17 < t-bast> We need to keep using the previous constants, but it's worth fixing the spec like johanth did IMO
11:18 -!- jonatack [~jon@88.124.242.136] has joined #lightning-dev
11:18 < lndbot> <johanth> especially this one I have no idea how was calculated before: https://github.com/lightningnetwork/lightning-rfc/pull/815/commits/a9e064d04f313032d38407f75c3f1c53e32ad562#diff-6bed824879b760d329ec379b16a1d0e78ffba034fdfa13b95cf0480e09fa7c4bL919
11:18 < rusty> t-bast: agreed.  Ack, and I like the wording too.
11:18 < t-bast> ACK, I think it helps to clarify the spec if someone re-does the calculation and doesn't understand the results :D
11:19 < cdecker> ack ^^
11:19 < t-bast> johanth: *magic*
11:19 < lndbot> <johanth> t-bast: yeah, that is mostly it. I wasted a few hours scratching my head here
11:20 < t-bast> the CI doesn't like your `reeeeally` though, can you fix this johanth?
11:20 < t-bast> and then I believe we can merge
11:20 < lndbot> <johanth> sure.
11:20 < t-bast> #action fix CI then merge
11:20 < lndbot> <johanth> someone should double check m calculations tho heh
11:20 < lndbot> <johanth> my*
11:21 < t-bast> johanth: I did check them, not with code but by hand and I agreed with you, will do another pass to be sure
11:21 < t-bast> #topic Public-key based routing
11:21 < lndbot> <johanth> awesome
11:21 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/814
11:21 < t-bast> joostjgr floor is yours ;)
11:21 < joostjgr> Thank you. What do people generally think about the proposal?
11:22 < rusty> "the math said 702 and 705, but after intense negotiation with world leaders we settled on 703 and 706"
11:22 <+roasbeef> main Q for me is what wallet authors and other services think of it 
11:22 <+roasbeef> it's an old idea, made  bit slimmer now by the tlv onion payloads 
11:22 < joostjgr> Yes, def wouldn't claim it is a new idea
11:22 <+roasbeef> it adds a bit of guess n check forwarding wise re the proper policy, but I think a few other impls already do something like that since you can pick which channel to use anyway 
11:23 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 256 seconds]
11:23 <+roasbeef> IIRC pheonix uses a form of this as well t-bast ? 
11:23 <+roasbeef> to like make new identifiers for clients that don't have chans on the fly? 
11:23 < t-bast> I think it's simple enough that implementing relay for it is trivial, and then once routing nodes have upgrade wallet can leverage it. The main Q for me is whether wallet will want that or blinded paths (given that they'll need to wait for at least some routing nodes to update before they can release it in wallets)
11:24 < t-bast> Yes Phoenix uses a variant with a fake short_channel_id, we could experiment with it easily becuase our node is always the next-to-last hop
11:24 < joostjgr> I think you don't need to wait for routing nodes to upgrade. Receivers can see the feature bits of their peers and decide based on that whether to omit the channel id
11:24 <+roasbeef> upgrade paths seems very diff tho right? this is an e2e update, not super up to date on blnded paths but iiuc it'll take _all nodes_ in the path to upgrade so its an internal update 
11:24 -!- jonatack [~jon@134.19.179.163] has joined #lightning-dev
11:25 < rusty> Yeah, I went for the same form in onion_message: you can use scid or key.  But that's because in theory you don't need a channel, and it can certainly change.
11:25 < t-bast> yes that's true, upgrade path is definitely lighter than blinded paths
11:25 <+roasbeef> also this doesn't affeect what gets back to the sender, and I think blinded routes ends up giving them less info on failures? 
11:25 < joostjgr> (ofc if no routing nodes ever upgrade, receivers never see the right feature bit and the invoice will stay as is)
11:25 <+roasbeef> the code impact for this is also pretty small impl wise I wager 
11:25 <+roasbeef> and can be phased in with an optional bit in the invoice, etc 
11:25 <+roasbeef> i think the invoice bit might be missing from the PR last I checked 
11:26 < cdecker> Technically any unique alias for a peer can be used to indicate the direction to forward, scid just happened to be shortest one we already had. But I don't think we should be adding aliasing schemes willy nilly
11:26 < t-bast> I agree, this is very light so I'd consider adding the relay code to eclair
11:26 < rusty> I'm missing how this helps private routes?  Or are you assuming a single private channel?
11:26 <+roasbeef> cdecker: can just treat the 33 bytes as w/e identifier 
11:26 < joostjgr> I tried my hand at a rough PoC impl in lnd: https://github.com/lightningnetwork/lnd/pull/4758
11:26 <+roasbeef> rusty: I think it's more about not giving away on chain data in invoices (that's how I see it at least) 
11:26 < t-bast> rusty: it's just that it doesn't point to an on-chain tx, so you're not revealing the amount you put in
11:27 < cdecker> Sure, we could use 33 bytes as a very verbose alias that is guaranteed to be globally unique, whereas blinded paths gives us a naming scheme that doesn't require global uniqueness, just local to the routing node
11:28 < rusty> If you put an all-zero scid in the bolt11 routehint, how do you handle old readers who will put it in the onion?
11:28 <+roasbeef> they seem distinct tho, and also have very diff deployment timelines 
11:28 <+roasbeef> rusty: a feature bit in the invoice? 
11:28 < rusty> roasbeef: you can only break old readers, though.
11:28 <+roasbeef> may be something that needs to be required from the get go 
11:28 < rusty> So this will take along time to deploy.
11:28 < niftynei> this seems like a dumb question, but this change is on the hop-level, right? so instead of specifying which channel to forward the payment to, you'd specify the node id
11:28 <+roasbeef> it's still an e2e update tho 
11:28 < t-bast> you should set the feature bit as required in that case I think
11:28 <+roasbeef> niftynei: yeh
11:29 < t-bast> old readers would then fail when reading the invoice
11:29 <+roasbeef> so up to the receiver if they really want this protection or not 
11:29 < t-bast> I'm a bit afraid receivers would not activate it because they can't know whether senders will support it...
11:30 < t-bast> Unless it puts a bit of pressure on wallet maintainers to add the feature
11:30 < rusty> Ick, it's kind of bad that it's useless until everyone upgrades :(  I'd really rather move to blinded routehints everywhere, which offers better privacy.
11:30 <+roasbeef> blinded route hints would have the same issues, and reqwuires even more nodes to update to have it be utilized 
11:31 < niftynei> this feels vaguely close to rendezvous routing, in that you're giving the onion unwrapper some leeway in *how* to get to the destination, no?
11:31 < joostjgr> An alternative is to just use the pubkey truncated to 8 bytes as the channel id in the hop payload
11:31 < t-bast> definitely, but at least we're a pain to wallet developers only once, we don't ask them to implement pubkey_routing and then route blinding :)
11:31 <+roasbeef> this is one of those things also that ppl can just go ahead and deploy, if they want to use another value in the tlv name space 
11:31 <+roasbeef> niftynei: kinda, but there's no like route-within-a-route, nodes cna already pick amongst channels to use if they have multiple channels to the destination, this kinda just makes that explicit in a sense 
11:31 < t-bast> niftynei: it's only a one-hop thing, so it doesn't have the privacy that rendezvous offers (which hides multiple hops)
11:31 < niftynei> i guess the scid was always a hint anyway, also lol
11:32 < joostjgr> Routing nodes would try to re-interpret the scid as a truncated pubkey if it doesn't match a real channel. That doesn't have the problem with old readers
11:32 < rusty> joostjgr: oh, that's kinda neat.  Skip the first byte though, because x-only.
11:32 < cdecker> Honestly I'm not seeing the point, there is very little upside, and has a rather annoying backward compatibility story
11:33 < rusty> cdecker: I think it's a good idea, I just think route blinding is better.
11:33 < cdecker> Route blinding may have the same issues, but at least it brings new features to the table
11:33 < cdecker> Agreed
11:33 < joostjgr> Perhaps that can be an upgrade path too. Don't omit or zero out the scid from the invoice, but just put the truncated key there. But for implementations, also implement true pubkey routing to get rid of the scid eventually in the invoice
11:33 <+roasbeef> they have verrry diff scopes fwiw, just look at the relative descriptions of the additions 
11:33 < BlueMatt> ugh, once we start to add hacks to shove the pubkey in the scid the "its easy and clean to just add and move forward" argument starts to fall apart
11:33 <+roasbeef> size of the*
11:33 < niftynei> (rusty's already living in an x-only future ;))
11:34 < rusty> "I have seen the future and it is 32 bytes long!"
11:34 <+roasbeef> but as mentioned above, ppl can start to do this already since it's an e2e upgrade, even intermediate nodes can start to use a global bit to say they like it for w/e reason aprt from end destinations 
11:34 < t-bast> rusty: xD
11:35 < niftynei> i'm not understanding exactly what this pubkey move gets you
11:35 < BlueMatt> roasbeef: "people can deploy this already if they know the feature set of all the relevant nodes" doesnt seem like a strong argument for *why* to do something.
11:35 < joostjgr> Would be nice if that global feature bit signals support for pubkey routing via a new tlv field AND via truncated pubkey in the scid
11:35 < niftynei> like, you still need to know the connection graph, as channels have to exist between the nodes
11:35 <+roasbeef> BlueMatt: that isn't a why, it's a how, contrasting the deploymen to of alternatives 
11:35 < joostjgr> niftynei: you don't need to reveal your channel points in invoices anymore
11:35 < joostjgr> for private chans
11:36 < cdecker> Sorry but the truncated node_id in the scid is a clear nack from me
11:36 <+roasbeef> it's like how ppl just started using stuff like keysend, since only the endpoints needed to update 
11:36 < t-bast> On the one hand, it's simple enough to implement, but upgrade will still be slow. And even though it's simple, it's time that could be spent implementing route blinding: the sooner route blinding is included in releases, the sooner the clock starts ticking before enough nodes support it to use it E2E
11:36 < BlueMatt> what cdecker said. please dear god no.
11:36 <+roasbeef> yeh just full on pubkey imo 
11:36 < t-bast> joostjgr: have you had many users asking for this?
11:37 < joostjgr> I've had likes lol
11:37 < BlueMatt> roasbeef: yes, I get that, and people can do whatever experiements they want, but "people could" is not an answer to "this has a lot of the issues of just doing route blinding, and only half the features, so lets just spend our precious little time on the first, not the second"
11:37 <+roasbeef> t-bast: that's a false dilemma imo, they both have widely diff scopes
11:37 < niftynei> but how does a node route to that pubkey if the private channels arent in the route graph?
11:37 < t-bast> joostjgr: what we've mostly had is users asking for more privacy by hiding both scid *and* node_id, which is why we worked on route blinding
11:37 <+roasbeef> niftynei: routing hints? 
11:37 < niftynei> i feel like i'm missing something here.
11:37 < niftynei> ... but isnt' that exposing your channel points in invoices??
11:38 <+roasbeef> routing hint w/ pubkey instead of scid? 
11:38 < t-bast> roasbeef: it's still time spent somewhere...I don't know how much users want this, it feels like it's not enough for users who asked us for more privacy and too much for those who didn't ask
11:38 < niftynei> so you know who they're connected to but not the value of any of those connections/channels etc
11:38 < rusty> t-bast: I *definitely* want this for onion_messages, since the whole idea of doxing yourself for a refund is anathema obv.
11:39 <+roasbeef> niftynei: yeh I think that's the idea, since rn I can grab an invoice from a service and learn info their users for wallets like phoenix/breez 
11:39 < t-bast> rusty: by "this" you mean route blinding or pubkey routing?
11:39 < joostjgr> t-bast: ofc hiding also the node_id is nicer, but given the choice between hidden channel points or no change, I'd expect them to still see benefit in just hiding channel points? Implementation effort is a factor as well
11:39 < rusty> t-bast: route blinding
11:40 < t-bast> roasbeef: you don't learn anything for Phoenix users, invoices don't expose short_channel_ids...
11:40 <+roasbeef> cuz y'all use something custom? 
11:40 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has quit [Ping timeout: 256 seconds]
11:41 <+roasbeef> what do you put in the scid field? nothing? 
11:41 < t-bast> rusty: ok, agreed, I meant that we didn't get user requests for something that achieves what pubkey routing does. But we did get user requests for the properties route blinding brings.
11:41 < cdecker> Any alias for the destination in the scid will do, as long as the forwarding node can interpret it correctly
11:41 < t-bast> roasbeef: a fake scid, that only allows our node to map
11:42 <+roasbeef> as I commented on the PR itself, this is one of those things that really just needs either side to opt into, it can just be a document describing how to do it, and ppl can pick it up or not, since it doesn't require internal updates, just as how keysend was progressilvey rolled out, ppl started to use it, more impls started to add it, etc 
11:42 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has joined #lightning-dev
11:42 < BlueMatt> roasbeef: it sounds like probably only lnd has any interest, so maybe it should just be in a docs folder in lnd somewhere?
11:44 < cdecker> roasbeef: just like keysend is still not documented, and we had to reverse engineer it? And now we are getting some reports that cross-implementation keysends aren't working anymore...
11:44 <+roasbeef> more so trying to make a broader point that only things that modify internal routing needs a high level of coordinating across impls 
11:44 < t-bast> roasbeef: it could reasonably be in a `proposals` or `lnip` folder, but there are still a few things that need to be merged in the spec, namely the TLV field used in the onion and the feature bits, right?
11:44 <+roasbeef> just like how pheonix uses scid place holders and none of us really needed to care 
11:45 <+roasbeef> cdecker: curious what the issues are since it's so impl, the spec is a sentence more or less (put the preimage in this place)
11:45 < t-bast> otherwise we risk incompatibilities on the TLV types and feature bits (clashes with other proposals)
11:45 <+roasbeef> so simpl* 
11:45 < rusty> roasbeef: MPP + keysend should Just Work, right?
11:45 < cdecker> Yeah, iirc it was something else, but still made me re-read the keysend impl to make sure
11:46 <+roasbeef> rusty: as in AMP? or something else 
11:46 < niftynei> the scid placeholder isn't an exact analog, as it's just repurposing an existing spec field...
11:46 <+roasbeef> but backing up I don't feel super strongly about this, just trying to make a meta point about the level of coordination required for certain features/extensions 
11:46 < cdecker> As in "include the preimage in the TLV payload" 
11:46 < cdecker> Whatever the name for that one was
11:46 < rusty> roasbeef: yeah, split payments.  Did you do some combination of the preimages in that case, or do they all contain the preimage?
11:46 < cdecker> Ah wait, no MPP as in "just reuse the same hash"
11:47 <+roasbeef> oh solution for that is AMP rusty, we have a path to phase out keysend in lnd as is since multi-path keysend is AMP 
11:47 <+roasbeef> but ok should we move to other things...?
11:47 < rusty> roasbeef: I think that's where the incompatibility is, we try to MPP using the same preimage...
11:48 <+roasbeef> rusty: ah yeh it's only a single path thing purposefully, to have ppl use AMP by necessity 
11:48 < cdecker> Ok, so that might be our issue, need to disable mpp for keysend
11:48 < cdecker> (or we keep it on, and just let lnd fail to receive...)
11:48 < t-bast> I think there's something coming from this discussion that would be interesting to settle: do we want to move forward with a proposals/lnip format for some features in the spec? As I pointed out above, if we do that, we still need to merge in the main spec body TLV types and feature bits
11:48 < rusty> cdecker: or implement AMP?  Shouldn't be that hard, assuming we can derive spec from code?
11:49 <+roasbeef> yeh they're mutually exclusive for us (keysend and mpp), and we're actually moving to make mpp rewuired for _all_ payments in our next release (0.12 drops "soon") 
11:49 < t-bast> TBH if keysend is for donations, it's surprising that it can't work with a single-part...
11:49 <+roasbeef> t-bast: imo yeh, and I think it would give ppl some clarity to working on higher level wwallet type things, many of which just ended up making their own spec repos 
11:49 < t-bast> (small donations)
11:50 <+roasbeef> it _only_ works w/ single part 
11:50 < cdecker> Mhz, I hate having multiple things that achieve the same (see route blinding and pubkey based routing), so also implementing AMP (with XORed preimage) is ugh
11:50 <+roasbeef> cdecker: what else does what AMP does? or referring to something else? 
11:50 < rusty> cdecker: if iut's just xor, that's easy to impl.
11:50  * niftynei needs a glossary of lightning routing shorthands
11:50 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
11:51 < cdecker> Yes, the current MPP implementation reusing the same hash works perfectly well, and with schnorr we get decorrelation
11:51 <+roasbeef> yeh ppl hear "additive secret sharing" but it's just xor, you can do a lot w.r.t how you derive the shares on the sender side, but receiver just xors till they can start to pull and eveyrthing is there 
11:51 <+roasbeef> works well, but re-uses the same payment hash so the route cna be correlated
11:51 < BlueMatt> roasbeef: what exactly do you mean "require mpp for all payments" - do you mean require the ability to send outbound mpp for outbound payments, or require the mpp fields in single-path payments?
11:51 <+roasbeef> "until schnorr" is a vague time frame 
11:51 < cdecker> Keysend + MPP is more composable than AMP (which requires the sender to generate the preimage if I'm not mistaken)
11:51 <+roasbeef> BlueMatt: we require the payment addr field for single-path payments 
11:52 <+roasbeef> cdecker: keysend still requires the sender to generate tho? 
11:52 <+roasbeef> idk how you can combine something that's spontaenous w/ something that isn't 
11:52 < rusty> Yeah, IMHO if you're doing keysend you might as well xor the preimages.
11:52 < cdecker> Exactly, that's what I mean by composability. Keysend generates secret on sender (invoice generation) while MPP takes care of transport
11:52 <+roasbeef> so new invoices lnd generates will rquire the payment addr, but if there'sr an old unexpired invoice with the optional bit set, then we'll still accept that (is the way we've impl'd it) 
11:53 <+roasbeef> but should we get to another topic in the remaining time? 
11:53 < cdecker> Afaik there is no AMP variant that works without the sender generating the preimag
11:53 < BlueMatt> roasbeef: ah, ok. interesting. I presume mostly to get payment_secrets?
11:53 <+roasbeef> cdecker: yes, that's how it works, the sender genrates the preimage, if you can do dlog stuff the receiver can include a point and the sender uses that to force them to also reveal a secret 
11:53 <+roasbeef> BlueMatt: yeh the payment addr, which would've partially thwarted that CVE we had, since the party couldn't probe any of our payments w/ that value 
11:54 <+roasbeef> or w/e it's called lol
11:54 < BlueMatt> :+1:
11:54 <+roasbeef> it also makes ppl doing "zero value invoice stuff" more secure 
11:54 < cdecker> Ok, seems nobody cares about having multiple transport mechanisms, so I'll shut up
11:54 <+roasbeef> we're also gonna require static remote key as well for funding 
11:55 <+roasbeef> LTU in the last bit? 
11:55 <+roasbeef> lnd has a PR for #804
11:55 <+roasbeef> but seems now CL will start to end an actual error if the reply isn't well formed rusty ? 
11:56 < t-bast> Let's talk a bit about long-term udpates indeed? And we'll talk about channel_range_queries next time?
11:56 <+roasbeef> that caused us to mark a channel as borked iirc since it wasn't clear to lnd why the error was sent (since we don't have proper error codes) 
11:56 <+roasbeef> t-bast: sure
11:56 <+roasbeef> just wanted to drop that msg lol
11:57 < t-bast> #topic Offers
11:57 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/798
11:57 < t-bast> rusty, maybe you want to tell us what reviewers should focus on for a first pass on the PR?
11:57 < rusty> roasbeef: we fixed latest release to allow that overlap.  before that, yeah, we would have complained.
11:57 < t-bast> since it's 1600 lines long, we definitely won't be able to grasp all of it during this meeting :)
11:57 < rusty> t-bast: OK, yeah, I have an implementation (as you can tell by all the spec churn!)
11:58 < rusty> Well, there are really two modes.  Normal is offer -> invoice_request -> invoice.  
11:59 < rusty> A "send_invoice" offer is offer -> invoice.  This is for ATMs and refunds, where you really are offering to send money, not recv it.
11:59 < rusty> Feedback welcome esp on stuff like the format (it's bech32 without the csum, of the same formatting we use on the wire)
11:59  * bitconner slips in the room, sits down quitely in closest seat
12:00 < rusty> Skipping the csum is actually kinda nasty, since std bech32 APIs don't give you that.  Not sure if I should simply shrug and put it back?
12:00 < rusty> (I removed it because there's speculation on changing csum calc anyway)
12:00 <+roasbeef> why not just drop bech32 all together? 
12:00 <+roasbeef> since it basically does nothing w/ such a large input string
12:00 <+roasbeef> just use base32 encoding or something if you want the same look and feel, and can add a manual prefix if you want 
12:01 < rusty> roasbeef: yeah, I just use the encoding, since we already support it.
12:01 <+roasbeef> ah ok so just the char set? tho the whole 5 bit word thing is annoying, and iirc a few impls had a bug related to it? 
12:01 < rusty> roasbeef: zbase32 just adds YA standard.
12:01 < bitconner> roasbeef: are you suggesting prefix||base32(tlv(data), sig)?
12:01 <+roasbeef> ehh I guess, but it's just extra complexity 
12:01 <+roasbeef> bitconner: yeh
12:01 < rusty> roasbeef: yeah, but that's true of any encoding unless we do hex :)
12:02 < rusty> So, yeah, I took the low road.
12:02 <+roasbeef> idk base32 vanilla is waaay smaller code wise than bech32 itself (like even just skipping the "re-wording" step adds a lot), but hey I guess it's already there 
12:02 < rusty> It's TLV, which is good and bad.  bad because there are some compulsory fields which now are in the spec rather than the decoder logic.
12:02 < BlueMatt> if we're gonna do bech32, just include the checksum. its worthelss but extra few chars is basically free.
12:02 <+roasbeef> just fees like over kill 
12:02 < rusty> BlueMatt: sure, once they decide what csum to use!
12:02 <+roasbeef> and we get no benefits from it other than "we're using it too!" 
12:03 < lndbot> <johanth> must note (as for invoices) that is not “real” bech32 tho
12:03 < rusty> Anyway, the other tech choice is 32-byte pubkeys.  I implemented with 33 byte and ecdsa, and the flip to schnorr and x-only took about a day.  Pretty trivial.
12:03 < lndbot> <johanth> which can be confusing, since a bech32 lib won’t parse it
12:03 < BlueMatt> rusty: right lol. tbh this seems like a "person who writes the spec choses, everyone else shuts up cause it doesnt matter and is otherwise shed-painting" kinda issue :p
12:04 < t-bast> BlueMatt: true dat :)
12:04 < rusty> Yeah, so the rest is pretty simple.  There's blinded paths in there, ofc.
12:04 < rusty> The main complexity is the recurrence stuff, but it's really a killer feature IMHO.
12:05 <+roasbeef> so in the past, ppl didnt like HORNET since they felt it allowed arbitrary data transfer or w/e if not limited or metered, but doesn't this allow the same thing with the onion messages? 
12:06 <+roasbeef> IRC over LN? ;) 
12:06 < rusty> roasbeef: yeah, but this is at least super cheap (1 way, no reply).
12:06 < t-bast> roasbeef: I think the difference is even with recurrence, it will likely be one message per day / week / month, so hornet woulnd't bring anything since session_keys would need to be reestablished every time (it would be slower than Sphinx)
12:06 < BlueMatt> roasbeef: having a spec to do useful things doesnt imply that people *should* run their vpn over it, and it provides useful things on its own, so, :shrug:
12:07 < t-bast> People can mis-use it of course though
12:07 <+roasbeef> BlueMatt: what i'm saying is HORNET gives us all that blinded paths+offers does plus more, but before ppl didn't like the messaging aspect, but offers rolls something new for that purpose 
12:07 <+roasbeef> t-bast: yeh that's what I mean 
12:07 <+roasbeef> also fwiw re recurrence, with AMP that can be implemtned in a way that doesn't require a manual invoice fetch (over the network itself?) each time they end user wants to pay, it's more of a cron job at the end user after it has the initial static inovice 
12:07 < t-bast> But offers optimizes for the normal path (the way it's intended to be used). Using HORNET there would be less efficient (and more code and complexity to implement)
12:08 <+roasbeef> unclear if more code from my PoV 
12:08 < BlueMatt> right, sure, I mean I dont care about HORNET vs rusty's work or whatever, just noting that the reason this is more of a "yep, sounds good" is that it actually provides all the useful features that people wanted to see, instead of just saying "cool, look messaging protocol, we can add features to use it later"
12:08 <+roasbeef> since it builds on sphinx 
12:08 < rusty> Implementing onion_message is pretty simple.  Was about 200 lines.
12:08 < t-bast> roasbeef: blinded path re-uses the existing sphinx scheme without changing anything, it was < 100 loc in eclair
12:09 < rusty> HORNET creates (one-way) circuits, which are not useful.
12:09 <+roasbeef> nah they're bi-directional 
12:09 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 264 seconds]
12:09 < lndbot> <johanth> t-bast: isnt anything < 100 loc in scala? :P
12:09 <+roasbeef> and require no stroage at the intermediaries to process 
12:10 < rusty> roasbeef: no, you gotta create them in a loop?
12:10 <+roasbeef> unlike how we all need to maintain these ciruits 
12:10 < rusty> roasbeef: sure, onion_message doesn't have circuits either.
12:10 <+roasbeef> a single round trip sets up the forward and backwards path, the backwards path can even be a diff route entirely 
12:10 < t-bast> The way I understood it is I thought you were pusing for HORNET for something like LSAT and high-frequency tiny payments, but apart from that I'm not sure why
12:10 < t-bast> johanth: damn, I'm exposed :)
12:10 <+roasbeef> mhmm but also we could use this to remove the circuit requiremetns for all reg HTLC forwarding as well 
12:11 <+roasbeef> t-bast: I mean if you want to use it to fetch an invoice from someone, you can do that as well 
12:11 < rusty> roasbeef: yeah, except mpp means you set up circuits and throw them away again.  Why?
12:11 < rusty> We just don't seem to have the setup-once-use-many pattern which fits HORNET.
12:12 <+roasbeef> "use many" is as many as the expiry of the forwarding packets allow, you're right in that there's the extra RTT across the entire route to set it up the first time 
12:12 < bitconner> well if you end up requesting invoices frequently, that pattern would fit
12:12 < BlueMatt> but only if its frequently enough that nodes on the path would come and go?
12:12 < t-bast> depends how frequently, how long are circuits supposed to live in HORNET? clearly less than a day, right?
12:12 < BlueMatt> (ie, per-hour, not per-month?)
12:12 < niftynei> iiuc HORNET would be useful for lots of payments between two parties in a short timeframe
12:12 <+roasbeef> but also the burden of the time isn't felt on the intermediate nodes since they don't need to write circuit state for it, the packets carry all the info 
12:12 < bitconner> they're routing nodes, we can expect pretty high uptime
12:13 < niftynei> so for a HFT application etc
12:13 <+roasbeef> t-bast: depends really, it can be 1 minute if you want 
12:13 <+roasbeef> if we're doing it now, would maybe use blockheight as expiry in the packet or something 
12:13 < niftynei> (HFT-> high freq trading)
12:13 < t-bast> roasbeef: yeah but it's the higher threshold that's interesting there: what's the maximum duration before you need to reset them for security>
12:14 < rusty> bitconner: I expect you may try several paths to get the invoice successfully, and maybe several more to make the payment.  Reuse of a single path would be < 1.
12:14 <+roasbeef> also note you can make a HORNET session to just request invoice or w/e and end up using some other path entirely for the actual payment trasnfer 
12:14 < t-bast> niftynei: that was my understanding as well
12:14 <+roasbeef> can think of it as control+payment sessions 
12:14 < bitconner> rusty: isn't it the case that you may need to request several path prefixes for rendezvous style payments?
12:14 < rusty> roasbeef: yeah, but you have liveness proof if you get a successful msg though, which makes it a good candidate for payment.
12:15 < bitconner> s/prefixes/sufficex
12:15 <+roasbeef> mhmm just pointing out the flexibility in usage 
12:15 < lndbot> <johanth> paving the way for “stuckless payment” types also
12:15 <+roasbeef> in that you can use nodes that've updated to requiest invoices or w/e, while still using the greater network for normal payment transfer 
12:15 < rusty> bitconner: if they want that, they'd have multiple paths in the invoice they send.
12:16 < bitconner> and that's all going to fit in one onion?
12:16 <+roasbeef> old email on the topic which maybe will provide ppl w/ more context: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001524.html 
12:16 < rusty> bitconner: ... 64k?  Sure.
12:16 < bitconner> ah okay, was thinking onion payload as the limit
12:16 <+roasbeef> other stuff I was reminded about from that email: can be used for a pyemtn level ACK (somethign we takced abou tin the past), and also to let nodes rotate onion keys which adds forward secrecy 
12:17 < niftynei> it really seems like it's hard to determine what's the most efficient here without a solid usecase in mind
12:17 < t-bast> What's unclear to me is how costly is the circuit setup in HORNET. I'd like to see the latency it adds for a wallet user that launches his wallet to make a payment, compared to the offers way. My assumptions was that it would add to much latency for the UX to be reasonable (by extrapolating from the HORNET paper figures), but I may be wrong
12:17 < rusty> Since chains of htlcs need state, implementing HORNET for it seems like a waste.
12:18 <+roasbeef> t-bast: good Q, I think processing is negliible (and actually faster since it' sjust symmetric crypto) so you could just estimate based on RTT guess and rroute length 
12:18 < niftynei> wallet user != HFT exchange rails
12:18 < rusty> Implementing HORNET for messages makes sense, but then they're usually single-use (and we don't really want to optimize streaming) so why bother?
12:18 <+roasbeef> rusty: lots of other benefits like faster forwarding in general, forawrd secrecy, payment level ack, etc, etc 
12:18 < rusty> roasbeef: none of those are hornet, dude!
12:19 <+roasbeef> what's the issue with the sessions having a low lifetime? 
12:19 <+roasbeef> ofc they are? it enables all those things 
12:19 < rusty> roasbeef: no.  Payment acks can be done today.
12:19 <+roasbeef> see that email above, timely now that it's 2 years old 
12:19 <+roasbeef> lots of things can be done today, this is one thing that gives us several things 
12:20 <+roasbeef> what would you use for an ack today? a reverse HTLC or something? 
12:20 < rusty> "A notable change is that each node no longer needs to maintain per-circuit state as we do now with Sphinx"  Err, yeah, HTLCs need state.
12:20 < t-bast> TBH I think the only way we'll settle this discussion about hornet vs no hornet is by having a PoC. If LL wants to spend time on it, I volonteer to do an interoperability Eclair PoC as well and we'll see what it brings.
12:20 < rusty> roasbeef: every node already has to remember the incoming<->outgoing HTLC circuit.  It's trivial to route msgs back based on that.,
12:20 <+roasbeef> yeh HTLCs need state, but that's a diff layer in the stack, that's purely talking about the state needed to forward an htlc and it's errro/settle 
12:21 <+roasbeef> I think yuo're getting caught up on the state thing rusty
12:21 < rusty> roasbeef: yeah, I am.  We have state, we can't get rid of it.  Let's not add something which has that as its entire purpose.
12:21 <+roasbeef> there're like 5 other things it adds beyond that, the state things is correct in that it's about session state, but correc tyou need htlc state to process them on-chain 
12:21 <+roasbeef> that's not the entire purpose, that's one aspect it adds amongst several 
12:21 <+roasbeef> consider it a bonus lol 
12:22 <+roasbeef> the point there is that if ppl want to use it for fetching invoices or w/e, it does't add any additional state burden to the node processing the session 
12:22 < rusty> roasbeef: sure, but since the messaging tends to be one-shot anyway, we don't even need hornet.
12:22 < bitconner> which meaens it's probably more DOS resistant
12:23 < bitconner> since the sender maintains all circuit state
12:23 < rusty> So we have two things: an HTLC which is ungodly heavy and requires state.  And messages which are oneshot.
12:23 <+roasbeef> it can be used one shot, or few shots, it's just more flexible 
12:24 <+roasbeef> g2g tho
12:24  * BlueMatt still doesnt see a lot of reason to bother optimizing for >1 shot - too few cases that are multi-messages-within-reasonable-timeframe
12:24 < BlueMatt> roasbeef, before you go quick q: a) can I presume that folks would be open to a post-covid (lets say fall-ish. 2021) physical spec meeting and b) that no one has yet started organizing one and c) that rusty would only threaten to not, but would still come if its in ny?
12:24 < rusty> BlueMatt: oh, I like NY.
12:24 < t-bast> BlueMatt: Yay!!
12:24 <+roasbeef> dunno what the future holds, but sounds like a good idea, has been too long since we've all met up 
12:24 < bitconner> DOS thing imo is pretty important as there's no natural ratelimiting for messages like there is for sats: commitment slots, fees, capital, etc
12:25 < BlueMatt> rusty: ah, I see you *do* love the inside of small metal tubes :p!
12:25 < bitconner> BlueMatt: absolutely!
12:26 < rusty> bitconner: yeah, I tried to make onion_messages as light as possible, but we still may end up with some anti-spam pay2play or simple ratelimiting.
12:27 < bitconner> t-bast: agree some PoC's would probably be useful here. also depends on if others would be willing to block offers on those numbers or if we'd just proceed with onion msgs anyway..
12:27 < bitconner> (assuming they can be completed in a reasonable timeframe)
12:27 < rusty> bitconner: TBF, if we get HORNET for ~free, I'd not block it for use in onion_message.  I'll have to look at it.
12:28 < rusty> (I don't have a good use for HORNET, but maybe someone will...)
12:28 < bitconner> not sure how we get HORNET by only using sphinx tho..
12:28 < BlueMatt> yea, dos is maybe the only super-compelling reason, aside from a bunch of pie-in-the-sky kinda thinking.
12:28 < rusty> bitconner: yeah, it's a bit more complex.  We need to re-add somef ields we removed.
12:28 < t-bast> I'm mostly afraid of complexity + latency when setting up circuits (especially on mobile wallets), but that's what PoCs are for, we'll see when we have code running
12:29 < rusty> BlueMatt: doesnt' win on DoS, sicne onion_message is also stateless.
12:29 < BlueMatt> ah, ok, I mis-parsed your earlier comment, rusty.
12:29 < rusty> (Def beats (ab)using HTLCs for msg transport though)
12:29 < BlueMatt> dear god yes.
12:30 < bitconner> t-bast: i think the setup latency isn't as bad as one might expect, definitely faster than payments bc you don't need roundtrips to sign states, but a concrete impl will confirm/deny
12:30 < t-bast> Great thanks everyone, let's end it for today! Great discussions.
12:30 < t-bast> #endmeeting
12:31 < t-bast> bitconner: I volunteer to experiment with it, will take a bit of time of course, but we'll see what we get
12:31  * BlueMatt will look into thinking about meeting. obviously nothing to propose until its looked into more and we all have clarify of travel safety/ability. no promises.
12:31 < t-bast> Thanks BlueMatt, it would be great to have such an event!
12:31 < joostjgr> Preventing abuse of htlcs. It is something that I hope will get some attention before moving on to extending the protocol with new functionality
12:32 < BlueMatt> since no one screamed, I'll think about new york, if it doesnt work out I'll try to hand it off to someone else. It was ~20 people last time, right?
12:33  * BlueMatt -> gone.
12:33 < t-bast> joostjgr: agreed, my proposal is still there, I hope people will have some time to look at it 
12:35 < joostjgr> yes, the proposal is definitely interesting. i didn't believe it was possible to fix the problem in a trust-less way until I saw that
12:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds]
12:35 < t-bast> Let's see where it goes with more eyes on it! To others in the channel, it's here:https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md#bidirectional-upfront-payment
12:36 < t-bast> Gotta go, have a good week all
12:36 -!- t-bast [~t-bast@5.50.145.86] has quit [Quit: Leaving]
12:38 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Ping timeout: 256 seconds]
12:38 -!- joostjgr [~joostjgr@81-207-149-246.fixed.kpn.net] has quit [Quit: Leaving]
13:00 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
13:04 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds]
13:25 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
13:27 -!- molz_ [~mol@unaffiliated/molly] has joined #lightning-dev
13:29 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
13:29 -!- laptop_ [~laptop@ppp-2-169.leed-a-1.dynamic.dsl.as9105.com] has joined #lightning-dev
13:32 -!- laptop [~laptop@ppp-3-32.leed-a-1.dynamic.dsl.as9105.com] has quit [Ping timeout: 264 seconds]
13:36 -!- nobody123 [~nobody123@ipservice-092-211-047-157.092.211.pools.vodafone-ip.de] has quit [Remote host closed the connection]
13:37 -!- nobody123 [~nobody123@ipservice-092-211-047-157.092.211.pools.vodafone-ip.de] has joined #lightning-dev
13:44 -!- nobody123 [~nobody123@ipservice-092-211-047-157.092.211.pools.vodafone-ip.de] has quit [Ping timeout: 264 seconds]
14:22 -!- Nebraskka [~Nebraskka@51.83.249.56] has quit [Remote host closed the connection]
14:23 -!- Nebraskka [~Nebraskka@51.83.249.56] has joined #lightning-dev
14:58 <+roasbeef> so just realized an issue w.r.t the way we advertise/interpret connection level feature bits 
14:59 <+roasbeef> static key is a connection level bit, we want to start to require it for lnd going forward, since it's better channel safety for end users 
14:59 <+roasbeef> but once a user upgrades to teh latest version of lnd, as written, they'll unable to connect to _existing_ peers they had non static key channels with (tho imo they should've closed those out long ago for the new ones) 
15:00 <+roasbeef> so to make things more graceful, seems you always need to set "the lowest common denominator" w.r.t channels/connection bits 
15:20 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
15:21 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev
15:42 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-zwrouasmjczcftxr] has quit [Quit: Connection closed for inactivity]
15:50 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds]
15:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
16:04 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds]
16:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:06 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
16:12 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
16:15 -!- proofofkeags_ [~proofofke@174-16-212-53.hlrn.qwest.net] has joined #lightning-dev
16:18 -!- proofofkeags [~proofofke@174-16-212-53.hlrn.qwest.net] has quit [Ping timeout: 264 seconds]
16:19 -!- eugene-ff [~eugene_ff@cpe-67-247-37-186.nyc.res.rr.com] has quit [Remote host closed the connection]
16:26 -!- eugene-ff [~eugene_ff@2604:2000:1383:472b:180:7d25:74a3:1753] has joined #lightning-dev
16:30 -!- eugene-ff [~eugene_ff@2604:2000:1383:472b:180:7d25:74a3:1753] has quit [Ping timeout: 264 seconds]
16:40 -!- proofofkeags__ [~proofofke@174-16-212-53.hlrn.qwest.net] has joined #lightning-dev
16:43 -!- proofofkeags_ [~proofofke@174-16-212-53.hlrn.qwest.net] has quit [Ping timeout: 260 seconds]
16:43 -!- laptop_ [~laptop@ppp-2-169.leed-a-1.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds]
16:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
16:46 -!- proofofkeags_ [~proofofke@174-16-212-53.hlrn.qwest.net] has joined #lightning-dev
16:46 -!- proofofkeags__ [~proofofke@174-16-212-53.hlrn.qwest.net] has quit [Remote host closed the connection]
16:48 -!- proofofkeags__ [~proofofke@174-16-212-53.hlrn.qwest.net] has joined #lightning-dev
16:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
16:50 -!- proofofkeags_ [~proofofke@174-16-212-53.hlrn.qwest.net] has quit [Ping timeout: 240 seconds]
16:54 -!- proofofkeags_ [~proofofke@174-16-212-53.hlrn.qwest.net] has joined #lightning-dev
16:56 -!- proofofkeags__ [~proofofke@174-16-212-53.hlrn.qwest.net] has quit [Ping timeout: 240 seconds]
17:02 -!- da39a3ee5e6b4b0d [~da39a3ee5@171.5.161.165] has joined #lightning-dev
17:10 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]
17:14 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds]
17:18 -!- marcinja [~marcinja@2604:a880:400:d1::89a:e001] has quit [Read error: Connection reset by peer]
17:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
17:35 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
17:38 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
17:42 -!- nobody123 [~nobody123@ipservice-092-211-047-157.092.211.pools.vodafone-ip.de] has joined #lightning-dev
17:46 -!- nobody123 [~nobody123@ipservice-092-211-047-157.092.211.pools.vodafone-ip.de] has quit [Ping timeout: 240 seconds]
17:54 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
18:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
18:05 -!- nobody123 [~nobody123@ipservice-092-211-047-157.092.211.pools.vodafone-ip.de] has joined #lightning-dev
18:08 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #lightning-dev
18:11 -!- nobody123 [~nobody123@ipservice-092-211-047-157.092.211.pools.vodafone-ip.de] has quit [Ping timeout: 264 seconds]
18:18 -!- proofofkeags_ [~proofofke@174-16-212-53.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
19:26 -!- da39a3ee5e6b4b0d [~da39a3ee5@171.5.161.165] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
19:30 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
19:30 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds]
19:54 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev
19:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds]
19:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
20:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
22:15 -!- shesek [~shesek@164.90.217.137] has joined #lightning-dev
22:15 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
22:15 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
22:17 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #lightning-dev
22:20 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds]
22:26 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
22:27 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Quit: Pavlenex]
22:28 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #lightning-dev
22:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
22:29 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Ping timeout: 264 seconds]
23:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
23:17 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds]
23:42 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-yvkrhcmnpcotzlkv] has joined #lightning-dev
23:52 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th] has joined #lightning-dev
23:59 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]
--- Log closed Tue Nov 24 00:00:25 2020