--- 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