--- Log opened Wed Oct 14 00:00:46 2020 00:37 -!- jonatack [~jon@213.152.161.69] has quit [Ping timeout: 272 seconds] 00:49 -!- Troy14Johns [~Troy14Joh@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds] 01:18 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 260 seconds] 01:18 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #rust-bitcoin 01:19 -!- jonatack [~jon@37.170.11.107] has joined #rust-bitcoin 01:27 -!- jonatack [~jon@37.170.11.107] has quit [Ping timeout: 272 seconds] 01:28 -!- jonatack [~jon@213.152.162.94] has joined #rust-bitcoin 02:33 -!- ulrichard [~richi@212.71.103.20] has joined #rust-bitcoin 03:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 03:24 -!- jonatack [~jon@213.152.162.94] has quit [Ping timeout: 258 seconds] 04:11 -!- fiatjaf [~fiatjaf@2804:7f2:2a85:2fc:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 244 seconds] 04:24 -!- fiatjaf [~fiatjaf@2804:7f2:2985:c0dd:ea40:f2ff:fe85:d2dc] has joined #rust-bitcoin 05:04 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 05:08 -!- tibo_ [~tibo@2400:4050:2a83:7000:90ce:7f16:8f10:6018] has quit [Remote host closed the connection] 06:06 -!- fiatjaf [~fiatjaf@2804:7f2:2985:c0dd:ea40:f2ff:fe85:d2dc] has quit [Read error: Connection reset by peer] 06:11 < ariard> BlueMatt: I think #681 is pretty mature, you can have a look after coffee :) 06:29 < ariard> updated #653, AFAICT the buggy test was only there to prevent future wreckage of the no-canceling-bac-dust-HTLC-in-case-of-funding-utxo-spend 06:31 < andytoshi> stevenroose: https://github.com/rust-bitcoin/rust-bitcoin/pull/413 implements verifymessage for segwit p2wpkh addresses ... elichai2 points out that Core does not do thi 06:32 < andytoshi> and i think we shouldn't do it either, there is an effort to soft-deprecate verifymessage/signmessage because it involves pubkey recovery which is a sketchy/unloved part of libsecp 06:32 < andytoshi> if we have users who want verifymessage for segwit addresses, we should implement BIP322 (this may belong in rust-miniscript rather than rust-bitcoin) 06:34 < stevenroose> andytoshi: elichai2: pushed an extra commit that removed p2wpkh support 06:39 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 06:41 < andytoshi> nice thanks :) 06:42 < andytoshi> elichai can you ack the PR now, then we can get 0.25.1 out 06:42 < andytoshi> and then start merging all the 0.26.0 stuff 06:42 < andytoshi> stevenroose: can you ack https://github.com/rust-bitcoin/rust-bitcoin/pull/500 real quick 06:43 < stevenroose> checking 06:44 < stevenroose> merged 06:44 < andytoshi> dope 06:44 < andytoshi> also https://github.com/rust-bitcoin/rust-bitcoin/pull/498/ (this is nontrivial but barely, 32 new LOC) 06:45 < andytoshi> oh lol the commits don't compile 06:45 < andytoshi> dr-orlovsky: `git rebase -x 'cargo test && cargo +1.29.0 test' $(git merge-base master HEAD) HEAD` fails on your PR 498 06:46 < andytoshi> it's kinda a dumb failure, it's just some module lookup stuff in the tests module on 1.29 06:47 < dr-orlovsky> sure, will be able to fix in a few mins 06:53 < stevenroose> andytoshi: hmm, looked at it and I don't really see the point of that trait 06:55 < andytoshi> dr-orlovsky: what is the use-case for this trait? 06:56 < andytoshi> i don't mind having it but i also didn't really get it 06:59 < dr-orlovsky> functions instead of taking derivation path will be able to take different forms of arguments all of which may be converted into derivation path. The same like with `impl IntoIter` trait. For instance you will be able to give a string representation or a vec 06:59 < dr-orlovsky> andytoshi: squashed commits, checked tests and pushed. No need for multiple commits there 06:59 < andytoshi> ok, i can get behind that, but the PR should impl this trait for `String` 07:00 < dr-orlovsky> ok 07:00 < andytoshi> and yeah, i'm fine with squashing, it was a pretty small PR 07:00 < andytoshi> iirc we already have a FromStr impl so it should be easy to do in terms of this 07:03 < elichai2> andytoshi: done 07:04 < dr-orlovsky> andytoshi: done with an additional commit on top 07:09 < andytoshi> cool lgtm now 07:10 < andytoshi> dr-orlovsky: this doesn't compile with 1.29, you need an explicit lifetime param on &str 07:11 < dr-orlovsky> I see, doing 07:13 < dr-orlovsky> done + one more small test. Force-pushed last commit 07:16 < dr-orlovsky> stevenroose: also answered your question regarding blanket impl and concern about whether the trait is needed 07:33 < dr-orlovsky> andytoshi: https://github.com/rust-bitcoin/rust-bitcoin/pull/497 done 07:40 < andytoshi> dr-orlovsky: i think you should drop the space insensitivity and case insensitivity 07:41 < andytoshi> stevenroose: #413 needs to update unit tests 07:47 < dr-orlovsky> andytoshi: done as an additional commit on top 07:50 < stevenroose> dr-orlovsky: did you use that trait already in one of your projects? 07:50 < stevenroose> andytoshi: fixed, sorry 07:52 -!- evalr [~evalr@malta1854.startdedicated.net] has quit [Ping timeout: 240 seconds] 08:08 < andytoshi> lol thanks stevenroose. running tests locally then will re-ack. elichai2 also need a re-ack from you 08:10 < andytoshi> dr-orlovsky: when tests are done on #413 i'll run them on #497 and re-ack. stevenroose or elichai2, can you take a look at #497 08:11 < dr-orlovsky> ok. Seems like GitHub actions migration from Travis becomes a matter of saving yours and others time... 08:12 < andytoshi> hmm? 08:15 < stevenroose> andytoshi: I'm just not really convinced on IntoDerivationPath, even though it's locally and no other usage should probably matter. For sure I'd like confirmation that it's uberhaupt possible to implement it 08:15 < stevenroose> but then still I don't think it has any merit. We could do the exact same thing for all our types with the same motivation :| 08:17 < andytoshi> well for derivationpath specifically there's an argument that it's like std ToSocketAddrs 08:17 < andytoshi> in that it's very common for people to provide derivation paths in weird formats 08:17 < andytoshi> specifically as strings or as vectors of childnums 08:18 < elichai2> andytoshi: I don't really know the PSBT module, but if you say it's fine i'll ACK :) 08:18 < andytoshi> elichai2: heh it's just adding default serde impls to a bunch of stuff, how could it be wrong ;) 08:29 -!- ulrichard [~richi@212.71.103.20] has quit [Remote host closed the connection] 08:33 < andytoshi> lol fucking travis 08:54 < andytoshi> ok looks liketravis is going now 08:58 < BlueMatt> ariard: right, looking at the test there the test itself looks fine, the issue is it cheating to use null witnesses, which makes us test with invalid transactions. 08:58 < BlueMatt> ariard: ideally I think all of our tests should be connecting fully-valid blockchains. 09:05 < BlueMatt> ariard: sadly, we're a ton of work away from that - especially on matching-prevhash and matching-height. I did a bit of work to try to fix it but quickly gave up, not sure its really worth the time. 09:07 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 09:11 < ariard> BlueMatt: okay, your comment was "Can we just drop that test" ? do you prefer to keep it and instead fulfill the witness with junk ? 09:12 < ariard> note the purpose of this test was explictely passing blockchain-invalid transaction to avoid faulty canceling of dust HTLCs 09:12 < ariard> but if you're connecting wrong blocks, that's far more concerning than caring about your dust HTLC 09:13 < ariard> BlueMatt: I see it's 1) update test to ensure prevhash, height as you describe then 2) update ChannelMonitor::block_connected to enforce it 09:14 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 09:14 < ariard> I would say in-order blockchain instead of valid, which is a far more demanding scope, and ofc beyond our scope 09:16 < ariard> BlueMatt: I think that's a worthy goal at some-term to ensure in-order blockchain to catch logic bugs in your chain::Monitor/chain::Filter 09:16 < ariard> If users are not re-using the chain sample, that highly likely to have mistakes there 09:28 < BlueMatt> ariard: hmm, ok, I'm confused as to the purpose of the test, then? 09:28 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds] 09:28 < BlueMatt> why would we ever want to test invalid transactions (instead of, eg, asserting on specific cases) 09:29 < BlueMatt> ariard: yes, totally agree we should do it sometime and then assert chain connection is all in-order and such. 09:30 -!- jonatack [~jon@109.202.107.147] has joined #rust-bitcoin 09:32 < BlueMatt> ariard: i mean we have to draw our trust model somewhere, right? like, what was the specific issue we were concerned about when that test was added? 09:32 < ariard> BlueMatt: the purpose of the test was in case of buggy blokchain we don't cancel back dust-HTLCs 09:33 < BlueMatt> right, but, like, in case of buggy chain-connection an attacker can do much worse. 09:33 < ariard> I skimed over #333 but didn't find back the specific issue we were trying to mitigate 09:33 < ariard> Agree, I think this test was an oversight of mine 09:34 < BlueMatt> i mean I'm sure there was *some* reason for it :p 09:34 < ariard> like a nice-behavior-to-ensure when everything is already broken 09:34 < ariard> that's the reason, protecting your dust HTLCs in case of buggy blockchain :) 09:35 < BlueMatt> heh, ok, then I'd vote we drop it - buggy chain connection probably means bogus-channel-entirely wich is much worse (and harder to catch) 09:36 < ariard> BlueMatt: okay so I don't think it need to touch #653 further? 09:36 < ariard> *I think I don't need 09:37 < BlueMatt> ariard: ah! I hadnt realized you'd dropped that test. yes, ok, looks good. let me give it a once-over in a bit and I'll ack+merge. 09:37 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin 09:37 < BlueMatt> same with 681 09:38 < BlueMatt> ah, looks like jeff didn't ack 681, I'll wait for him to do so and then merge. 09:40 -!- rjected [~dan@pool-151-203-65-159.bstnma.fios.verizon.net] has joined #rust-bitcoin 09:43 < ariard> okay I think he is away for few days, but in the meanwhile we can make steps forward on other stuff 09:52 < BlueMatt> indeed. 10:05 < BlueMatt> ariard: for now I've been focusing on bindings, let me know if there's something i should be doing review-wise or such. I'm really happy with how this release is shaping up. 10:14 -!- vindard_ [~vindard@200.7.90.152] has joined #rust-bitcoin 10:16 < ariard> BlueMatt: just achieved a round on MPP, planning to review devrandom signer stuff then NOISE/PeerManager 10:17 < ariard> I'll provide test for #611, for #575 I'm tempted to call directly for a spec update as channel policy is something scrutined rn 10:17 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 256 seconds] 10:27 -!- vindard_ [~vindard@200.7.90.152] has quit [Ping timeout: 240 seconds] 10:27 < BlueMatt> ariard: the noise/peermanager stuff really needs a new champion - it needs some cleanups to reduce the OOP-complexity, and julian timed out. i think jeff had some willingness to take it on, or you're welcome to. 10:28 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin 10:28 < BlueMatt> ariard: another thing worth doing would be to use the chaincode sym data to figure out historical mempool min-fee values - thats needed to make the spec changes upstream which would help us imensely 10:29 < BlueMatt> and I keep not getting around to it :( 12:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 12:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 12:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 12:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 12:22 -!- belcher_ is now known as belcher 14:13 < andytoshi> stevenroose: can you quickly ack https://github.com/rust-bitcoin/bitcoin_hashes/pull/99 14:13 < andytoshi> we can get this into the next minor rev of bitcoin_hashes 14:16 < stevenroose> andytoshi: acked, what's the exact use case for that 14:16 < stevenroose> didn't think too much about those requirements 14:20 < andytoshi> the usecase is implementing that trait 14:20 < andytoshi> which should involve writing the engine() method 14:20 < andytoshi> but currently requires also #deriving like 8 unrelated things for no reason 14:21 < andytoshi> it's more about confusing than anything else 14:21 < andytoshi> i tried to create a tagged hash for bip322 and got errors because my tag dummy type wasn't orderable ... i had to dig into the bitcoin_hashes source to figure out why that was a requirement 14:30 < andytoshi> oops failed CI 14:30 < andytoshi> one sec i have to fix a couple serde things 14:32 < andytoshi> ok should work now 15:05 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-anszanoxiedqhnvw] has quit [Ping timeout: 272 seconds] 15:06 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-kgbadmxzqqlezakb] has joined #rust-bitcoin 16:15 -!- tibo [~tibo@2400:4050:2a83:7000:957:2fca:5ec:6792] has joined #rust-bitcoin 17:00 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 17:05 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 17:08 < ariard> BlueMatt: hmmmmm, I know the noise/peermanager needs someone to push it, I'll coordinate with jeff on this, I really want to push for the sample node 17:12 < ariard> I know for the mempool min-fee, but I prefer to keep pushing for Core tx-relay changes, which IMO is the real long-term fix 17:12 < ariard> BlueMatt: I'll have a look on it, it's maybe super easy to figure out but I don't guarantee to deliver :) 17:38 < BlueMatt> ariard: it should be pretty easy to calculate, I think, you'd have to chat with suhas, though, as i have no idea how that code works. 17:39 < BlueMatt> ariard: as for sample node, yep! totally agree, definitely the highest priority, but immediate-term I'm not sure how much more parllelizable the work is - val has the on-disk stuff moving forward (though maybe chat with her about automating channel{,manager} on-disk storage as well?) and jeff's working on taking over 614 to provide an easy way to fetch the chain. I'd have to go look at -bitcoinrpc again, but iirc those were basically the 17:39 < BlueMatt> only two big piles of code. 17:45 < BlueMatt> ariard: one comment, but looks good otherwise. 17:45 < ariard> BlueMatt: one thing we need to draw clearly with the sample node is being sure that stay a sample node 17:45 < BlueMatt> eh, actually, I dont care about that comment 17:45 < ariard> because I expect people to reuse it and start to send patch downstream 17:46 < ariard> and we want to avoid to have to maintain a full-fledged node 17:46 < ariard> otherwise when persistence and 614 are ready it's just a matter how fitting the pieces together, easier said than done tho 17:47 < BlueMatt> hmm, maybe? I mean I think in general the "break it into pieces which become subcrates" model implies that those subcrates are production-ready, and then the "sample node" is just a few 10s of lines of code and it doesnt matter much. 17:47 < BlueMatt> right, I think the persistence stuff and 614 we should gear towards assuming people will use them in production, and they should be high enough quality that we're ok with that. 17:47 < ariard> yeah but then someone will start to open PR to change the color of the RPC, you know 17:48 < ariard> like people will hack with the glue code tightening together the sample 17:48 < BlueMatt> right, sure, the app built on top we should definitely just have a ton of comments talking about how this is a sample 17:50 < BlueMatt> ariard: in other news, in case you're curious, java bindings are starting to be human-readable: https://github.com/TheBlueMatt/ldk-java/blob/master/src/test/java/org/ldk/HumanObjectPeerTest.java 17:50 < BlueMatt> there's still a bunch of manual-free, but its getting closer every day. 17:50 < ariard> lol I done java one afternoon in my life, that was enough :p 17:50 < BlueMatt> i dont blame you :( 17:50 < ariard> but glad you're hacking this forward 17:51 < ariard> I'm catching on the upfront payment dicussion, how we're going to solve this as a lot of dependencies with a bunch of topics 17:51 < ariard> like watchtowers, minimal price of commitment transactions, long-term held HTLCs 17:54 < BlueMatt> (trying to shove "rust has, like, ownership, and clear models of objects" into "java lulz everything is a shared_ptr, lol, good luck, there's a billion references to everything" is, uhhhh, hard) 17:55 < BlueMatt> cool! happy you're keeping up with the spec. I just really haven't had time :( 17:55 * BlueMatt -> bbl 18:03 < ariard> lol I would like to help you ensuring your pointers passthroughs are memory-consistent across languages boundaries but I'm not that much of a language hacker... 18:05 -!- fiatjaf [~fiatjaf@2804:7f2:2a84:12c:ea40:f2ff:fe85:d2dc] has joined #rust-bitcoin 18:29 < BlueMatt> ariard: dont worry, I've got addrsanitizer and a custom memory-leak detector all hooked up :) 18:30 < BlueMatt> it wouldnt be my work unless there's a bunch of needlessly-complicated test infrastructure :) 18:34 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 19:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 22:56 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 22:57 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin --- Log closed Thu Oct 15 00:00:47 2020