--- Log opened Sun May 01 00:00:10 2022
01:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
01:34 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #lightning-dev
01:55 -!- Ghulie [~Ghulie@gateway/tor-sasl/ghulie] has quit [Remote host closed the connection]
01:55 -!- Ghulie [~Ghulie@gateway/tor-sasl/ghulie] has joined #lightning-dev
01:58 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
02:00 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
02:10 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Remote host closed the connection]
02:10 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
02:17 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
02:20 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
02:30 -!- Ghulie [~Ghulie@gateway/tor-sasl/ghulie] has quit [Remote host closed the connection]
02:41 -!- rusty [~rusty@118.211.70.216] has joined #lightning-dev
02:51 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
02:55 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 240 seconds]
02:55 -!- rusty [~rusty@118.211.70.216] has quit [Ping timeout: 256 seconds]
03:01 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev
03:02 -!- rusty [~rusty@115-166-28-156.tpgi.com.au] has joined #lightning-dev
03:07 -!- rusty [~rusty@115-166-28-156.tpgi.com.au] has quit [Ping timeout: 272 seconds]
03:13 -!- rusty [~rusty@115-166-28-156.tpgi.com.au] has joined #lightning-dev
03:35 -!- rusty [~rusty@115-166-28-156.tpgi.com.au] has quit [Ping timeout: 240 seconds]
03:59 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...]
04:05 -!- stick [sid403625@user/prusnak] has quit [Quit: Connection closed for inactivity]
04:13 < darosior> remyers[m]: yes that would fix it. Especially having the possibility to have one, but only one, additional input would help a lot because you have the benefits of input-based fee-bumping (no need to bother with descendant limits, no need to rely on the carve-out) without the current limitations
04:14 < darosior> (of course input-only fee bumping has other tradeoffs, esp. wrt the preparation of coins since you are consuming them entirely)
04:15 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
04:30 < remyers[m]> Antoine's post on fee bumping has a good discussion of input based methods ett APO
04:30 < remyers[m]> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html
06:10 -!- An0rak [An0rak@user/an0rak] has quit [Ping timeout: 272 seconds]
06:13 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev
06:36 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
06:48 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
06:50 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
07:00 < jeremyrubin> Input based bumping is inherently insecure, so it only fixes it if you commit to exactly one input
07:02 < jeremyrubin> Additional unspecified input is as bad as as many as you like IMO
07:02 < jeremyrubin> Unless we somehow commit to max additional weight
07:03 < jeremyrubin> You also go back to CpFP which means txns need to be cpfp bumpable 
07:04 < darosior> Right
07:04 < darosior> No, you don't go back to CPFP? The tx that you want to bump is effectively the child
07:06 -!- jespada [~jespada@cpc121022-nmal24-2-0-cust171.19-2.cable.virginm.net] has joined #lightning-dev
07:07 -!- jespada_ [~jespada@89.238.143.238] has joined #lightning-dev
07:08 -!- jespada_ [~jespada@89.238.143.238] has quit [Client Quit]
07:10 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 240 seconds]
07:11 -!- jespada [~jespada@cpc121022-nmal24-2-0-cust171.19-2.cable.virginm.net] has quit [Ping timeout: 272 seconds]
07:19 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
07:21 < _aj_> isn't the only time miners would (rationally) prefer a pinned tx (over a higher fee rate, lower total fee alternative package) when the pinned tx is going to make it into the next block anyway (and thus pinning serves no purpose to an attacker)? making mining/relay more "rational" seems like the best approach, unless there's really easy ways to avoid pinning...
07:25 < jeremyrubin> The issues around this are immense 
07:25 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev
07:26 < jeremyrubin> This feerate based approach can make it very cheap to flush a peers mempool entirely 
07:26 < jeremyrubin> Hence my earlier comment we might need to have more than one mempool with different policies and you can submit to either. 
07:27 < jeremyrubin> But having one universal policy seems hard to actually meet all constraints and concerns 
07:28 < jeremyrubin> So while you're right that it's more rational, it's also rational to not let someone drain your mempool entirely 
07:31 -!- jespada [~jespada@194.37.96.110] has joined #lightning-dev
07:32 < _aj_> "make it more rational" could easily mean "have multiple mempools"
07:33 < _aj_> could also be "solve an intractable problem, even for modestly better results", though hopefully not
07:36 < darosior> _aj_: i think this logic extends to the second block, too. Once the top 1vMB gets mined, you don't want to be mining a template with less absolute fees. And then to the following blocks
07:36 < darosior> So replace by feerate is only rationale in specific cases
07:39 < _aj_> darosior: i think even then, when you're constructing the top block, you (and every other miner) would rather get the higher fee rate tx into that top block; you only want the pinning tx around in case some other miner mines the next block and doesn't include either
07:39 < jeremyrubin> _aj_ either way it's prob something to solve for before advancing APO as a workable solution for LN, since I think without punishment it's much more important that bad behavior actually be stoppable 
07:39 < _aj_> jeremyrubin: yes, agree
07:39 < jeremyrubin> And I highly suspect that approaches based on mutable txns enter the domain of intactible problem 
07:40 < _aj_> jeremyrubin: don't agree with that, but we'll see
07:40 < jeremyrubin> Can you think of a framework to test my hypothesis?
07:41 < jeremyrubin> E.g. is there some model we can show a result of complexity in that would convince you one way or another 
07:41 < _aj_> huh? "coming up with a good enough solution to x is intractable" can only be refuted
07:42 < _aj_> "coming up with solution y which also works is easier" is the closest you can get, but then you have to come up with solution y
07:46 < jeremyrubin> I can't parse that 
07:47 < jeremyrubin> I'm just asking if there's an exercise which we can do which moves your understanding toward intactible or moved mine towards not interactible. 
07:47 < _aj_> beyond "come up with ideas and simulate/implement them", i don't think so?
07:49 < _aj_> mining doesn't need to (and doesn't) produce the absolute optimum fee for a block, and you can never guarantee your tx getting into a block anyway, so intractability results just don't see apropriate
07:49 < jeremyrubin> Gotcha. 
07:50 < jeremyrubin> So maybe one thing that helps is defining what the expectation of the mempool should be
07:50 < jeremyrubin> Eg see Peter Todd not liking sponsors 
07:50 < jeremyrubin> I think his complaint is whack 
07:51 < jeremyrubin> But without a shared expectation of what the mempool should do it's he said he said 
07:54 < _aj_> coming up with either a different structure for the mempool, or a different way of using it both seem like "come up with iideas and simulate/implement them" to me
07:55 < evanlinjin> I don't think multiple mempools will solve anything since, at the end of the day, it only matters which mempool policies the miners uphold that determines what get's mined and what does not.
07:55 < evanlinjin> Also, what is the difference between "multiple mempools" and "nodes upholding different mempool policies"?
07:56 < jeremyrubin> Two mempool in one node
07:56 < jeremyrubin> Each resists different attacks
07:56 < _aj_> as it stands, a node's mempool won't allow two conflicting txs to both be present (eg, your tx and the pinning tx that is preventing your tx from being mined). multiple mempools might be one way of loosening that restriction
07:57 < evanlinjin> Thanks for the explanation, that makes sense!
07:58 < evanlinjin> Apologies for just barging in the conversation, it just caught my interest
07:58 < jeremyrubin> Pinning is an attack against users, and against single shot rational miners, whereas mempool flushing is an attack against single shot rational miners and longer term miners 
07:59 < jeremyrubin> So if you want to resist both attacks, it might be infeasible to have a single policy that fits both 
07:59 < jeremyrubin> But having two different conflicting domains might allow for attacks on one side but not the other 
08:00 < jeremyrubin> So then the mempool has a way of being only half flushed 
08:00 < evanlinjin> That makes sense, thank you for clarifying
08:00 < evanlinjin> I have not heard of a "mempool flushing attack", will search it up
08:01 < evanlinjin> Actually, do you have recommended resources for understanding "mempool flushing attack"? Thank you in advance
08:10 < _aj_> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019921.html has an example i think
08:10 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
08:23 < jeremyrubin> I also posted some similar examples in the GitHub discussion with Gloria 
08:34 -!- yonson_ [~yonson@ip68-105-113-161.sd.sd.cox.net] has joined #lightning-dev
08:35 -!- yonson [~yonson@2600:8801:d900:0:529a:4cff:fe65:a337] has quit [Ping timeout: 240 seconds]
08:44 -!- preemz [~preemz@73.58.92.183] has joined #lightning-dev
08:49 < evanlinjin> Thank you
09:14 < jeremyrubin> Another reason we may need to do 2 mempools, at least
09:14 < jeremyrubin> people have a 'reliance interest' in the way the mempool works today continuing to work tomorrow
09:15 < jeremyrubin> even if we can design 1 mempool that works for a wide variety of interests, if it is incompatible with deployed applications we might need to support two paradigms so as to keep existing applicaitons happy
09:27 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Remote host closed the connection]
09:35 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
09:46 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Remote host closed the connection]
10:02 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
10:18 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
10:25 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 256 seconds]
10:54 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
11:15 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Remote host closed the connection]
11:28 -!- preemz [~preemz@73.58.92.183] has quit [Ping timeout: 272 seconds]
11:47 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
12:04 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 246 seconds]
12:25 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev
12:49 -!- An0rak [An0rak@user/an0rak] has joined #lightning-dev
12:53 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection]
12:53 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev
13:04 -!- preemz [~preemz@73.58.92.183] has joined #lightning-dev
13:04 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #lightning-dev
13:21 -!- An0rak [An0rak@user/an0rak] has quit [Ping timeout: 250 seconds]
13:24 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
13:25 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Remote host closed the connection]
13:26 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
13:31 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 276 seconds]
13:56 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
14:00 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 256 seconds]
14:14 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
14:19 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
14:23 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 250 seconds]
14:23 -!- Guest9057 [~Guest90@123-1-21-85.area1b.commufa.jp] has joined #lightning-dev
14:24 -!- preemz [~preemz@73.58.92.183] has quit [Ping timeout: 272 seconds]
14:30 -!- Guest9057 [~Guest90@123-1-21-85.area1b.commufa.jp] has quit [Quit: Client closed]
15:23 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
15:29 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 276 seconds]
15:48 -!- rusty [~rusty@120-88-143-254.tpgi.com.au] has joined #lightning-dev
15:50 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
16:04 -!- rusty [~rusty@120-88-143-254.tpgi.com.au] has quit [Ping timeout: 276 seconds]
16:06 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Remote host closed the connection]
16:26 -!- yuya [~yuya@123-1-21-85.area1b.commufa.jp] has joined #lightning-dev
16:26 -!- yuya [~yuya@123-1-21-85.area1b.commufa.jp] has quit [Remote host closed the connection]
16:27 -!- yuya [~yuya@123-1-21-85.area1b.commufa.jp] has joined #lightning-dev
16:37 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
16:39 -!- yuya [~yuya@123-1-21-85.area1b.commufa.jp] has quit [Quit: Leaving]
16:42 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 256 seconds]
16:42 -!- bucko_ [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
16:46 -!- preemz [~preemz@73.58.92.183] has joined #lightning-dev
16:53 -!- bucko_ [bucko@gateway/vpn/protonvpn/bucko] has quit [Remote host closed the connection]
16:53 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
16:58 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 272 seconds]
17:22 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
17:23 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
17:25 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds]
17:28 < ariard> jeremyrubin: re-rbas and malleable inputs, no full analysis yet if safe, furthest discussion is https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020139.html iirc
17:29 < ariard> though not sure if i agree with pinning worsening with APO compare to LN-penalty, rn an attacker can try a pin with two valid commitment transactions, as no risk
17:29 < ariard> e.g with current LN state machine, you own two valid commitment transactions before to release rev secret
17:33 < ariard> jeremyrubin: or if you point is about the lack of punishment, not the pinning technique leveraged, we could re-introduce punishment on top of APO with https://github.com/LLFourn/witness-asymmetric-channel/blob/master/README.md i think
17:48 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Remote host closed the connection]
17:57 < jeremyrubin> it's worse because it's fully third party malleable
18:05 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 256 seconds]
18:16 -!- preemz [~preemz@73.58.92.183] has quit [Ping timeout: 272 seconds]
18:19 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
18:24 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev
18:24 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 272 seconds]
18:52 -!- rusty [~rusty@203.221.41.134] has joined #lightning-dev
19:43 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
19:59 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
20:06 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 276 seconds]
20:13 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
20:17 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
20:19 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
20:24 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Remote host closed the connection]
20:56 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
20:57 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...]
21:01 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 256 seconds]
21:19 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
21:23 -!- jtraub91 [~Jason@098-147-176-043.res.spectrum.com] has joined #lightning-dev
21:24 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 256 seconds]
21:25 -!- Netsplit *.net <-> *.split quits: shiza, BlueMatt[m]
21:25 -!- Netsplit over, joins: shiza
21:26 -!- Netsplit over, joins: BlueMatt[m]
21:26 -!- jtraub91 [~Jason@098-147-176-043.res.spectrum.com] has quit [Quit: WeeChat 3.2]
21:27 -!- jtraub91 [~Jason@098-147-176-043.res.spectrum.com] has joined #lightning-dev
21:27 -!- jtraub91 [~Jason@098-147-176-043.res.spectrum.com] has quit [Client Quit]
21:27 -!- jtraub91 [~Jason@098-147-176-043.res.spectrum.com] has joined #lightning-dev
21:28 -!- Netsplit *.net <-> *.split quits: vincenzopalazzo, b42, kalle
21:28 -!- Netsplit over, joins: kalle, b42
21:37 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
21:45 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #lightning-dev
21:55 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 246 seconds]
23:39 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev
23:46 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 246 seconds]
--- Log closed Mon May 02 00:00:11 2022