--- Day changed Tue Nov 24 2020
00:51 < shesek> v4.0.0 is out, nice! \o/
01:36 < darosior> "Just published a new major release. " => Nice :D
02:19 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has quit [Ping timeout: 256 seconds]     
02:20 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined ##miniscript     
02:27 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has quit [Ping timeout: 256 seconds]     
02:37 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds]     
02:43 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##miniscript     
03:06 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
03:12 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined ##miniscript     
03:27 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript     
05:45 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Ping timeout: 240 seconds]     
05:58 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined ##miniscript     
07:40 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript     
08:20 < justinmoon> Oops my fault forgetting about uncompressed keys! Is there any reason rust-miniscript needs to work with uncompressed keys in the first place? rust-bitcoin probably needs to support them ...
08:44 < andytoshi> justinmoon: yeah, just because rust-bitcoin supports them
08:44 < andytoshi> we could forbid them outright across rust-miniscript and probabyl nobody would complain..
09:17 < shesek> bwt v0.2.0 is out, with rust-miniscript-powered descriptor tracking. :) https://twitter.com/shesek/status/1331284400558968838
09:44 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined ##miniscript     
09:50 < andytoshi> nicee
09:51 < sipa> awesome
09:56 < shesek> thanks! this release also includes libbwt, a C FFI library that allows embedding the bwt server into third party software. the goal is to make it easy for electrum-backed wallet developers to add support for a bitcoin core rpc backend, by running the electrum server on the wallet side
09:57 < shesek> https://github.com/shesek/bwt/blob/master/doc/libbwt.md
09:59 < shesek> I'm hoping to eventually do something similar with neutrino too, so you'll have a neutrino p2p backend exposed as an electrum server to give wallets an easy upgrade path
10:00 < jeremyrubin> [11/24/20 08:44] <andytoshi> we could forbid them outright across rust-miniscript and probabyl nobody would complain..
10:01 < jeremyrubin> maybe the script -> Miniscript paths would be unhappy if that happened
13:39 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
13:43 < darosior> sanket1729_: good point about checksum validity for miniscript descriptors. Looking at https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums it looks pretty good ?
13:49 < sanket1729_> darosior: yeah, it looks pretty good. 
13:50 < sanket1729_> > "up to 4 errors will always be detected in descriptors up to 501 characters, and up to 3 errors in longer ones."
13:50 < darosior> sipa got us covered :)
13:50 < sanket1729_> sipa: Do you remember what it limit on the longer ones?
13:55 < sipa> https://github.com/bitcoin/bitcoin/blob/master/src/script/descriptor.cpp#L29L47
13:59 < andytoshi> do we do checksum decoding in rust-miniscript?
13:59 < andytoshi> i constantly forget that we need to implement this..
13:59 < andytoshi> i guess this is what issue trackers are for
14:00 < sanket1729_> darosior opened #195 for it
14:00 < darosior> andytoshi: will propose a patch
14:04 < sanket1729_> nit: The source code says 4 errors will be detected upto 507 characters whereas the doc says 501 characters. 
14:05 < sanket1729_> andytoshi, sipa: I don't know how the current checksum will be interact with miniscript. What about character substitions like or_i to or_b or something else
14:09 < sipa> sanket1729_: that may count as 2 symbol errors
14:10 < sipa> sanket1729_: but i'm not particularly worried about that... errors in a fragment will almost certainly result in an invalid fragment
14:10 < sipa> *fragment names
14:14 < shesek> bdk has a rust implementation of checksums: https://github.com/bitcoindevkit/bdk/blob/master/src/descriptor/checksum.rs
14:20 < sanket1729_> I spent a while thinking about the current guarantees. I agree that fragment name substitutions will likely return a invalid fragment. But I am not so sure about the wrappers. It maybe possible to error on wrapper and still get a typed checked miniscript. 
14:20 < sanket1729_> But they don't change the semantics at all
14:22 < sanket1729_> maybe i should not be doing adverserail thinking while thinking about checksums
14:22 < sanket1729_> it's about accidents
14:23 < sipa> indeed
16:01 < andytoshi> unfortunately the bdk code is not licensed compatibly with rust-miniscript
16:36 < sanket1729_> really? it's MIT license. 
16:41 < sanket1729_> TIL about CC0 license vs MIT license
17:22 < andytoshi> lol yeah nothing is compatible with public domain ;P
17:22 < andytoshi> have you been contributing code all this time and didn't realize it was CC0?
17:29 < andytoshi> musing about rewriting icboc to use descriptors
17:29 < andytoshi> this is my homebrew wallet that lacks spending code (i just checked, the only form of coin selection i bothered implementing was FIFO apparently)
17:30 < andytoshi> it attempts to encrypt all of the wallet data using the ledger, with the idea that i could freely upload the wallet file to whatever random pastebins/github i wanted and it'd just be a big uniformly random blob
17:31 < andytoshi> but i do this by doing AES using symmetric keys since the ledger does not support pk encryption, which is (a) stupidly slow and (b) stupid
17:31 < andytoshi> because if the hww is plugged in then malware can decrypt the wallet without my intervention and i've lost all my privacy
17:32 < sipa> is there so way of using signature interface to construct ECDH?
17:32 < sipa> i suspect not, as signing only does an n*G multiplication, not arbitrary-base
17:33 < andytoshi> heh, yeah, so i'm musing about this..
17:33 < andytoshi> i guess a first question is whether the ledger produces deterministic signatures
17:34 < andytoshi> if that's so, maybe i can abuse the nonces somehow
17:34 < sipa> ah, right
17:34 < sipa> deterministic nonces are effectively an HMAC
17:35 < sipa> i should say "a MAC"
17:35 < andytoshi> right...so unfortunately without dangerous tricks though i can't get any secret key material out of the ledger
17:35 < andytoshi> "dangerous tricks" meaning restoring the recovery phrase and deriving keys on other hardware..
17:36 < andytoshi> yeah i think they're deterministic, i tried signmessage twice and rebooted in between and it came back the same 
17:37 < andytoshi> that's all the proof i need :P
17:37 < andytoshi> ok but does that get us anything
17:37 < sipa> i assume they're RFC6979
17:38 < andytoshi> yeah i would hope so
17:38 < andytoshi> i guess, i could just grind out a fixed messagehash and encrypt with the s value of the sig
17:38 < andytoshi> then to decrypt the wallet will flash "sign this message? 0xDEADBEEFwhatever" and that'd be my cue that i'm decrypting the wallet
17:39 < sipa> you can use the r value too
17:39 < sipa> as it's G*hash(key, msg) really
17:42 < andytoshi> yeah make sense
17:43 < andytoshi> ah R i think would be nicer to use, because iirc the ledger does something dumb with low-s and signmessage
17:43 < sipa> no harm in using s, though
17:43 < andytoshi> i think "something dumb" is just not using low-s, but i don't remember exactly and if i use R i don't need to look it up
17:44 < sipa> you can convert to low-s after signing
17:44 < sipa> if need be
17:45 < sipa> does ledger support bip38 something?
17:45 < sipa> that involves arbitrary base point multiplication
17:45 < sipa> maybe you can implement ecdh on top ;)
17:47 < andytoshi> lol fraid not
17:48 < andytoshi> it gives me signmessage, signing bitcoin transactions, deriving xpubs
17:48 < andytoshi> and for some reason there's a block of bip32 paths where it'd do signmessage without user intervention
17:49 < andytoshi> i could install other apps on it which give me other stuff (including directly PKE) but the last time i tried that i had a bad time fighting the sdk
17:50 < andytoshi> and at one point i bricked the device and had to mail it to achow101 who somehow recovered it :P
18:45 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript     
19:02 < shesek> I (finally!) got minsc ported to rust-miniscript, with new runtime data types and functions for descriptors, addresses, (x)pubkeys, hashes and compiled miniscripts. a demo is available at https://min.sc/v0.2/
19:03 < shesek> this enables people to easily get their (testnet) bitcoins locked up with advanced scripts, and most likely not be able to get them out. :p I'm gonna try to tackle that part next, with the help of bdk and bwt
19:04 < shesek> this is still not officially released and none of the new features are documented on the website, but I wrote up an example of using them at https://t.co/CiyQKtFEjq
19:37 < andytoshi> super cool!
19:37 < andytoshi> i think the two links are the same?
19:40 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined ##miniscript     
20:05 < shesek> the shortened t.co one has a long hash fragment in it, with a minsc snippet that should get displayed in the playground code editor
20:21 < shesek> the runtime derivation operator could be useful for avoiding key reuse, by deriving different key paths for the different branches, e.g. https://t.co/xlgw2yO9Pc (silly example that could more easily be rewritten to avoid reuse)
22:33 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds]