--- Log opened Thu Mar 18 00:00:59 2021 02:02 -!- gnusha [~gnusha@unaffiliated/kanzure/bot/gnusha] has quit [Ping timeout: 264 seconds] 02:02 -!- gnusha [~gnusha@unaffiliated/kanzure/bot/gnusha] has joined #rust-bitcoin 02:02 -!- Topic for #rust-bitcoin: Discussion of rust-bitcoin, rust-lightning and related crates | For rust-miniscript see ##miniscript | For general bitcoin discussion #bitcoin | Channel logs at http://gnusha.org/rust-bitcoin/ 02:02 -!- Topic set by andytoshi [~apoelstra@unaffiliated/andytoshi] [Tue Jan 12 15:46:09 2021] 02:02 [Users #rust-bitcoin] 02:02 [ andytoshi ] [ kallewoof ] 02:02 [ ariard ] [ kanzure ] 02:02 [ b10c ] [ kcalvinalvin ] 02:02 [ belcher_ ] [ kiltzman ] 02:02 [ BlueMatt ] [ michaelfolkson] 02:02 [ cloudhead ] [ midnight ] 02:02 [ CubicEarth ] [ moneyball ] 02:02 [ darosior ] [ mycroft ] 02:02 [ DeanGuss ] [ nickler ] 02:02 [ dongcarl ] [ nothingmuch ] 02:02 [ dr-orlovsky ] [ notmandatory ] 02:02 [ drolmer ] [ otoburb ] 02:02 [ early` ] [ prusnak ] 02:02 [ elichai2 ] [ raj_149 ] 02:02 [ esotericnonsense] [ real_or_random] 02:02 [ evalr ] [ rich ] 02:02 [ felixweis ] [ rodarmor ] 02:02 [ fiatjaf ] [ sanket1729 ] 02:02 [ fjahr ] [ sanketcell_ ] 02:02 [ Galvas ] [ schmidty ] 02:02 [ ghost43_ ] [ sgeisler ] 02:02 [ gnusha ] [ shesek ] 02:02 [ gribble ] [ stevenroose ] 02:02 [ gwillen ] [ th0th ] 02:02 [ harding ] [ Thomas[m]1 ] 02:02 [ Isthmus ] [ tibo ] 02:02 [ jakesyl ] [ valwal ] 02:02 [ jamesob ] [ wallet42____ ] 02:02 [ jeremyrubin ] [ warren ] 02:02 [ jkczyz ] [ willcl_ark ] 02:02 [ jrawsthorne ] [ windsok ] 02:02 [ junderw ] [ wraithm ] 02:02 [ justinmoon_ ] [ zkao ] 02:02 -!- Irssi: #rust-bitcoin: Total of 66 nicks [0 ops, 0 halfops, 0 voices, 66 normal] 02:02 -!- Channel #rust-bitcoin created Fri Mar 9 09:46:56 2018 02:04 -!- Irssi: Join to #rust-bitcoin was synced in 134 secs 05:13 -!- tibo [~tibo@2400:4050:2a83:7000:4d5f:d849:34c0:baa8] has quit [Remote host closed the connection] 05:14 -!- tibo [~tibo@2400:4050:2a83:7000:4d5f:d849:34c0:baa8] has joined #rust-bitcoin 05:18 -!- tibo [~tibo@2400:4050:2a83:7000:4d5f:d849:34c0:baa8] has quit [Ping timeout: 244 seconds] 05:26 -!- belcher_ is now known as belcher 05:52 -!- tibo [~tibo@p3002252-ipngn18401marunouchi.tokyo.ocn.ne.jp] has joined #rust-bitcoin 05:57 -!- tibo [~tibo@p3002252-ipngn18401marunouchi.tokyo.ocn.ne.jp] has quit [Ping timeout: 256 seconds] 07:46 -!- jonatack [~jon@37.164.254.128] has joined #rust-bitcoin 07:50 -!- raj_149 [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 240 seconds] 07:51 -!- raj_149 [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has joined #rust-bitcoin 08:29 < BlueMatt> yay! libsecp merged gcd 08:29 < BlueMatt> time to update rust-secp :) 08:34 < BlueMatt> dongcarl or elichai2 or someone with some linker/llvm knowledge: does anyone have any ideas how you'd filter symbols in llvm ir files? eg in many x86 ld's you can use --version-script to apply a filter and no-export (hopefully drop, with lto) symbols that you don't want to export, but wasm-ld doesn't have anything similar. it'd be nice to do it at the llvm-ir level to make sure llvm-lto has knowledge of the symbols that are being dropped 08:34 < BlueMatt> (its unclear to me if llvm-ld is aware of the limits pre or post lto) 08:35 < elichai2> You could always try with `strings` 08:35 < BlueMatt> huh? 08:35 < elichai2> but that could be unrelated to a symbol 08:36 < BlueMatt> you mean get the list of symbols and pass them all to wasm-ld --export=...? I think you'd end up with more arguments than you're allowed to have in exec() 08:37 < BlueMatt> with --version-script you can have *s in the list 08:37 < elichai2> I was talking about the binary itself(like `strings some_binary | grep my_symbol`) but even then it's mehh, you want at llvm IR level. 08:37 < BlueMatt> yea, you really want to pass it to the linker somehow, or, at worst, get the llvm ir and do it there before handing that back to ld 08:37 < elichai2> so I'm not sure if there are tools to parse llvm-ir (there probably are?) 08:38 < BlueMatt> yea, I think there's a vaguely human-readable asm form for it that you can maybe convert back and forth to 08:38 < elichai2> you can always try at #llvm at OFTC 08:39 < BlueMatt> ugh, then i have to join oftc again 08:39 < BlueMatt> lo 08:39 < elichai2> lol 08:42 < BlueMatt> ok, i asked there 08:51 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 08:51 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 09:55 < elichai2> Rust is in linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/rust?id=c77c8025525c36c9d2b9d82e4539403701276a1d 09:56 < ariard> really? exciting :) 10:04 < BlueMatt> huh, fun. 11:06 < jeremyrubin> it's a draft, no? 11:18 < BlueMatt> elichai2: and....question ignored. 11:19 < elichai2> jeremyrubin: it's in linux-next already, they're just saying they'll probably rebase before it gets into linux 11:19 < elichai2> BlueMatt: :/. Is your end goal eliminating unused symbols in wasm? 11:21 < BlueMatt> elichai2: its come up twice now - https://github.com/rust-bitcoin/rust-secp256k1/pull/287 (which I really hate the idea of stuff like this, but I'm not sure how else to do it) and also in my own stuff where we build a C wrapper that exports the LDK/rust-lightning C bindings as JNI/WASM functions 11:21 < BlueMatt> for Java we can use --version-script to strip out all the symbols that aren't the JNI ones, but for wasm we end up with a much larger wasm file that exports a ton of C bindings functions which we dont want to 11:22 < BlueMatt> plus the libsecp functions, which, again, we dont want to export directly to wasm 11:22 < elichai2> I thought you need to explicitly export symbols for wasm 😔 11:22 < BlueMatt> how? afaiu there's no special "export to wasm" flag, so you can only set "export", which, sure, rustc wont export everything in the codebase to wasm, but once you mix in C stuff all the C functions get exported 11:23 < BlueMatt> rustc is good about it, eg for the LDK/RL C bindings the rust functions don't get exported, only the extern "C" functions do, which is great, but also not sufficient once you mix in C code 11:23 < jeremyrubin> yep -- that's been my experience as well, there's no easu way to filter 11:23 < BlueMatt> its really a shitty limitation of wasm-ld 11:25 < BlueMatt> there really needs to be a visibility=magic_value --export-only-with-magic-value=magic_value option in linkers 11:25 < elichai2> really weird. in emscripten for example you need to either pass `EXPORTED_FUNCTIONS=bla,bla,bla` or mark them with `EMSCRIPTEN_KEEPALIVE` 11:25 < BlueMatt> when you're linking multiple static libraries you may want to re-export only a subset of the things that are exported across the static binaries 11:25 < BlueMatt> sure, but emscripten is a dirty hack, not a real linker :p 11:25 < elichai2> haha yeah 11:26 < elichai2> so you want to expose a symbol to a specific compilation unit, but not to the outside 11:26 < elichai2> it might be related to the fact that linking is weird in wasm IIRC 11:26 < BlueMatt> i mean....kinda? issue is I want to expose it to several compilation units, then merge those compilation units and then only export a subset of them outside 11:26 < BlueMatt> there's no way to do this in regular linkers either, fwiw, except via --version-script 11:27 < BlueMatt> i guess more specifically, I want to take multiple static libraries/compilation units, link-time lto them, and then only re-export the symbols from one of the compilation units 11:28 < BlueMatt> making sure that lto/dce runs on the non-exported bits 12:10 -!- willcl_ark [~quassel@unaffiliated/willcl-ark/x-8282106] has quit [Remote host closed the connection] 12:12 -!- willcl_ark [~quassel@unaffiliated/willcl-ark/x-8282106] has joined #rust-bitcoin 12:27 < BlueMatt> ok, well https://github.com/rust-bitcoin/rust-secp256k1/pull/289 fixes it for clang/rust-cc generated code, now to fix it for rustc-generated code.... 12:51 -!- jonatack_ [~jon@37.173.214.42] has joined #rust-bitcoin 12:52 -!- jonatack [~jon@37.164.254.128] has quit [Ping timeout: 245 seconds] 14:04 -!- tibo [~tibo@2400:4050:2a83:7000:4d5f:d849:34c0:baa8] has joined #rust-bitcoin 16:10 -!- jonatack_ [~jon@37.173.214.42] has quit [Ping timeout: 240 seconds] 18:14 < ariard> BlueMatt: don't take yet #849, reviewing 18:38 < BlueMatt> ariard: sure, will wait 18:39 < BlueMatt> ariard: we also really need to expose holder_max_htlc_value_in_flight, but we currently dont (and it will have to be a separate pr) 18:47 < ariard> BlueMatt: done, should we also allow holder to bump `max_accepted_htlcs` default is 50? 18:47 < ariard> note the interaction with #845 18:47 < BlueMatt> wait, default is only 50? I thought we had a default of the max limit 18:47 < BlueMatt> heh 18:48 < ariard> we have a max limit for the counterparty 18:48 < BlueMatt> right, I guess we could, I almost think we dont care because its the in_flight amount that matters more 18:48 < ariard> wait no 18:48 < BlueMatt> note: 845 is failing tests 18:48 < BlueMatt> also I think your description of how you got the constant in 845 is wrong? 18:48 < ariard> we don't have `max_max_accepted_htlc` 18:49 < ariard> about 330 ? 18:49 < ariard> i need to update this pr 18:49 < BlueMatt> yea, 330 18:50 < BlueMatt> huh, yea, I think we should drop OUR_MAX_HTLCS and replace with whatever the protocol max is, but I'm open to it being configurable if you think users *really* care about it as a dust-limiting number. 18:50 < ariard> what's your reasoning ? p2wsh output aren't 43 bytes-sized 18:50 < BlueMatt> well, my point was there is no such thing as a "standard p2wsh output dust threshold" in core 18:50 < BlueMatt> core has two dust limits: witness outputs and non-witness outputs 18:51 < BlueMatt> it doesnt differentiate further, last i checked 18:51 < ariard> actually it does GetSize(txout) in `GetDustThreshold()` 18:51 < ariard> it does differentiate for the type of spend 18:52 < ariard> `GetSerializeSize(txout)` exactly 18:53 < BlueMatt> huh? https://github.com/bitcoin/bitcoin/blob/6c6140846f37de8c132b3b6abf09f3d7940554a7/src/policy/policy.cpp#L30 18:53 < BlueMatt> ohhhh 18:53 < BlueMatt> i see your point 18:53 < ariard> Core computes in function of the *actual* size of the output spend and a differing constant in function of witness/non-witness 18:53 < ariard> the constant isn't the same between witness/non-witness afaiu this code 18:54 < ariard> yes we can drop OUR_MAX_HTLC and make it configurable but i would be happy to have a max bound ~100 18:54 < BlueMatt> whats the protocol max? like 140 or something? 18:54 < BlueMatt> or is it 400? 18:54 < ariard> 483 18:55 < ariard> in both direction 18:55 < BlueMatt> ah, right 18:55 < ariard> i don t think ~100 will bother our users right now considering current network volume 18:55 < BlueMatt> heh, i was just digging it out 18:55 < BlueMatt> I think we should either use 483 or have a good reason to not do that 18:55 < ariard> my good reason is the dust thing 18:55 < BlueMatt> and if we have a good reason not to, we should probably have math behind it, and also probably make it configurable 18:56 < BlueMatt> also, lol, yea, so I'm blind af about the dust limit....gotta go fix rust-bitcoin now https://github.com/rust-bitcoin/rust-bitcoin/pull/566 18:58 < ariard> aha lol, but i think core is making a rough assumption, a p2wsh witness spend might be smaller than a p2wpkh 18:58 < ariard> have to go to sleep, back tmrw 18:58 < BlueMatt> rough estimation or not, its effecitlvely a network rule 18:58 < BlueMatt> goodnight! 19:36 < BlueMatt> ariard: lol, andytoshi was already mad about that pr...now he's gonna actually kill me 21:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 21:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds] --- Log closed Fri Mar 19 00:00:00 2021