--- Log opened Fri Sep 11 00:00:15 2020
00:28 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
00:31 -!- Kiminuo [~mix@193.9.112.252] has joined #rust-bitcoin
00:32 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
01:34 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds]
01:50 < cloudhead> BlueMatt: andytoshi: the problem I see with pow_limit being an unrepresentable value in compact form is when you need to validate min-difficulty blocks in the testnet, you can't do header.validate_pow(params.pow_limit)
01:50 < cloudhead> even though that seems like the natural thing to do
01:50 < cloudhead> but you will get a false negative in that case
01:52 < cloudhead> it also comes about if hitting the difficulty floor on mainnet (though I guess that hasn't actually happened in practice), because there you will basically cap the difficulty to pow_limit, and then header.validate_pow() using that value
01:52 < cloudhead> and again, that will give you a false negative
01:56 < cloudhead> so really I'm not sure where pow_limit can be useful for users of the api, except maybe comparing it to another value, but this is where you are likely to commit the error of doing `if target > pow_limit { target = pow_limit }` which is really hard to debug
02:00 < cloudhead> you can definitely get around if you know what you're doing (eg. https://github.com/cloudhead/nakamoto/blob/master/chain/src/block/cache.rs#L307-L310) but I have to admit it threw me for a loop
02:49 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined #rust-bitcoin
02:50 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
02:50 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
03:11 -!- Netsplit *.net <-> *.split quits: junderw, prusnak
03:16 -!- prusnak [sid403625@gateway/web/irccloud.com/session] has joined #rust-bitcoin
03:16 -!- junderw [sid43070@gateway/web/irccloud.com/session] has joined #rust-bitcoin
03:17 -!- prusnak [sid403625@gateway/web/irccloud.com/session] has quit [Changing host]
03:17 -!- prusnak [sid403625@gateway/web/irccloud.com/x-nficguliffcrpcdy] has joined #rust-bitcoin
03:17 -!- junderw [sid43070@gateway/web/irccloud.com/session] has quit [Changing host]
03:17 -!- junderw [sid43070@gateway/web/irccloud.com/x-otmivaodxntnfmqu] has joined #rust-bitcoin
03:17 -!- prusnak is now known as Guest39002
04:35 < andytoshi> cloudhead: IIRC the first 100k blocks or so hit the difficulty floor in mainnet
04:36 < andytoshi> and i was able to validate the chain some years ago, without running into this confusion ... but i don't remember exactly what i did. i think i just took the genesis difficulty for granted
04:39 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 240 seconds]
04:47 < elichai2> nightly is fixed :) https://travis-ci.org/github/rust-bitcoin/rust-bitcoin/jobs/726241878
04:51 < cloudhead> andytoshi: that's right, I think that may be a better way than using pow_limit (how it was originally defined)
04:51 < cloudhead> but then not sure it needs to be exposed at all
04:56 < andytoshi> heh, yeah, i'm not sure where that constant came from. i don't think i exposed it
04:57 < andytoshi> lol dr-orlovsky i merged https://github.com/rust-bitcoin/rust-bitcoin/pull/387/files
04:57 < andytoshi> but
04:57 < andytoshi> how are users supposed to obtain e.g. a WPubkeyHash
04:57 < andytoshi> it looks like we defined that hashtype but never actually defined any constructors for it?
05:03 < andytoshi> in your unit tests you have code like         let wpubkey_hash = WPubkeyHash::hash(&pubkey.serialize());
05:04 < andytoshi> but we shouldn't encourage users to do this because it fails to check compressedness of `pubkey`
05:06 < darosior> andytoshi: currently adapting rust-miniscript to new rust-bitcoin API (mainly Address::[segwit type]::script_pubkey which now returns a result), do you want to bump rust-bitcoin to 0.24 or 0.25 in miniscript ?
05:07 < andytoshi> darosior: 0.24
05:07 < andytoshi> i'm doing the same thing .. how far along are you?
05:07 < darosior> Argh i finished the Address part
05:07 < darosior> Not started the Script iteration one, you ?
05:08 < darosior> https://github.com/darosior/rust-miniscript/commit/064e6521c34d96d0a951589f4fa5cd0b102648a7
05:08 < andytoshi> heh kk i'll let you finish
05:09 < andytoshi> i'm a bit further ahead but not much
05:09 < andytoshi> and i'd rather have your code + my review than the other way around :shrug:
05:09 < darosior> Ok
05:09 < darosior> Did you go for changing our API to Result<> too ?
05:10 < andytoshi> oh no
05:10 < andytoshi> it shouldn't be possible to construct descriptors with uncompressed pubkeys in them
05:11 < andytoshi> or rather, it shouldn't be possible to deserialize such descriptors
05:11 < andytoshi> you can manually construct one but you're asking for trouble if you do that
05:11 < andytoshi> so my code just panics
05:11 < darosior> Ah that's simpler then
05:11 < darosior> But we accept (and even test that we accept uncompressed pubkeys in descriptors)
05:11 < darosior> At creation i mean
05:11 < darosior> So i assumed there was a reason
05:12 < andytoshi> ?? we should never accept uncompressed pubkeys in segwit descriptors
05:13 < darosior> the parse_descriptor() test
05:13 < darosior> In descriptor/mod.rs
05:13 < darosior> Ok nvm
05:13 < andytoshi> :P
05:13 < darosior> i misread
05:13 < darosior> :)
05:13 < andytoshi> half of those .unwrap()s are .unwrap_err()s
05:13 < andytoshi> :)
05:14 < andytoshi> so ... fwiw i just finished my version of the code. i could PR or let you finish if you'd lie
05:14 < darosior> I don't mind
05:14 < andytoshi> if you want to get the commit credit :P
05:14 < darosior> No go ahead, i just want to rebase my cleanup of sgeisler's xpub desriptors :)
05:14 < andytoshi> kk https://github.com/rust-bitcoin/rust-miniscript/pull/130
05:19 < darosior> Yay, now DescriptorPublicKey is almost ready :)
05:19 < darosior> By the way, do you think we should handle descriptor origin with non-xpub pubkeys ?
05:20 < andytoshi> nice
05:20 < andytoshi> what would descriptor origin look like in that case?
05:21 < darosior> Something like wpkh([ea676a8d/0'/0'/0']0231c7d3fc85c148717848033ce276ae2b464a4e2c367ed33886cc428b8af48ff8)#4pczzayw
05:22 < darosior> Actually i tested with core and noticed the diff
05:22 < darosior> Also, no checksum
05:24 < andytoshi> oh i see, you still have a bip32 path but you don't give an xpub
05:25 < andytoshi> yeah we should support that, if the user can get away without exposing the chaincode, we should enable that
05:25 < andytoshi> also right lol i forgot that Core has that checksum
05:28 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin
05:55 < dr-orlovsky> andytoshi: looking asap into the issue with https://github.com/rust-bitcoin/rust-bitcoin/pull/387/files
05:59 < dr-orlovsky> I think the whole idea of having `hash` function for hash types is flawed: they have to be created via constructors, not via hashing arbitrary data...
06:01 < dr-orlovsky> right now hash functions comes as a part of "ancestry" of Hash trait implementation with hash_newtype macro, and I think we do not need to have it implemented for hash types
06:03 < dr-orlovsky> As for constructors, they are ready to be merged with https://github.com/rust-bitcoin/rust-bitcoin/pull/388/files
06:11 < dr-orlovsky> Have re-based it and force-pushed (your review got cancelled b/c of that, so we need two reviews again for marging)
06:14 < dr-orlovsky> Btw, with my work on bitcoin_num https://github.com/rust-bitcoin/bitcoin_hashes/pull/91 it will be much simpler to remove Hash trait impls from hash new types, since we will have useful functions like into/from/as_inner implemented with InnerHex, not Hash trait
06:44 < dr-orlovsky> also added commit with WPubkeyHash constructor that fails on uncompressed pubkeys: https://github.com/rust-bitcoin/rust-bitcoin/pull/388
06:44 < dr-orlovsky> sorry, the commit is here: https://github.com/rust-bitcoin/rust-bitcoin/pull/388/commits/ff1b4a8dbd64e1c61378bcacf7abc4c8ef1a98ae
07:06 -!- reallll [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
07:07 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
07:29 -!- nothingmuch [~nothingmu@unaffiliated/nothingmuch] has joined #rust-bitcoin
07:48 < ariard> BlueMatt: updated 633 post cbinding merge, look on last commit, I tried to move match bindings as near from new nomenclature, but not sure if this wasn't automatically generated
07:49 < BlueMatt> ariard: cool, will look post-coffee. note that the bindings never auto-generate, you have to run genbindings.sh to do so (that way we always have them in git).
07:50 < BlueMatt> (though most of genbindings is actually testing them, like the first 2 lines generate the actual bindings)
07:57 < BlueMatt> ariard: note that github ci checks (but does not enforce) that the bindings in git match what it generates, and will give you a (nearly useless) git diff if it fails.
07:59 < ariard> BlueMatt: okay maybe I should have run genbindings.sh, I think naming leak higher, for e.g, you need to rename LDKLocalCommitmentTransaction
08:01 < ariard> effectively check_bindings failed
08:17 < BlueMatt> ariard: thats fine. thats why its set to not cause build to not pass :)
08:17 < BlueMatt> ariard: for now, I think best if folks just dont touch the bindings in prs and I can do update-bindings prs afterwards
08:18 < BlueMatt> (unless genbindings.sh passes and you want to, though)
08:21 < ariard> BlueMatt: okay or document update-bindings in CONTRIBUTING.md, I think it's loosely said in cbindings README.md but would be better to have this in top tree
08:22 < BlueMatt> agreed! will do.
08:29 < ariard> BlueMatt: BlueMatt: hmmm how does codecov.io parsing is working? I see a bunch of what appears as false positives on PRs
08:29 < ariard> notably #684
08:33 < BlueMatt> honestly? I dont know...its basically C parsing applied to rust (based on the debug symbols in the binary)
08:34 < BlueMatt> note that its only applied to cargo test things not fuzzing or so.
08:34 < BlueMatt> its also possible that the -O1 we do on tests is confusing it, maybe we can try turning -O1 off in codecov?
08:38 < ariard> you mean optimization stripping too much binary symbols and thus failing parsing, maybe...
08:38 < BlueMatt> yea, optimization can do all kinds of interesting things to debug symbol accuracy
08:39 < BlueMatt> ariard: am I missing anything in this reasoning? the reason we didnt turn off update_fee in anchor was so that the non-broadcaster could still broadcast things (eg htlc txn) since they probably have a reasonable fee, but as we learned, because its hard/impossible to monitor the mempool, thats not really practical anyway. thus, the only downside to removing update_fee for anchor would be increase in broadcaster fee costs
10:12 < ariard> BlueMatt: correct, but the downside is actually an upside for the channel funder as you don't pay anymore for your counterparty's HTLCs broadcast
10:13 < ariard> it's more a fair advance in distributing the fees according to whom gauge it's time to go onchain
10:14 < ariard> apart of dual-funding, I think we should remove all negotiated fees in the long term
10:14 < ariard> (around just digging in MPP to see if gleb's algorithm makes sense)
10:56 < BlueMatt> ariard: right, i presume the reason folks didnt want to do that is a pure-cpfp model *does* imply more in fees.
10:56 < BlueMatt> but i think inevitably we'll end up there eventually.
11:18 < ariard> BlueMatt: a) the difference cost of pure-cfpfp compare to bring-your-own-fees malleable HTLC is really low (nVersion, nLocktime, I/O index) b) assuming long-term high-rate of cooperative close, it won't serve in practice c) you will always pick the most-suiting user's feerate
11:18 < ariard> BlueMatt: I think there is a general concern of wasting blockspace for nothing, but in fact it's likely cpfp/byof will cost less in fees to the average user
11:18 < BlueMatt> ariard: sorry, i meant in comparison to update_fee.
11:18 < ariard> and your blockspace demand is lawful as long as you pay for
11:18 < BlueMatt> byo fees is different
11:20 < ariard> "a pure-cpfp model does imply more in fees" that's where I'm differing, if your party is offline and mempool fluctuates it can be as much in your favor or defavor
11:21 < ariard> BlueMatt: if your negotiated and pre-signed feerate is above the 4M block feerate, you're loosing money
11:22 < BlueMatt> right, sure, i guess i meant only blockspace
11:22 < BlueMatt> but thats a good point re: fees
11:22 < BlueMatt> which is ultimately what we should care about
11:31 < BlueMatt> ariard: there's still a ton of references to broadcaster_revocation_key.
11:31 < BlueMatt> ariard: when you update things, git grep is your friend?
11:31 < BlueMatt> :)
12:33 -!- reallll is now known as belcher
14:56 -!- devcarrot [~devcarrot@pike.ops.ski] has quit [Ping timeout: 256 seconds]
15:00 -!- devcarrot [~devcarrot@pike.ops.ski] has joined #rust-bitcoin
18:24 < ariard> BlueMatt: ah that's smart will fix
19:38 < BlueMatt> ariard: ugh, and now honggfuzz upstream broke our ci :(
19:38 < BlueMatt> ariard: will review tomorrow! hopefully we can land some things :)
22:30 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:31 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
23:38 -!- yancy [~root@li1543-67.members.linode.com] has quit [Quit: WeeChat 2.9-dev]
--- Log closed Sat Sep 12 00:00:16 2020