--- Log opened Fri Sep 18 00:00:22 2020 00:09 -!- jamesob [sid180710@gateway/web/irccloud.com/x-jkrjxdqaspqhedhy] has joined #rust-bitcoin 00:33 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 00:33 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 00:41 -!- jonatack [~jon@37.172.86.203] has joined #rust-bitcoin 00:49 -!- peter_ [~peter@185.114.3.24] has joined #rust-bitcoin 01:04 -!- jonatack [~jon@37.172.86.203] has quit [Ping timeout: 240 seconds] 01:05 -!- jonatack [~jon@213.152.161.133] has joined #rust-bitcoin 01:52 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-uzdanwwxmzmmiffd] has quit [Quit: killed] 01:53 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-uxmiuemqnuserojw] has quit [Quit: killed] 02:16 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-etwcygzgunvfvtct] has joined #rust-bitcoin 02:19 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-etwcygzgunvfvtct] has quit [Remote host closed the connection] 02:24 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-jgxqwluuixlqbevk] has joined #rust-bitcoin 02:43 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-gbvfwkusvwddsrdd] has joined #rust-bitcoin 02:52 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 02:57 -!- jonatack [~jon@213.152.161.133] has quit [Ping timeout: 240 seconds] 02:57 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 240 seconds] 02:59 -!- jonatack [~jon@37.172.86.203] has joined #rust-bitcoin 03:04 -!- jonatack [~jon@37.172.86.203] has quit [Read error: Connection reset by peer] 03:18 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #rust-bitcoin 03:22 -!- Favian7Konopelsk [~Favian7Ko@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin 05:45 -!- jonatack [~jon@37.172.22.3] has joined #rust-bitcoin 08:13 -!- jonatack [~jon@37.172.22.3] has quit [Read error: Connection reset by peer] 08:38 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 11:45 < BlueMatt> ariard: ha! you're gonna kill me. there are no channelmonitor/onchain-caused too-low-fee cases. there's a case in close-transaction generation and one in tests. 11:45 < BlueMatt> ariard: anyway, I have a patch to fix it. 12:12 -!- belcher_ is now known as belcher 13:17 < BlueMatt> ariard: anyway, I have a patch to fix it. 13:17 < BlueMatt> lol oops 13:27 < ariard> BlueMatt: in case of doubt just blame update_fee 13:28 < BlueMatt> lol, yea 13:29 < BlueMatt> but here I am bitching that we have 0-fee txn bugs, and most of them are in tests, and the remaining ones are my fault :shrug: 13:31 -!- Favian7Konopelsk [~Favian7Ko@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds] 13:36 < ariard> so sounds I don't introduce 0-fee txn bugs, only non-standard script one (I see you MINIMAL_IF) 13:36 < BlueMatt> right. 13:47 < BlueMatt> ariard: hmmm, actually i think one of these may be a bug. 13:47 < BlueMatt> can you take a look? 13:48 < ariard> BlueMatt: sure send it 13:49 < BlueMatt> ariard: https://github.com/TheBlueMatt/rust-lightning/commit/79cbf8794aca4e7e45067605891a654388854909 13:49 < BlueMatt> see-also commits before it. 13:49 < ariard> okay looking on it 13:52 < ariard> BlueMatt: just to get started a fee bug or a double-spend or whatelse you're seeing? 13:52 < BlueMatt> ariard: just where that NOTE is - afaict we dont generate *any* valid claim txn 13:53 < BlueMatt> they're all double-spends against sets of things that are confirmed. 13:56 < ariard> BlueMatt: I see it might not be a bug but just more a schedule rebroadcast and the broadcaster isn't dryup before the next block_connected 13:56 < ariard> let me check 13:57 < BlueMatt> hmm, you mean that it'll broadcast on the next block for an rbf bump? 13:57 < BlueMatt> I mean I'd still call that a bug. 13:57 < ariard> like block 128 13:57 < BlueMatt> hmm? 14:00 < ariard> testing my hypothesis 14:03 < BlueMatt> also take a look at the next block - checking the txn generated after block 130 - we're checking that we generate transactions which double-spend outputs already spent? 14:03 < ariard> okay sounds like a bug investigating logs 14:04 < BlueMatt> errr, sorry, just its broadcasting two txn to spend one output 14:05 < BlueMatt> errr, sorry no. 14:07 < BlueMatt> yea, ok first claim there is right - node_txn[0] and node_txn[1] *both* doubel-spend the inputs that revoked_htlc_txn[0-1] spend. 14:08 < ariard> I see the bug is we generate 2 justice txn, 1) spending HTLC A + revoked balance and 2) spending HTLC B + revoked balance 14:08 < ariard> are we saying the same thing? 14:09 < BlueMatt> hmm? wait i dont think so? 14:09 < BlueMatt> sec. 14:12 < BlueMatt> ariard: ok, look at the top three-ish commits https://github.com/TheBlueMatt/rust-lightning/commits/2020-09-no-rescan-tests 14:12 < BlueMatt> note "demo bogus-ness" noting the issue in the txn generated in block 129 14:13 < BlueMatt> then wip shows that we generate 4 transaction in the non-rescan case: tx 1 and 2 are just 1-in and double-spend the two htlc txn that are confirmed in block 129 (fine, whatever, they just arent useful) 14:14 < BlueMatt> then tx 2 has 3 inputs (great...), two spend the revoked htlc txn (great...), and one double-spends the revoked-htlc-txn (oh no, now we cant broadcast it) 14:14 < BlueMatt> the final tx is just our local commitment tx 14:14 < BlueMatt> but now we dont have a valid tx to broadcast! 14:16 < ariard> wait the bug is tx 2 14:16 < BlueMatt> tx[0] and tx[1] are broken, but thats fine, we broadcast a bunch of "alternative to the current state" txn, which those both are 14:16 < BlueMatt> tx[2] is fubar. 14:16 < ariard> "one double-spends the revoked-htlc-txn (oh no, now we cant broadcast it)" wait a revoked HTLC output? 14:16 < BlueMatt> oh fuck my loop is wrong! 14:17 < BlueMatt> ok fuck me. anyway, so question is only about block 130 14:17 < BlueMatt> loop was checking node_txn[0] not node_txn[2] :( 14:17 < BlueMatt> man i hate computers 14:17 < ariard> tx[0] and tx[1] that's okay as we are somehow scanning the transaction graph linearly, so we broadcast punishment step-by-step 14:17 < BlueMatt> right. 14:17 < ariard> yeah those kinds of days 14:17 < BlueMatt> i dont understand block 130, though 14:18 < BlueMatt> its trying to rbf-bump the alternate transactions which conflict with txn which were already confirmed? 14:18 < BlueMatt> i mean, no harm, really, but.... 14:18 < ariard> yes IIRC it's some kind of reorg-protection 14:18 < ariard> like try to bump until 6 blocks of confirmation 14:19 < ariard> we don't "unschedule" them 14:19 < ariard> until enough confirmation 14:19 < BlueMatt> right 14:19 < BlueMatt> yea, ok 14:19 < BlueMatt> just kinda funny to see. 14:19 < ariard> otherwise we need an intermediate state, "don't rebroadcast but withhold until competiting spend get enough confirmations" 14:20 < BlueMatt> right. 14:20 < BlueMatt> yea, ok. 14:20 < ariard> welcome in the wonderful world of automated security transactions 14:20 < ariard> just checking the test 14:21 < BlueMatt> yeah those kinds of days <- one of those kinds of years....... 14:21 < BlueMatt> or at least weeks. 14:21 < ariard> ahahah all bugs and security issues will be solved next year 14:21 < ariard> more or less 2 weeks 14:23 < ariard> okay as far as my understanding of test_bump_penalty_txn_on_revoked_htlcs logs, it sounds correct 14:23 < BlueMatt> yea, ok, i think its all right. 14:24 < ariard> we generate 5 transactions each with one input, though 0 and 1 are double-spend in same block, which I confess is a bit confused 14:24 < BlueMatt> it is, but whatever, they wont propagate 14:24 < BlueMatt> we "broadcast" a lot of double-spends 14:24 < BlueMatt> some of them we could probably not do, but some we likely need to do anyway 14:25 < ariard> there is the fee-bumped double-spends and those ones are lawful 14:25 < ariard> *there are 14:25 < ariard> and the child-in-same-block-but-parser-step-by-step cases 14:25 < BlueMatt> right, though some of them are double-spends against confirmed things 14:25 < BlueMatt> which, ..... 14:25 < ariard> also right 14:26 < ariard> it would be good to get ride of as that's some kind of implementation fingerprint 14:26 < ariard> but I think we're far away of caring about this 14:28 < BlueMatt> right, but there's 20 other ways to fingerprint, and you're hopefully using a "trusted" place to broadcast your transactions 14:28 < BlueMatt> either local full node or whatever 14:28 < BlueMatt> sooooo 14:29 < ariard> I was thinking it's a leak if you're using a swarm of servers to broadcast 14:30 < ariard> but privacy of light clients for tx-relay is already so poor... 14:30 < BlueMatt> right... 14:30 < ariard> I mean they only broadcast their transactions it's not even a thing... 16:10 < ariard> BlueMatt: I think SIGHASH_SINGLE is introducing another weakness with aggregation 17:13 -!- peter_ [~peter@185.114.3.24] has quit [Ping timeout: 272 seconds] 17:16 -!- fiatjaf [~fiatjaf@2804:7f2:2984:7344:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 272 seconds] 19:25 -!- fiatjaf [~fiatjaf@2804:7f2:2a85:2fc:ea40:f2ff:fe85:d2dc] has joined #rust-bitcoin 23:40 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 23:42 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] --- Log closed Sat Sep 19 00:00:22 2020