--- Log opened Mon Jul 06 00:00:11 2020
00:02 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
00:02 -!- laptop [~laptop@85-195-244-64.fiber7.init7.net] has joined #lightning-dev
00:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
00:09 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
00:12 -!- marcoagner [~user@81.193.76.62] has joined #lightning-dev
00:27 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
00:29 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Read error: Connection reset by peer]
00:34 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds]
00:36 -!- rdymac [uid31665@gateway/web/irccloud.com/x-tjowiiiwbfbkkkol] has quit [Quit: Connection closed for inactivity]
00:38 -!- slivera [~slivera@103.231.88.26] has joined #lightning-dev
00:45 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
00:56 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev
00:59 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
01:05 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has quit [Remote host closed the connection]
01:05 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined #lightning-dev
01:15 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:21 -!- rdymac [uid31665@gateway/web/irccloud.com/x-uhaxmxkgaipvqnwp] has joined #lightning-dev
01:37 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev
01:42 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Ping timeout: 272 seconds]
02:05 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
02:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds]
02:09 -!- lukedashjr is now known as luke-jr
02:23 -!- t-bast [~t-bast@2a01:e34:efde:97d0:81ef:f391:31b8:fe49] has joined #lightning-dev
02:28 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 240 seconds]
02:38 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #lightning-dev
02:38 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]
02:38 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev
02:41 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex]
03:18 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
03:18 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
03:52 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev
03:53 -!- slivera [~slivera@103.231.88.26] has quit [Remote host closed the connection]
03:55 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 258 seconds]
04:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
04:18 -!- laptop [~laptop@85-195-244-64.fiber7.init7.net] has quit [Quit: Leaving]
04:30 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
04:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
04:34 -!- vasild_ is now known as vasild
04:51 -!- sr_gi [~sr_gi@static-144-88-225-77.ipcom.comunitel.net] has joined #lightning-dev
05:16 -!- Relis [~Relis@148.252.129.179] has joined #lightning-dev
05:39 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev
05:42 -!- Relis [~Relis@148.252.129.179] has quit [Quit: This computer has gone to sleep]
05:43 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Ping timeout: 246 seconds]
05:43 -!- Relis [~Relis@148.252.129.179] has joined #lightning-dev
06:33 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
06:46 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
06:46 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
07:00 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev
07:16 -!- Pavlenex [~Thunderbi@178.220.60.83] has joined #lightning-dev
07:18 -!- Pavlenex [~Thunderbi@178.220.60.83] has quit [Client Quit]
07:27 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 246 seconds]
07:40 -!- dr_orlovsky [~dr-orlovs@adsl-62-167-101-63.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
07:52 -!- fearbeag [~seanicide@clwdon2201w-lp140-02-142-112-161-69.dsl.bell.ca] has joined #lightning-dev
07:52 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Ping timeout: 240 seconds]
08:08 -!- dr-orlovsky [~dr-orlovs@adsl-62-167-101-63.adslplus.ch] has joined #lightning-dev
08:28 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
08:31 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 246 seconds]
08:32 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
08:48 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 272 seconds]
08:50 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
08:50 -!- marcoagner [~user@81.193.76.62] has quit [Ping timeout: 258 seconds]
08:56 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds]
09:08 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
09:26 -!- marcoagner [~user@81.193.76.62] has joined #lightning-dev
09:54 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
09:59 -!- fearbeag [~seanicide@clwdon2201w-lp140-02-142-112-161-69.dsl.bell.ca] has quit [Ping timeout: 256 seconds]
10:08 -!- IPGlider [~IPGlider@45.76.34.219] has quit [Ping timeout: 272 seconds]
10:10 -!- IPGlider [~IPGlider@45.76.34.219] has joined #lightning-dev
10:20 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 272 seconds]
10:23 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
10:30 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
10:43 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 264 seconds]
10:44 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
10:56 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev
12:25 -!- sr_gi [~sr_gi@static-144-88-225-77.ipcom.comunitel.net] has quit [Quit: Leaving...]
12:29 -!- Pavlenex [~Thunderbi@185.245.85.251] has joined #lightning-dev
12:39 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
12:39 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
12:44 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 240 seconds]
12:57 -!- gleb [~gleb@159.224.16.138] has quit [Ping timeout: 265 seconds]
12:57 < t-bast> Good afternoon everyone
12:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
12:58 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev
12:59 < rusty> Hello everyone!
13:00 < t-bast> Good morning rusty!
13:00 < cdecker> Good evening everyong ^^
13:00 < ja> congrats on the lnprototest release
13:00 < sstone> Hi everyone!
13:00 < ariard> hello
13:00 < rusty> ja: thanks!  Now with Anchor Outputs(TM)!
13:01 < t-bast> rusty: for anchor outputs, are you going to be using bitcoin core's wallet or does c-lightning have its own wallet implementation?
13:02 < t-bast> like tight integration with green?
13:02 < rusty> I estimate I should have anchor outputs for c-lightning ready for interop tests by end of week, FWIW.
13:02 < rusty> t-bast: we have our own wallet, because bitcoind's was way too hard to use :(
13:03 < t-bast> rusty: damn, I'll be playing with `bumpfee` this week
13:04 < rusty> (I think every lightning implementation tries to avoid writing YA bitcoin wallet, then discovers they have to)...  Yeah, the initial implementation just discards the anchor outputs :)  We will get fancy with fee bumping in future releases...
13:04 < t-bast> We're trying hard to use bitcoind/electrum and for now we're okay-ish, I hope we can keep doing that!
13:04 <+roasbeef> yeh own wallet is the way to go imo, luckily we started off with btcwallet already existing 
13:04 < t-bast> ariard: what do rust-lightning do?
13:04 < ariard> How do you provision bumping utxos ? Substract it from the funding_txo ?
13:05 <+roasbeef> few options, but you can also do it in stages too
13:05 < ariard> t-bast: I do have a new interface UtxoPool to plug on top of an already existent wallet
13:06 <+roasbeef> like just leave the fee as is, then to the proviosning afterwards, but diff for y'all tho since we already have stuff deployed so wanted to get it out sooner 
13:06 < t-bast> ariard: ok so you'll have something that should plug into bitcoind's RPC for example?
13:06 <+roasbeef> but you can eithe rallocate a utxo up front, or just have a pool for it, we have a central utxo sweeper, so it handles all that 
13:06 < t-bast> BTW all, what about starting with a jitsi call to make progress on anchors/pinning and then do the rest of the meeting on IRC?
13:06 <+roasbeef> the ML also exists ;) 
13:07 < ariard> yeah you can reallocate based on closing, but ideally you want to allocate upfront by security on some % of channel value
13:07 < ariard> like your bumping utxo is "fractional reserve" of your channel value
13:08 < ariard> t-bast: in theory yes, it's just a dumb interface
13:09 <+roasbeef> but as I said above, this doesn't need to block your greater anchor impl 
13:09 <+roasbeef> given you can keep things as is, then only later do the low-ball + cpfp thing 
13:09 <+roasbeef> leave as is, meaning a faster confirmation target 
13:09 < ariard> agree, it's a different layer that tx-format
13:09 < t-bast> yeah I think the pinning attacks are a good example of why we'd want to keep a high estimated fee even with anchor for now
13:10 < t-bast> or at least reasonable feerate
13:10 < rusty> roasbeef: yeah, that's what we're doing.  Getting the implementation out the door, doing smart stuff later.
13:10 <+roasbeef> rusty: +1, we did the same 
13:10 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
13:10 < ariard> we can do a anchor-follow-up on all the smart bumping heuristics latter
13:11 < t-bast> I think it would be helpful to share those things outside of the spec
13:11 < t-bast> Anyway shall we start the meeting then?
13:11 <+roasbeef> that's all heuristics stuff
13:11 < rusty> YEah, eventually we should have a feature to turn off fee updates and remove the safety net....
13:12 <+roasbeef> just liek we don't detail all the possible ways you _can_ do path finding in sthe spec 
13:12 < t-bast> everything lies in that "eventually" :D
13:13 < ariard> at the difference than getting wrong path finding doesn't break your implementation contrary to a clumsy bumping making you unsafe
13:13 <+roasbeef> very well could, but you know what I mean 
13:14 < ariard> t-bast: let's start meeting :) ?
13:14 < t-bast> #startmeeting
13:14 < lightningbot> Meeting started Mon Jul  6 20:14:58 2020 UTC.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:14 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:15 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/789
13:15 < t-bast> Let's do some PRs first and we'll get back to anchors afterwards, allright?
13:15 < t-bast> #topic Bump our recommendations for cltv_expiry_delta
13:15 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/785
13:16 < t-bast> We discussed that PR last time and agreed to raise the recommended values
13:16 < t-bast> I updated it to hopefully make the trade-offs a bit clearer without cluttering the spec too much, and raised default recommendations
13:17 < rusty> Acked on issue.
13:17 <+roasbeef> yeah there've been some papers related to this recently 
13:17  * rusty quickly opens a c-lightning issue to increase defaults...
13:18 <+roasbeef> a follow up to that "flood and loot" paper analyezes the current defaults, and compares to a model of malicious hash power % for bribery attacaks 
13:18 <+roasbeef> they also look at values for csv delay as well 
13:18 < t-bast> yes we're starting to see interesting analysis
13:18 < t-bast> so I really don't want to see more channels with a cltv_expiry_delta of 6 on mainnet
13:18 <+roasbeef> this one I just referred to: https://eprint.iacr.org/2020/774 
13:19 <+roasbeef> heh yeh that's pretty low, thankfully fees are low rn, but we shouldn't get complacent 
13:19 <+roasbeef> I even see some values of like 1-4....
13:19 < t-bast> daaaamn
13:19 < cdecker> Oh nice, my former research group
13:19 <+roasbeef> I think part of it is education on the front of the node operator 
13:20 <+roasbeef> cdecker: yeh they've really been cranking out a ton of LN stuff this year, cool to see they continue to explore the research area 
13:20 < t-bast> cdecker: nice!
13:20 < t-bast> do I have another ACK on this PR?
13:20 <+roasbeef> pedro's group as usual also stays steady cranking out papers 
13:20 < cdecker> Should give them a visit some time soon, would love to brainstorm in person for a change ^^
13:20 <+roasbeef> t-bast: down with teh idea in general, will check out the PR, +1 for being more conservative 
13:21 < t-bast> what does "in person" mean? Long time I haven't heard that
13:21 < ariard> what are the new hightlights of this one compared to miner censorship described in original LN paper?
13:21 <+roasbeef> it's like a hologram, but you can touch it 
13:21 < t-bast> roasbeef: cool sgtm, let's defer to github then
13:21 < t-bast> touch it? that's digusting
13:21 <+roasbeef> ariard: this one focuses in the game theory of bribing, with various hash rate distributions 
13:22 <+roasbeef> seciton 3.2 is what analyzes current values of csv delay and chan reserve based on their model 
13:22 < ariard> okay do they give you an equilibrium point between HTLCC value and miner topology ?
13:23 <+roasbeef> it's more about the extra fee to be paid to them than the value iteslf 
13:23 <+roasbeef> but ofc those are related
13:23 < t-bast> #topic Clarify duplicate TLV in stream
13:23 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/777
13:23 < t-bast> Small PR that's been hanging around, clarifying that we disallow duplicate TLV records
13:24 < cdecker> ack
13:24 <+roasbeef> lgtm'd on PR 
13:24 <+roasbeef> speaking of the OP of that PR, has anyone tried out their RGB demo stuff? 
13:24 < t-bast> there's a working demo?
13:25 <+roasbeef> saw some tweet
13:25 <+roasbeef> I think it might just be on-chain stuff, and not actually channel updates yet tho 
13:25 <+roasbeef> I never fully grokked the protocol myself in the channel context tho fwiw....
13:25 < t-bast> interesting, good to know they were able to make progress
13:25 < rusty> I thought the lack-of-dups was obvious, but yes "strictly" is better than "monotonically".
13:25 < cdecker> I'm helping them (RGB) along a bit 
13:26 < rusty> Acked on issue.
13:26 < cdecker> Quite some interesting tech, but still a lot of road ahead
13:27 < cdecker> It's colored coins with off-chain protocol support. I think dr-orlovsky is in this channel as well :-)
13:27 < t-bast> #action Merge PR (enough acks gathered)
13:28 < t-bast> #topic Clarify flip(bits)
13:28 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/779
13:28 < t-bast> Apart from the spellchecker, I think every implementation agrees with that change
13:28 < t-bast> Otherwise nothing would work on mainnet :)
13:29 < rusty> I'll fix spellchecker...
13:29 < t-bast> Thanks rusty!
13:30 < rusty> Though adding 'th' to the dictionary feels... dangerous...
13:30 < rusty> I can see th problems it will cause...
13:30 < t-bast> ^^
13:31  * rusty elects to remove the "'th" in both places instead.
13:31 < t-bast> rusty: ACK
13:33 < rusty> force pushed with those removed...
13:33 < rusty> ... and "..." added.
13:33 < ja> thanks
13:34 < t-bast> #topic Static RemoteKey test vectors
13:34 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/758
13:35 <+roasbeef> doesn't look like the PR has chagned since last time
13:35 <+roasbeef> there're some unresolved comments too 
13:35 < t-bast> IIRC, the latest state was that joost found it a bit weird to have test vector that actually couldn't occur because tx amounts were impossible.
13:35 < t-bast> In my opinion this is mixing layers and these test vectors don't have to care about these requirements
13:36 <+roasbeef> well they should be valid transactions, no? 
13:36 < t-bast> But I don't have a strong feeling about it, if BlueMatt isn't around shall we let this follow up on github?
13:36 <+roasbeef> ppl could even have libs that just refuse to make transactions like that 
13:36 < t-bast> They can be valid bitcoin transaction and not meet reserve requirements (which are covered in a separate bolt)
13:36 < BlueMatt> oh oops. sorry have forgotten to follow up on that (and didnt have any meeting notifications set :( )
13:36 < t-bast> otherwise the risk is that every test vector starts depending on the whole spec which is weird
13:36 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
13:37 < t-bast> Oh hey BlueMatt!
13:37 < BlueMatt> anyway, yes, I dont think anything has changed since last meeting, doesn't need discussion
13:37 < rusty> Yeah, I worked around my problems with the previous vectors for lnprototest (in particular, it's supposed to be the 42nd commitment, but the shachain is stated (0x01020304...) not derivable.
13:38 < t-bast> #topic Anchor outputs
13:38 < rusty> t-bast: it's always nice if the results are derivable from first principles, but I'd rather have test vectors than not!
13:38 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/688
13:38 < t-bast> rusty: exactly :D
13:39 < t-bast> The latest on anchor outputs is that c-lightning and eclair are getting started on the implementation, rust-lightning as well if I'm not mistaken
13:39 <+roasbeef> dope
13:39 < rusty> I'm just grateful for test vectors.  Even YAML ones.  (Which, it turns out, are actually JSON ones)...
13:39 <+roasbeef> well JSON is a subset of yaml ;)
13:39 < rusty> roasbeef: yeah, TIL!
13:39 < t-bast> From what I understand, anchor outputs don't make it worse than what we have today regarding pinning attacks, so we should start with that and once we have package relay on mainnet, migrate to an anchor v2
13:40 < ariard> good to me, I still hope in the long term we can get rid of mempool watching
13:40 < t-bast> FWIW I think the state of the anchor outputs PR is ok, it's clear enough for implementers
13:41 < t-bast> ariard: that would be awesome
13:41 < ariard> should we add CPFP weight in appendix ?
13:42 < t-bast> I have summaries of the pinning discussions here if anyone's interested: https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
13:42 < rusty> I did have a question on the recent 668 weight increase to allow > 253 inputs on the commitment tx.  That seems... weird?
13:43 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev
13:43 < rusty> s/668/688/
13:43 < joostjgr> hi, that was a mistake
13:43 < joostjgr> it must have been >253 outputs
13:43 < ariard> it's the tx_out 
13:43 < joostjgr> corrected in the pr
13:45 < rusty> joostjgr: right... but in practice it's in the noise at that point?  We require 253 minfee (though I couldn't actually find that in the spec!), which means we can't hit the bitcoin minfee?
13:45 < rusty> (Not to mention I think everyone grinds sigs to save a byte?)
13:46 < joostjgr> I think it is consistent to not do such optimizations
13:46 < joostjgr> We have a history ofc, but also no cost to make it consistent now
13:46 < joostjgr> (speaking for lnd)
13:47 < BlueMatt> so regarding the (afair) unresolved issue around changing the htlc tx format: There are essentially two incompatible goals here:
13:47 < BlueMatt> 1) we can have a goal of "the broadcaster can get the tx into the mempool/confirmed, but we dont care about allowing the non-broadcasting side any access to the tx, including seeing it, without a lot of work", then the sighash_single approach is cheaper and simpler to handle,
13:47 < BlueMatt> note that this is essentially the best we can do for *commitment* txn, so maybe we just rely on that for now, but
13:47 < BlueMatt> 2) if we want to have a more robust security model for htlc transactions today, then we can have that, but we need to ditch the sighash_single approach as previously discussed and (probably in a separate change) move towards all htlc txn being pre-signed and CSV 1, with associated state machine changes.
13:47 < BlueMatt> ariard indicated he thought those state machine changes may be required for ptlcs or schnorr or something, so maybe it makes sense anyway, but I dont know if its worth the effort given we cant really possibly have a decent security model today either way.
13:48 < rusty> Yes, but because our minimum fee is not 250 but 253, I think we don't need to take into account the extra 2 bytes for giant txs.
13:48 <+roasbeef> sighash single ftw, it actually lets you bump the fee of the HTLC transaction, which is important since that's what you want to get in 
13:48 < BlueMatt> I *do* think we need to make a conscious decision regarding what security model makes sense to have in mind for anchor before we charge ahead implementing here, it feels super premature.
13:49 <+roasbeef> idk if it's "charging ahead", given it's an issue today, and there're implementations that're deployed that want to help mnitigate things for their users 
13:49 < BlueMatt> roasbeef: that doesnt add anything given the commitment transaction got in.
13:49 <+roasbeef> BlueMatt: ofc it does, for second level transactions, only once that's in can you consider the HTLC "rsolved" 
13:49 < BlueMatt> roasbeef: the current anchor outputs design was written up months before we found a whole series of critical issues in lightning that are highly related. it seems worth discussing those issues before committing to a path forward...
13:49 < t-bast> BlueMatt: I don't see how the suggestion of pre-signed changes anything, you can still pin in miners mempool one tx and have a different one for the rest of the network, so the honest participant won't be able to learn about it either
13:50 < ariard> Yeah I think that was making sense to pre-signed second stage before we realize pinning on the commitment_tx-level
13:51 < t-bast> BlueMatt: you simply have to wait for the timeout block: the attack broadcasts his (pre-signed) ClaimHtlc tx to miners mempool and the HTLC-timeout to the rest of the network
13:51 < ariard> since then we'll need package relay anyway to be secure, so at least let's make user safe against mempool congestion stucking their 2nd-stage
13:51 < BlueMatt> t-bast: it only helps for the htlc txn :/. essentially, if the htlc can only be resolved in one of 4 different txids, then its less of an issue and you can maybe do the blind-bumping approach, or, at least, you probably can presuming an ability to send transactions to a whole mess of nodes
13:51 < BlueMatt> but, indeed, for commitent txn, we're pretty much totally hosed without changes to various other things
13:51 < t-bast> BlueMatt: ok, so you still need to rely on a blind-bumping mechanism, in that case it's slightly better indeed
13:52 < ariard> blind-bumpinh wouldn't work with _current_ propagation, orphan rules
13:52 < t-bast> BlueMatt: but this blind-bumping is still something we don't know how to do properly, right?
13:52 < BlueMatt> *but* it would mean that we dont need the mess of monitoring global mempools for htlc preimages (again, however, if the attacker uses commitment txn to do an attack, you're pretty much screwed)
13:52 < BlueMatt> ariard: remind me why we decided that? I dont recall and I'm now thinking we were wrong, at least assuming there's only 4 valid txids that can be in the mempool and they're all csv 1
13:53 < ariard> BlueMatt: assuming the attacker know tx-relay topology, I can conflict-partition you and your neighboors with txid_1 and throw txid_2 in miner mempools
13:54 < ariard> and your blind-bump won't propagate at the boundary between subsets?
13:54 < BlueMatt> ariard: I dont think so? the htlc-timeouts are all cltv'd
13:55 -!- t-bast [~t-bast@2a01:e34:efde:97d0:81ef:f391:31b8:fe49] has quit [Remote host closed the connection]
13:55 <+roasbeef> re blind bumping, we just anchor down all versions 
13:55 < ariard> BlueMatt: hmmmm, but your bump is going to be an orphan at some point even if you know txid of all combinaisons
13:55 -!- t-bast [~t-bast@2a01:e34:efde:97d0:81ef:f391:31b8:fe49] has joined #lightning-dev
13:55 <+roasbeef> we don't watch the mempoo
13:55 < BlueMatt> t-bast: you missed these lines:
13:55 < BlueMatt> <roasbeef> re blind bumping, we just anchor down all versions 
13:55 < BlueMatt> <ariard> BlueMatt: hmmmm, but your bump is going to be an orphan at some point even if you know txid of all combinaisons
13:56 < BlueMatt> ariard: i mean if it is that means the htlc-success isnt in that nodes' mempool which is ok?
13:56 < ariard> roasbeef: you don't watch the mempool ? How do you decide to broadcast a cpfp on to_remote of remote commitment?
13:56 < BlueMatt> ariard: its more complicated post-timeout, I thinkk, though?
13:56 <+roasbeef> in practice, we haven't run into any issues with that 
13:56 <+roasbeef> ariard: if we force close, we anchor them all down 
13:56 < t-bast> Thanks
13:57 < BlueMatt> roasbeef: I'm confused what you're referring to, here?
13:57 < ariard> roasbeef: right, but you anchor local and remote commitment but only one of them will propagate
13:57 < joostjgr> local, remote commitment and the remote pending one if it exists. three max
13:58 <+roasbeef> ariard: yeah, so which ever one confirms is fine 
13:58 < BlueMatt> roasbeef: you're saying that when you receive an error message you just broadcast all possible anchors on the latest commitment tx?
13:59 < BlueMatt> roasbeef: have you read ariard's list of attacks in the email thread?
13:59 < ariard> BlueMatt: with your blind-bumping how do you jump across a conflict-partition between previous_commitment_tx+HTLC-Success/commitment_tx+HTLC-Success
13:59 <+roasbeef> if we then decide there's a new for us to bump, we can do that 
13:59 <+roasbeef> yeh
13:59 < BlueMatt> ariard: I'm presuming csv-1, so the commitment tx must be on-chain before anything relays
13:59 < t-bast> ariard: I think that's still unknown, and probably out of the normal bitcoin p2p relay :/
14:00 < ariard> BlueMatt: ah yes miss this point so yes you can know which version you have to bump, but that's not a blind one anymore :p
14:00 < t-bast> BlueMatt: but even with that, the attacker can still sneak in right after the block confirmation, right?
14:00 < BlueMatt> roasbeef: sooo, this conversation isnt about commitment txn, I'm not really sure what you're referring to here? or are you suggesting something about commitment txn applies to htlc txn?
14:00 < ariard> assuming it's pre-signed
14:00 < BlueMatt> ariard: well, its not *really* blind, its only blind in that you dont really have to look at the mempool to know whats there
14:00 < BlueMatt> t-bast: it relies pretty heavily on rebroadcasting, I think
14:01 < BlueMatt> but, I think thats maybe ok?
14:01 <+roasbeef> was talking about the way you anchor down w/e may get in 
14:01 < ariard> BlueMatt: gotcha, was confused with your other ideas of noinput+cpfp, also called blind-bumping at some point
14:01 < t-bast> BlueMatt: but that's where the attacker can fill the network's mempool to create the partition and prevent p2p relay...unless I'm still missing something
14:01 < BlueMatt> ariard: ah, right, I think I was maybe trying to get the same mental model to apply there, but I'm not convinced it makes sense in that context.
14:01 -!- yzernik [~yzernik@2600:1700:dc40:3dd0:a951:a371:d80e:5a83] has quit [Quit: ZNC 1.7.5 - https://znc.in]
14:01 <+roasbeef> the #2 above there, also means state machine changes as I've mentioned before 
14:01 < ariard> roasbeef: yes it works if you rebroadcast every X blocks in case the remote commitment win the propagation race but the anchor on remote has always been evicted
14:01 < BlueMatt> roasbeef: right, ok, so you're just saying that you think blind bumping makes sense in general?
14:02 -!- yzernik [~yzernik@2600:1700:dc40:3dd0:b407:1c33:63e9:77d] has joined #lightning-dev
14:02 <+roasbeef> ptlc or scnhorr also doesn't really have any time frame rn, and this is a big issue today w/ more an dmore papers bringing attention to it
14:02 < BlueMatt> t-bast: right, I dont think there's any (current) way of addressing that except package relay, essentially
14:02 <+roasbeef> how do we define blind bump, like bump-em-all? 
14:02 < t-bast> BlueMatt: ok thanks, that's clear, we agree on that
14:02 < BlueMatt> roasbeef: essentially. yes. the idea being bump what you know could be in the mempool, but arent sure if its there
14:03 <+roasbeef> mhmm, that's what we do rn
14:03 < BlueMatt> (of course that doesnt work/make sense for commitment txn cause there's millions of those, but for htlc txn we can make it work)
14:03 <+roasbeef> our next release is going to have dynamic bumping based on cltv delay too 
14:03 <+roasbeef> and the looming deadline 
14:03 < t-bast> roasbeef: but you can't do it anymore with the sighash_single change, you don't know the final txid of the HTLC-success / HTLC-timeout?
14:03 < ariard> changing state machine may take us as long as getting package relay on the base layr
14:04 <+roasbeef> t-bast: thought we're talking about the anchor on the commitment? 
14:04 <+roasbeef> as in bump that 
14:04 < BlueMatt> roasbeef: no, we've been talking about anchors on htlcs this entire time :)
14:04 < ariard> yes we already do bumping based on cltv_delay limit approaching
14:04 <+roasbeef> i don't think that revocation thing is an issue, only what matters is what gets in the chain
14:04 < ariard> actually we do this for any kind of transaction, not only HTLC claiming
14:04 < BlueMatt> ariard: I dont see why adding one more message to the state machine should take years?
14:05 <+roasbeef> t-bast: the single change means you can aggregate htlcs, and also include the second level htlc transaction bunlded w/ _other_ transactions that you might've already been doing as well 
14:05 < t-bast> roasbeef: even for commitment tx, the attack ariard described ensures your bumps will never propagate...
14:05 < BlueMatt> roasbeef: you should go read ariard's email! I promise its quite excellent
14:05 <+roasbeef> the devil is always in the details 
14:05 <+roasbeef> re state machine changes 
14:05 < t-bast> I mean ariard's attack on the ML
14:05 <+roasbeef> which already is rather underdefined int eh spec 
14:05 < ariard> roasbeef: timelocks being committed by sighash in pratice that's pretty limited for HTLC-timeout, but still a gain for preimage ones
14:06 <+roasbeef> ariard: nah, we already time lock transactions we do from the normal wallet 
14:06 <+roasbeef> the timelock value 
14:06 < t-bast> roasbeef: yeah I agree that the sighash change does have a lot of good things for the honest participant, it's just sad that it also has a few drawbacks that help attackers...trade-offs, trade-offs everywhere
14:06 <+roasbeef> but yeh nice for sweeps too 
14:06 <+roasbeef> t-bast: yeh tradeoffs, so lets satisfice and get something out to protect our users from even the non-adversarial cases where they could lose out 
14:07 < BlueMatt> t-bast: so, I think re: flooding the mempool I'm maybe a tiny bit less worried about that attack, especially for attacking htlc txn.
14:07 <+roasbeef> as this threat model has just been continually expanding 
14:07 < BlueMatt> roasbeef: we've got two options here, both accomplish that.
14:07 <+roasbeef> it's a mistake to try to solve everything in one swoop 
14:07 < BlueMatt> no one is suggesting we do that
14:07 <+roasbeef> when even w/o 3rd parties interacting, bad things can happen rn 
14:07 < t-bast> but overall I think we should still move forward with anchor outputs and the sighash changes, it allows us to implement a lot of things that will be useful later when we have package relay to tackle the latest threat model updates
14:07 < BlueMatt> but lets also please *not* charge forward with something that we'll have to undo six months later
14:08 < ariard> I think we want more to agree on how we are going to solve every attach and be sure we dom't do 2 steps forward 1 backward
14:08 < ariard> *attack
14:08 <+roasbeef> charge forward is relative here, given that this is also a link level change, this isn't bitcoin script 
14:08 < BlueMatt> t-bast: well, i mean, no, once we get package relay I think we'll move towards anchor on the htlc txn
14:08 < BlueMatt> not sure, but I think.
14:08 <+roasbeef> what we deployed has been ready for 6+ months already 
14:08 < ariard> yes anchor-ouput current version is goodd against mempool-congestion unsafeties
14:08 <+roasbeef> none of the package relay or ptlc or scnhorr stuff even has a realistic time frame
14:08 < joostjgr> ariard: what is the heuristic that you use for bumping when the cltv limit approaches?
14:09 < ariard> joostjgr: you mean to increase feerate or decide when the next bumping happens?
14:09 < joostjgr> the 'curve' that you walk along towards expiration
14:09 < t-bast> BlueMatt: maybe, but I think we can phase things to update from anchor outputs (the current one), can't we?
14:09 < BlueMatt> roasbeef: we've been talking about it for ~3 years, so, yea, I think the rush given we've learned more in the past month than in three years is somewhat strange. anyway, it seems worth having the conversion. given we maybe are getting some clarity on what things will look like when we get to an actually-secure lightning mempool model.
14:10 < t-bast> Because I think we can realistically have the current anchor outputs proposal shipped in less than 3 months, which solves many issues we have today (and simpler attacks than the pinning ones)
14:10 <+roasbeef> BlueMatt: yeah i know, i was part of the original convos, i'm talking baout this conrete version 
14:10 < BlueMatt> t-bast: sure, I mean we can also have current anchors-but-only-on-the-commitment-txn shipped even quicker, though :)
14:10 <+roasbeef> also we're already deployed and have active users, I can understand if RL wants to wait longer since they haven't fully "deployed yet", but the rest of us don't need to adopt that framing 
14:11 < ariard> joostjgr: rn it's 3 modes, if less than 3 blocks, re-schedule next block, if less than 15 blocks, re-schedule in 3 blocks, if more re-schedule in 15
14:11 <+roasbeef> we have skin in the game as is 
14:11 < BlueMatt> roasbeef: I dont really care about RL for this stuff, tbh.
14:11 <+roasbeef> lol wat?
14:11 < t-bast> BlueMatt: true, but the simple attacks that exist today on HTLCs can't be mitigated with only the commit tx changes (AFAIK)
14:11 <+roasbeef> but y'all are implementing it..right?
14:11 -!- Pavlenex [~Thunderbi@185.245.85.251] has quit [Quit: Pavlenex]
14:11 < BlueMatt> roasbeef: as-is, I dont think anyone should be using lightning peered with anyone who isnt fully-trusted. period. and they shouldnt until we've figured this stuff out. hence why I'm trying to figure this stuff out :)
14:12 < ariard> roasbeef: yeah it's more important to get Lightnign right overall than just RL not being exposed there
14:12 < BlueMatt> t-bast: sure, but thats what the in-flight limit is for :)
14:12 <+roasbeef> ok you're free to share that world model lol 
14:12 < joostjgr> ariard: and which fee rates do you use then? if you get close to expiry, potentially the full value of the htlc is at stake.
14:12 <+roasbeef> also as usual, security isn't binary 
14:13 < t-bast> BlueMatt: yeah you can limit how much you lose, and probabilistically protect from the attack with high enough cltv_expiry_delta, but it's not a 100% protection though...
14:13 < BlueMatt> t-bast: sure, but none of what we're talking about is "protection" :)
14:13 < ariard> joostjgr: if your fee-estimator has changed since last time use it, hence a dumb 25%
14:13 < BlueMatt> its only a "two honest parties who screwed up their feerate selection are cooperating to get the latest state on the chain" fix
14:13 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
14:13 <+roasbeef> existence of known issues or attacks against a protocol doesn't render it unusable or "broken" 
14:13 <+roasbeef> we all still use tor after all
14:14 < BlueMatt> eh, this probably isnt a relevant debate.
14:14 < ariard> same with bitcoin base layer saying it's 100% secure wouldn't be accurate
14:14 < joostjgr> ariard: ok. we generally republish every block with an updated fee estimate. some of those may violate bip125 rules, but we don't care. only problem is that if the conf target is high, it may still not conf in time. because it is only an estimate. so in some cases we lower the conf target when we get closer
14:15 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
14:15 < BlueMatt> I'm curious what rusty's take is
14:15 < BlueMatt> given he also worked on implementing this stuff and has put time in
14:16 <+roasbeef> iirc, he's on board w/ protecting our current users, w/ what we have already, given bad things can happen rn even w/o any malicious actors 
14:16 < ariard> joostjgr: right because you may not account for bandwidth increase? lowering the conf target is quite equivalent to bump more aggressively as I'm trying to do I think
14:16 < rusty> BlueMatt: it's unfixable.  Bitcoin core needs to have an emergency RBF rule that says if the previous package was not in the top 4MW and the replacement would be in the top 3.2MW, it accepts it whether the other feebump rules are met or not.
14:16 < BlueMatt> to restate the question at hand - do we accept that the best we can do is help two-honest-counterparties get their txn on chain and stick with that model for htlc txn as well, or do we redo the htlc txn format for anchors so that we can get better security for them
14:16 < rusty> Then you can just bid it into the next block.
14:16 <+roasbeef> and there's other pinning issues also outside of all this stuff even
14:16 < ariard> BlueMatt: mempool-congestion unsafety, even it's an edge-case (like 0.000001%) is worthy to fix
14:16 < BlueMatt> rusty: agreed (plus package relay) essentially.
14:17 < joostjgr> ariard: ok, i see. so you follow your fee estimator, but if the needle doesn't move anymore, you override with 25%?
14:17 < BlueMatt> rusty: (but thats somewhat a different question - i think it *is* fixable, essentially, today, for htlc txn)
14:17 -!- Relis [~Relis@148.252.129.179] has quit [Ping timeout: 256 seconds]
14:18 < ariard> rusty: you also need p2p changes to relay as a package, and a way to actually compose them, either by relay or initial-sender
14:18 < BlueMatt> rusty: (as an aside, I've had a few productive chats recently about possibly utilizing a rule like that to fix this whole mess, or at least make it more sensible)
14:18 < rusty> ariard: why?  
14:18 < t-bast> BlueMatt & Rusty: if Bitcoin offers that (in the future), we can fix the issue while keeping the sighash changes on htlc txs and not requiring anchors on HTLCs, which would be great because anchors on every HTLC are costly...
14:18 < BlueMatt> t-bast: I dont believe so, no.
14:18 < ariard> joostjgr: yes a dumb override with 25%, actually I think a more sophisticated version would try to re-bump even between blocks if you observe significant congestion increase
14:19 <+roasbeef> also the p2p changes need to be super widely propagated to do anything 
14:19 < BlueMatt> t-bast: I believe the sighash chages are fundamentally incompatible with fixing these issues.
14:19 <+roasbeef> t-bast: +1
14:19 < BlueMatt> t-bast: at least, I dont see how to fix it)
14:19 < ariard> t-bast: I think we quite all agree there :)
14:20 < BlueMatt> rusty: because if the pre-signed commitment tx has a low fee, you have to be able to relay that commitment tx (with its low fee) and a bump txn based on it to make the whole group have a higher fee :(
14:20 < ariard> roabseef: yes you need to have a least a propagation path to miner mempools, so if you assume 8 outbounds peers, you might night 30% of network updages
14:20 < ariard> *need
14:20 < rusty> ariard: meh, if bitcoind just deferred evaluation of incoming low-fee txs for some (perhaps long) time, that would cover it.  Turns out, that would also cover the concerns about flooding the network with cheap RBF replacements.
14:21 < t-bast> BlueMatt: but in the case of a confirmed commit tx, the attacker and the honest participant are competing to spend the same confirmed output: so if the honest participant can attach a high fee to his HTLC-timeout to get it to replace a low-fee pinned HTLC-success (that's hidden in far-away mempool) all his good regardless of the sighash of the HTLC-success?
14:21 <+roasbeef> ariard: mhmm, and uprades take time...unless there's a soft-fork or something in flight 
14:21 < t-bast> BlueMatt: ok I'm assuming we got the commitment tx confirmed
14:21 < ariard> BlueMatt: wait if you have package relay you can bump a pinning on 2nd-stage?
14:21 < rusty> Though it would change the current model where the mempool is considered something you can reliably throw lowfee txs into every few days, but that's arguably broken anyway.
14:21 < BlueMatt> t-bast: note that you cannot enforce the "top 4MW of the mempool" rule that rusty is just talking about here in a sighash_single tx
14:22 < t-bast> BlueMatt: can you detail?
14:22 < BlueMatt> ariard: I dont think this all works out without the "top 4MW of the mempool" rule, thing
14:22 < ariard> roasbeef: sure, but still you can ask LN operators to upgrade nicely their full-node to increase _our_ whole security
14:23 < ariard> rusty: perhaps but that sounds like a censorship vector if I can tweak your mempool rules, and still you need to reverse topology-order
14:23 < BlueMatt> to avoid the "but you can waste infinity bandwidth" issues, I think the elegant solution, as rusty points out, is to allow txn to carry a flag which says "I only want to get into the mempool if I'm gonna be in the next block or two" - this implies that the proability of the tx getting mined is high enough that free relay for it can be allowed (at least, hopefully, this isn't a well-socialized idea, but its at least possible)
14:23 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
14:23 < ariard> announcement to your p2p peers
14:24 < BlueMatt> sooo, to have package-relay-rbf you probably need such a flag (and a way of *enforcing* that that flag be set - on commitments and htlc txn)
14:25 < BlueMatt> rusty: I believe the larger concern of suhas' is around mempool standardness changes causing honest nodes to DoS each other by downloading the same package over and over again.
14:25 < ariard> BlueMatt: yes the tagging we talked offline is needed, you need a way to signal "this transaction might be part of a higher-feerate package and we need to do discovery"
14:25 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 258 seconds]
14:25 < t-bast> can't we get clever and use specific nSequence or nLockTime values as a flag to ensure it's covered by the sighash_single sig (maybe a dumb proposal)?
14:25 <+roasbeef> ariard: we don't really know what the propagation graph looks like, but yeh we have this new class of nodes that may be more willing to upgrade sooner 
14:25 < t-bast> actually not nSequence then
14:25 < BlueMatt> rusty: also, note that the actual effort of calculating a tx's fee can for some nodes be most of the DoS potential :(
14:26 < BlueMatt> t-bast: yes, I presume thats how we'd do it.
14:26 < ariard> rusty: if you tag them, you can have different tx-relay policies per class of transacion
14:26 < ariard> at least with RBF you already have 2 classes
14:26 <+roasbeef> let's remember to keep ourselves grounded, we can't count on pkg relay stuff or other mempool policy changes 
14:26 < BlueMatt> t-bast: but, note, you cannot sighash_single|sighash_anyonecanpay such txn.
14:26 <+roasbeef> this is a real issue today that affects all LN users, where bad stuff can happen even w/o outside interference 
14:26 <+roasbeef> input level lock-time would be amazing 
14:27 < BlueMatt> roasbeef: yes, agreed. we should be building something to deploy today keeping in mind the end-state that we want to get to to be comfortable with the whole picture
14:27 <+roasbeef> for stuff outside of this too 
14:27 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has quit [Quit: Leaving]
14:27 <+roasbeef> mhmmm, and some of us havve more skin in the game than others, given they're widely deployed already
14:27 <+roasbeef> also this is a link level upgrade, not a bitocin script upgrade, just you and your peer need to agree 
14:27 < t-bast> BlueMatt: even if it's an `nLockTime` flag? This should be covered by the sig, isn't it?
14:27 < BlueMatt> ie the above is describing a potential end-state...so as to inform what we may want to do today
14:28 < rusty> BlueMatt: yes, failing to have a simple way of representing the fee in bitcoin txs sucks hard.
14:28 < ariard> BlueMatt: on this package-relay-rbf you still have to manage conflit at the relay-side between the delay time
14:28 < ariard> BlueMatt: and wrt to mempool Dos actually you can introduce package_id
14:28 < BlueMatt> rusty: anyway, you should chat with suhas! I think he's interested in maybe workng on this stuff again post-wtxid-based-relay, I'm sure you'd be super useful in helping him think through ideas :)
14:29 < rusty> BlueMatt: ack.
14:29 < BlueMatt> t-bast: I think my concern is more about having a tree of unconfirmed parents, which I thinkw ould break this
14:29 < ariard> to avoid a parent A being ban first for being attached with a low-feerate child 
14:29 < ariard> and then reevaluated with a higher-feerate child
14:29 < t-bast> BlueMatt: ok, but we could restrict this rule/flag to only be accepted in mempools if all parents are confirmed or something like that?
14:29 < BlueMatt> ariard: I *think* this stuff only makes sense if the flag is set on a tx with no in-mempool parents
14:30 < BlueMatt> (ie commitment txn, htlc txn spending a csv-1 value)
14:30 < ariard> BlueMatt: yes that I meaned offline by utxo-spender opt-in!
14:31 < rusty> ariard: good point.  You can't blacklist a tx for being too low fee, if you want it to be bumpable.
14:31 -!- slivera [~slivera@103.231.88.26] has joined #lightning-dev
14:31 < BlueMatt> ariard: Hmmmm E_NO_PARSE :(
14:31 < rusty> OK, hard timeout for me, sorry! gtg
14:31 < BlueMatt> see ya rusty! can we do an audio/video call about this this/next week?
14:31 -!- Relis [~Relis@185.69.144.160] has joined #lightning-dev
14:31 <+roasbeef> we've spun our wheels so much on this, it's really dissapointing
14:31 < BlueMatt> I'm sure roasbeef will be happy if we stop chasing our tails :)
14:32 < ariard> BlueMatt: cf the signal conv I've answered yet!
14:32 <+roasbeef> which is why we just deployed, as no one else had an actual urgency to deploy a solution to protect our users 
14:32 < ariard> not answered
14:32 < t-bast> I'll have to drop off soon, I'd like to thank everyone for the discussion; I think it's important to acknowledge that there are issues to solve (thanks BlueMatt/ariard for pressing on those) and keep the long-term discussions going, while still making short-term progress to fix shorter term issues (thanks roasbeef/joost for the current anchor proposal)
14:32 < BlueMatt> roasbeef: last I heard others were way ahead of y'all on this - and actively scanning the mempools of many nodes on the network to address attacks :)
14:33 <+roasbeef> other ppl have deployed anchors?
14:33 < t-bast> Trade-offs are hard, but I'm sure we'll be getting there in the long run ;)
14:33 < BlueMatt> t-bast: totally aggreed! tbh I mostly just want to see a conclsion on what security model we want for these things and then we should move forward as fast as possible :)
14:34 < t-bast> roasbeef: on it, can you lend me johan and joost for a couple of months? :D
14:34 <+roasbeef> that's the other thing, the security model is just every growing now, it's leaked into network level node linking
14:34 < ariard> roasbeef: I think we agree on anchors, discussion was more on global-mempool-watching vs package-relay as security models
14:34 < t-bast> BlueMatt: great, I think we are making some slow progress on that, week by week ;)
14:34 < ariard> to fix advanced pinning
14:35 < BlueMatt> t-bast: yea. would be nice to schedule a more high-bandwidth chat so we can conclude this
14:35 < BlueMatt> I *think* we've played about enough with the issues here that we have some kind of idea whats at play and at least one or two ideas for where to go in the long-term
14:35 < ariard> roasbeef: yes but you can't evict the base layer model from the lightning one, and AFAIK pinning wasn't scoped in original LN paper
14:36 < t-bast> #action t-bast to start mail thread for video/call meeting
14:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 272 seconds]
14:36 < t-bast> Allright dropping off, thanks everyone!
14:36 < t-bast> #endmeeting
14:36 < lightningbot> Meeting ended Mon Jul  6 21:36:43 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:36 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-07-06-20.14.html
14:36 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-07-06-20.14.txt
14:36 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-07-06-20.14.log.html
14:36 < BlueMatt> see y'all
14:36 -!- t-bast [~t-bast@2a01:e34:efde:97d0:81ef:f391:31b8:fe49] has quit [Quit: Leaving]
14:37 <+roasbeef> ariard: not saying you should, but you need to constrain things, otherwise you try to fix everything at once 
14:46 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Quit: Leaving]
15:11 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Ping timeout: 256 seconds]
15:14 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
15:14 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
15:19 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 264 seconds]
15:33 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
15:35 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
15:40 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 272 seconds]
15:45 -!- jeremyrubin [~jr@2601:645:c200:f539:54da:42a6:fcf0:11d7] has quit [Quit: Konversation terminated!]
15:45 -!- jeremyrubin [~jr@2601:645:c200:f539:21b6:bf4:fe1d:6ab9] has joined #lightning-dev
16:00 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #lightning-dev
16:05 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
16:06 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds]
16:12 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
16:15 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Ping timeout: 256 seconds]
16:17 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 264 seconds]
16:28 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
16:30 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
16:31 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
16:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
16:35 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
16:49 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
16:50 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
16:54 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 258 seconds]
17:21 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 265 seconds]
17:49 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
17:50 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
18:06 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
18:12 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
18:13 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
18:15 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
18:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
19:07 -!- pigeons_ is now known as pigeons
19:15 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
19:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
19:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
19:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
19:31 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
19:36 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 256 seconds]
19:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
19:42 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
19:55 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 246 seconds]
19:55 < ariard> https://arxiv.org/pdf/2007.00764.pdf
19:56 < ariard> heuristic to map LN nodes to Bitcoin _utxo_ entities
19:56 < ariard> "We also present cross-layer linking heuristics that can, withour dataset, link43.7% of all LN nodes to26.3%"
19:57 < zmnscpxj_> Further, we find the security and privacy of the LN area t the mercy of as few as five actors that control 34 nodes and over 44% of the total capacity
19:58 < ariard> "Moreover, the possible deanonymizationof Bitcoin entities hereby presented shows that it is crucial toconsider the privacy of both layerssimultaneouslyinstead ofone of them at a time as largely done so far in the literature." and we should do the them with privacy :/
19:58 < ariard> *security 
19:58 < ariard> the same
19:59 < ariard> (even if you fix vulns layer by layer)
20:00 < zmnscpxj_> nearly every interesting attack is a layer-crossing attack. e.g. SQL injections from HTML forms
20:01 -!- Relis [~Relis@185.69.144.160] has quit [Ping timeout: 246 seconds]
20:03 < zmnscpxj_> I believe fundchannelv2 at least allows the possibility of multiple nodes creating channels in a single transaction, for whatever little benefit in privacy this might have
20:09 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
20:11 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit]
20:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
20:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit]
20:17 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
20:22 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 256 seconds]
20:26 -!- norisg_ [~nobody123@ipservice-092-209-139-225.092.209.pools.vodafone-ip.de] has joined #lightning-dev
20:29 -!- norisg [~nobody123@ipservice-092-209-139-225.092.209.pools.vodafone-ip.de] has quit [Ping timeout: 260 seconds]
20:48 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
20:56 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 246 seconds]
21:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
21:13 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has quit [Remote host closed the connection]
21:14 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has joined #lightning-dev
21:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
21:39 -!- alko89 [~alko89@unaffiliated/alko89] has joined #lightning-dev
21:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
21:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
21:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
21:46 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds]
22:21 -!- rdymac [uid31665@gateway/web/irccloud.com/x-uhaxmxkgaipvqnwp] has quit [Quit: Connection closed for inactivity]
22:34 -!- cryptoso- [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
22:35 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Ping timeout: 240 seconds]
22:44 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 246 seconds]
22:53 -!- Amperture [~amp@65.79.129.113] has joined #lightning-dev
22:54 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
22:54 -!- cryptoso- [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection]
22:55 -!- Amperture [~amp@65.79.129.113] has quit [Client Quit]
22:58 -!- stiell [~stian@fsf/member/stiell] has joined #lightning-dev
23:02 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
23:06 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 260 seconds]
23:07 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 246 seconds]
23:13 -!- stiell [~stian@fsf/member/stiell] has joined #lightning-dev
23:19 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 256 seconds]
23:21 -!- stiell [~stian@fsf/member/stiell] has joined #lightning-dev
23:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
--- Log closed Tue Jul 07 00:00:12 2020