--- Log opened Tue May 11 00:00:51 2021 00:28 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 260 seconds] 00:28 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 00:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin 01:01 < sgeisler> Thomas[m]4: Asked myseelf the same, but probably because we don't want to depend on core2 by default, either because MSRV or to not add an untrusted dependency 01:03 < sgeisler> core2 does not seem stable at all, the only real release is 0.3.0-alpha.1 01:58 -!- belcher_ is now known as belcher 02:00 -!- fast1[m] [fast1priva@gateway/shell/matrix.org/x-frptzlxjthnaaomf] has quit [Quit: Idle for 30+ days] 02:08 < Thomas[m]4> Right, that makes sense but also makes things quite a bit more complicated :/ 02:08 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #rust-bitcoin 04:04 < dr-orlovsky> apoelstra: seems we are good to go with 0.26.1 finally! Just need review from you on trivial #559 (error derives) and merge of already reviewed #509 04:05 < dr-orlovsky> you can also grab new CONTRIBUTING from #587 which passed multiple reviews so far if you'd like to get it into minor version (not necessary though) 04:07 < dr-orlovsky> if you do not have a time, I can help you composing CHANGELOG. With our consistent use of GitHub milestones it is got easier: https://github.com/rust-bitcoin/rust-bitcoin/milestone/11?closed=1 04:18 < dr-orlovsky> (seems you are right that #509 is probably breaking, so we can re-lable and re-purpose it for 1.27.0) 04:18 -!- Nigel83Wiza [~Nigel83Wi@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin 05:33 -!- tibo [~tibo@2400:4050:2a83:7000:5128:d9d1:982c:43a2] has quit [Remote host closed the connection] 05:47 -!- Blackwolfsa4 [~Blackwolf@195.159.29.126] has joined #rust-bitcoin 07:35 < BlueMatt> ariard: hey, I'd kinda like to build a "tx that was locktime'd rebroadcast when its broadcastable" thing, but probably need to land 642 first. any update on that? 07:53 < ariard> BlueMatt: yep addressed all your comments 20min ago :) rebasing on master rn 07:53 < ariard> removed the inputdescriptors they're not really useful 07:54 < BlueMatt> sounds good, thanks 07:55 < BlueMatt> ariard: also, if we add a csv delay on htlc-timeout transactions doesn't that "fix" flood-and-loot? or at least make it much harder. 07:55 -!- Nigel83Wiza [~Nigel83Wi@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 260 seconds] 08:09 < ariard> BlueMatt: iirc it was advocated as a mitigation in the paper, but does it really prevent an attacker to target second-stage tx? 08:09 < ariard> it should prevent exploitation of your commiment transaction at least 08:09 < ariard> but for HTLC transactions, evne if you assume to sort them by range of csv delay based on some expectation of mmepool size 08:10 < ariard> you can still target HTLCs in the same range? 08:10 < BlueMatt> ariard: it doesnt, but it solves part of the issue, at least. you could theoretically go one further and add a csv+preimage claim output on an htlc-timeout tx, making the attacker-defender relationship completely symmetric 08:12 < BlueMatt> the issue really is that the attacker needs to get less into the blockchain to start the attack clock than the defender needs to get into the chain before the attack clock 08:12 < BlueMatt> if you make those numbers symmetric the attack "doesnt work" 08:12 < ariard> BlueMatt: BlueMatt: hmmmm but htlc-timeout tx are the victims one here, why adding a preimage output on it incentivizes attacker to not target them? 08:14 < ariard> i see, so you will somehow linearize the htlc-timeout claiming path on the preimage one 08:15 < BlueMatt> right, its not practical in the sense that you add an extra on-chain tx to the htlc-timeout path (to "finalize" it) 08:15 < BlueMatt> but i also wanted to check my mental model around "making the attacker and defender pay the same tx weight" 08:16 < BlueMatt> I *think* if you add a csv and then make the attacker pay the same weight to start the attack as the defender to defend, then the attack largely goes away 08:16 < BlueMatt> not completely, its still a race, but in the theoretical sense it does 08:17 < ariard> BlueMatt: it doesn't fit the flood&loot attack, where you flood the mempool to swallow the routing hub's cltv_delta 08:18 < BlueMatt> yes it does? you flood the mempool, but then in order to "claim your reward" you still have to get the same amount of data onto the chain as the defender, and you give the defender time post-confirmation. 08:18 < BlueMatt> so instead of flooding the mempool to get infinite defenders who compete with each other, you make the attacker compete at the same time 08:20 < ariard> right, so what's you're trying to achieve is give a chance to the defender to claim back the incoming HTLC on top of the malicious's counterparty HTLC-timeout 08:20 < ariard> like on the backward link, not the forward one 08:20 < ariard> but it still assumes the other maliciosu counterparty did reveal the preimage forward? otherwise you're still stuck 08:20 < BlueMatt> right 08:21 < BlueMatt> hmm? 08:21 < ariard> and the attacker or collusion of it need to reveal the preimage 08:21 < ariard> *them 08:21 < BlueMatt> if the malicious counterparty didnt reveal the preimage on the forward link, then you are trying to time out the htlc like anything else? 08:22 < BlueMatt> you still have time to time it out, and you're completely symmetric with the backwards link broadcating their own time out 08:22 < ariard> i think on the claim paying the same tx weight, it's already the case, at least post-anchor 08:22 < BlueMatt> again, you have attacker + defender broadcasting the same amount of data 08:23 < ariard> not even sure about the same amount of data, what if you trick the defender's broadcasting logic to aggregate HTLC on the forward link? 08:24 < BlueMatt> vs with just a csv on the htlc-timeout transaction the attacker only has to broadcast the commitment tx, and the defender has to broadcast potentially many htlc-success txn 08:24 < BlueMatt> if the forward link gets htlc-success aggregation, then the backwards link can too? 08:25 < BlueMatt> or you mean the attacker aggregates then the defender has to broadcast commitment + a series of htlc-success? 08:25 < ariard> but you still assume the preimage is revealed on the forward link before htlc-timeout csv's new redeem path? 08:25 < BlueMatt> yea, that's an interesting point 08:25 < BlueMatt> right, this *probably implies doubling the cltv delta on most nodes 08:26 < BlueMatt> as now you need cltv + csv 08:27 < ariard> at least, we should assume the defender is broadcasting the commitment, so easy to force it with a low-value, looped HTLC 08:27 < ariard> doubling cltv + csv is likely going to be needed for eltoo.. 08:28 < BlueMatt> it is interesting, though, basically you can trivially "solve" it by just requiring certain transactions be padded to make the weight equal 08:28 < ariard> i don't assume the attacker aggregate, at the contrary, to break the weight asymmetry attacker broadcast single htlc-success? 08:29 < BlueMatt> hmm? if the attacker has to broadcast more then we've won 08:30 < ariard> well if we stay in the flood&loot framework, the attacker win if it steal one of the HTLC among the many congestioning htlc-timeout? 08:30 < ariard> and it doesn't have to broadcast htlc-success for the HTLC outputs which are only congestion junks? 08:31 < ariard> though i agree we should aim for weight symmetry, at least to make the scortched earth approach holding 08:31 < BlueMatt> right, its always a race, but at least if you make the attacker broadcast more than they have to put much more effort into winning the race 08:31 < BlueMatt> and "in theory" they dont win 08:31 < BlueMatt> if the attacker doesn't broadcast *any* lightning transactions they cant break things? 08:31 < ariard> yes, or 50-50 08:32 < BlueMatt> they always have to broadcast some lightning transactions, so you make the attacker's broadcast more expensive and you win 08:32 < BlueMatt> or at least make it equal 08:32 < ariard> the attacker broadcast the htlc-success for the HTLC he really wants to steal 08:32 < ariard> make it equal would be already a win 08:33 < ariard> but you have to solve first that the defender don't broadcast a commiment transaction lured by the counterparty 08:33 < BlueMatt> right, then the defender just has to broadcast the htlc-success going backwards for the htlc they dont want to lose 08:33 < BlueMatt> as long as its symmetric it should be mostly ok 08:33 < BlueMatt> its ok if the defender broadcasts a commitment transaction! 08:33 < ariard> right, ideally you break aggregation if timelock expiration is coming soon 08:33 < BlueMatt> as long as the csv is *after* that 08:33 < BlueMatt> doesnt matter 08:34 < ariard> like your broascast logic start to disaggregate if expiration is soon 08:34 < ariard> but broadcasting the commitment breaks the weight symmetry if we assume a future almost-zero-fee commitment transaciton? 08:35 < BlueMatt> the weight symmetry only applies on the thing that's actually a race 08:35 < BlueMatt> with csv the commitment transaction wouldn't be a part of the race 08:35 < BlueMatt> the commitment transaction only matters because its only cltv 08:35 < ariard> right, this holds post-anchor 08:37 < ariard> okay i think your weight symmetry holds if you assume the rebroadcast logic fallback in a disaggregate mode if HTLC timer is near-to-expiration 08:37 < ariard> that way broadcasting the most-minimal HTLC claiming tx, and an attacker can't do better 08:38 < BlueMatt> right. 08:38 < BlueMatt> just need it to be symmetric on the parts that are a race, which right now is everything, but with csv could be just the htlc txn 08:45 < ariard> easier to do with taproot, with well-isolated leafs? rn you're more likely to inflate a bit htlc offered witnessScript with new path? 08:46 < ariard> even in non-cooperative but non-adverserial scenarios 08:54 < BlueMatt> probably, yea 09:03 < ariard> BlueMatt: pushed the new version of #642 09:03 < ariard> okay finally motivating me to review #851 :) 09:04 < BlueMatt> cool! 10:33 < ariard> BlueMatt: iiuc bug-fix on #851 is about we receive a HTLC failure that we should pass backward, monitor update fails for a X reason, we restore the monitor and are still connected to peer, but effectively we never pass backward this HTLC failure? 10:33 < ariard> and beyond it's mostly merging code-paths, drying up errors more fix coverage? 10:37 < BlueMatt> yes 11:00 -!- kiltzman [~k1ltzman@195.189.99.96] has quit [Ping timeout: 252 seconds] 11:05 -!- kiltzman [~k1ltzman@195.189.99.96] has joined #rust-bitcoin 13:04 -!- _0x0ff- [~potatoe@2001:bc8:47b0:123::1] has joined #rust-bitcoin 13:04 -!- _0x0ff [~potatoe@unaffiliated/0x0ff/x-1210984] has quit [Ping timeout: 245 seconds] 13:09 -!- Netsplit *.net <-> *.split quits: _zkao, jakesyl, sgeisler, Galvas 13:13 -!- Netsplit over, joins: jakesyl, Galvas, _zkao, sgeisler 13:17 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-ffhuimjqrifccnpa] has quit [Ping timeout: 245 seconds] 13:17 -!- h4sh3d[m] [h4sh3dmatr@gateway/shell/matrix.org/x-hvrtqvzoekaoqwxa] has quit [Ping timeout: 258 seconds] 13:17 -!- Thomas[m]4 [thomaseizi@gateway/shell/matrix.org/x-hxsnytpylsvpqrsh] has quit [Ping timeout: 245 seconds] 13:17 -!- rcasatta[m] [rcasattama@gateway/shell/matrix.org/x-msodekmefqnxkwxi] has quit [Ping timeout: 247 seconds] 13:18 -!- _zkao [zkaomatrix@gateway/shell/matrix.org/x-bkkuwhqeqorofpsw] has quit [Ping timeout: 276 seconds] 13:41 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-hsipnhrsqvwbheyo] has joined #rust-bitcoin 13:46 -!- Thomas[m]4 [thomaseizi@gateway/shell/matrix.org/x-vqvfzbpyoyxeqrfc] has joined #rust-bitcoin 13:47 -!- h4sh3d[m] [h4sh3dmatr@gateway/shell/matrix.org/x-rokjwpxtvxzcvlof] has joined #rust-bitcoin 13:50 -!- rcasatta[m] [rcasattama@gateway/shell/matrix.org/x-kattwldjznbsgyef] has joined #rust-bitcoin 14:02 -!- rcasatta[m] [rcasattama@gateway/shell/matrix.org/x-kattwldjznbsgyef] has quit [Ping timeout: 245 seconds] 14:02 -!- h4sh3d[m] [h4sh3dmatr@gateway/shell/matrix.org/x-rokjwpxtvxzcvlof] has quit [Ping timeout: 245 seconds] 14:03 -!- Thomas[m]4 [thomaseizi@gateway/shell/matrix.org/x-vqvfzbpyoyxeqrfc] has quit [Ping timeout: 258 seconds] 14:03 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-hsipnhrsqvwbheyo] has quit [Ping timeout: 258 seconds] 14:16 -!- _zkao [zkaomatrix@gateway/shell/matrix.org/x-yzlnygmqppbvapga] has joined #rust-bitcoin 14:28 -!- h4sh3d[m] [h4sh3dmatr@gateway/shell/matrix.org/x-nobgmzafrrohffdq] has joined #rust-bitcoin 14:28 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-viqzixvzipkwvstl] has joined #rust-bitcoin 14:31 -!- Thomas[m]4 [thomaseizi@gateway/shell/matrix.org/x-xppbdcblfqtgukuu] has joined #rust-bitcoin 14:33 -!- rcasatta[m] [rcasattama@gateway/shell/matrix.org/x-syrlootjlefrgvny] has joined #rust-bitcoin 15:26 -!- willcl_ark_ [~quassel@unaffiliated/willcl-ark/x-8282106] has quit [Remote host closed the connection] 15:28 -!- willcl_ark [~quassel@unaffiliated/willcl-ark/x-8282106] has joined #rust-bitcoin 16:41 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 16:42 -!- shesek [~shesek@164.90.217.137] has joined #rust-bitcoin 16:42 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 16:42 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin 17:32 -!- tibo [~tibo@2400:4050:2a83:7000:8453:167f:201c:108b] has joined #rust-bitcoin 17:34 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 17:53 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 18:26 -!- stevenroose [~steven@irc.roose.io] has quit [Ping timeout: 245 seconds] 18:32 -!- stevenroose [~steven@2001:19f0:6801:83a:1c0:dd39:fc42:8677] has joined #rust-bitcoin 20:38 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 20:41 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 22:49 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 23:08 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #rust-bitcoin --- Log closed Wed May 12 00:00:52 2021