19:00:58 #startmeeting 19:00:58 Meeting started Fri Jul 5 19:00:58 2019 UTC. The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:58 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:04 #bitcoin-core-dev Wallet Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball 19:01:09 all I have to say is that #16341 does the wallet restructure and is very large 19:01:11 https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub 19:01:11 hi 19:01:32 achow101: the infamous box? I'll add to my review list. 19:01:35 #topic miniscript update (sipa) 19:01:40 hola 19:01:41 hi! 19:02:46 so me and some colleagues of mine have been working on a way to make more complex bitcoin scripts more accessible, in a project called miniscript 19:03:19 this is about the bitcoin scirpt language as it exists today, without any softforks or other changes to consensus needed (but obviously prepared for those) 19:05:03 the idea is that we can define a subset of script which is composable (so things can be arbitrarily nested, say you can replace a public key anywhere with a "subexpression" which corresponds to an arbitrary policy), has properties like correctness and nonmalleability that can be easily reasoned about, and can be targetted by a compiler that converts policies into scripts 19:05:32 with this, we could make software/hardware wallets support basically arbitrary policies, without even any extensions to psbt 19:06:07 there's a website which is still actively being changed: http://bitcoin.sipa.be/miniscript 19:06:30 does this make sense? 19:07:10 sipa: is your website the only documentation of miniscript? 19:07:30 achow101: andrew and sanket are also working on a rust implementation, which is public i think 19:07:44 but as we're actively changing things yet i prefer to not really have any production code available 19:09:13 This seems very nice 19:09:13 so the different moving parts would be (a) signing logic in core/other software which is miniscript compatible, allowing signing/updating of any valid miniscript-compatible script (b) extension to descriptors that lets you include miniscript expressions, which are kinda engineer-readable but maybe a bit less than descriptors are now... (c) a compiler from policies with probabilities for all 19:09:20 branches/choices to miniscript descriptors 19:09:48 I see the aor was replaced with explicit probabilities, is that overkill or are there use cases in mind? 19:10:11 jb55: it was basically impossible to write a 3-way or where each branch is equally likely 19:10:32 ah 19:10:50 oh we also came up with a neat algorithm that lets you compute the worst-case satisfaction cost for a miniscript, with annotations on various branches saying "this key is certainly available, this key will not be available at signing time, this key may be available at signing time" 19:10:59 which is useful for fee estimation 19:11:28 [13bitcoin] 15sipsorcery closed pull request #15995: systemd service script: set usable permissions on /etc/bitcoin config dir (06master...06systemdconfig) 02https://github.com/bitcoin/bitcoin/pull/15995 19:11:30 and the compiler is also good enough now that it can construct scripts that are strictly better than the bolt 3 htlc scripts... but obviously incompatible with them 19:12:04 it'd be nice to support all actual script people have come up with in the past, but it would require adding a whole bunch of ad-hoc extensions for weird tricks 19:13:25 cool! how close to being finalized do you think it is? 19:13:32 (aka when pr?) 19:13:46 i think we're very close to finalizing the design of the language... but we've been saying that for a few weeks now 19:14:04 it'll be some work to convert the hacky code to something PR'able 19:14:08 but i hope soon 19:14:55 so a motivation for this is for example being able to use a 2-of-3-timelocked-escrow-cool policy as a "participant" in a multisig, rather than being restricted to just keys in the multisig 19:16:04 more questions? otherwise end topic 19:16:30 the policy language is descriptors, right? 19:16:50 nope 19:17:25 the thing i envision becoming part of descriptors is a 1-to-1 mapping with script itself 19:17:47 so there is no "compilation" step between the descriptor and the script, as that compilation is pretty complex 19:18:20 is it policy -> descriptor -> script? 19:18:22 so the policy language is similar, but it has probabilities in it, and only has and/or/threshold/key/hash/time functions 19:18:29 policy -> descriptor <-> script 19:18:51 ah, ok 19:18:56 while the descriptor extensions have a ton of different ways of encoding an and/or, depending on context, probabilities, ... 19:19:39 i don't expect the policy language and the compiler to become part of core, 19:20:26 though maybe some analysis functionality may be (e.g. we can extract a policy without probabilities back from the script etc) 19:20:43 So what are you planning to PR then? 19:21:08 ability to sign/update/psbt arbitrary miniscript compatible scripts 19:21:11 and extensions to descriptors 19:21:33 basically replacing the solver and ProduceSignature? 19:22:00 so instead of pattern matching to figure out how to sign and finalize, interpret miniscript/descriptors 19:22:05 right 19:22:17 maybe all of the signing code can become delegated to a miniscript module 19:22:45 maybe the existing rawtransaction-compatible ones should just stay as legacy code, and only miniscript code gets invoked for more complex things 19:23:20 and with native descriptor wallets, people will be able to track whatever weird scripts they want and be able to sign for them 19:23:47 the conversion from script to miniscript structure is basically an LALR(1) parser (we have a handwritten one that's easier to read, but tools like bison/yacc can generate code to do this trivially) 19:24:11 yup 19:24:28 and with psbt, you can have even hardware wallets in theory participate in signing 19:24:46 though they may freak out with the unconventional scripts, and change detection becomes a lot harder 19:25:03 sipa: is the conversion from script to policy ever ambiguous? 19:25:11 if that makes sense 19:25:41 jb55: if you define an "abstract policy" which is a policy but without probabilities in it, you can always derive the abstract policy from a script 19:26:03 Ah that LALR parser point answered my next question 19:26:04 in such a way that it's equivalent to the policy fed to the compiler 19:26:43 sipa: and that is guaranteed to be unique? 19:26:43 jb55: though if the compiler gets a lot smarter, this may not be possible anymore (e.g. complex reasoning over booleans/threshold gates to simplify the policy before compiler) 19:27:15 jb55: testing whether two different encodings of the same abstract policy are identical for arbitrary policies is an intractable problem 19:27:56 like and(a,thresh(2,a,b,c)) is identical to and(a,or(b,c)) 19:28:08 things like that cannot be generally compared 19:28:28 but the compiler (so far) won't ever make such transitions 19:29:13 right 19:32:50 Alright this seems very nice, thank you sipa, I need some time to read the website in more detail 19:33:12 Does anyone have any other topics to discuss today? 19:34:17 please review wallet boxes and the 3 PRs it depends on 19:34:47 Yes ^ sorry I haven't reviewed much yet, it's been a crazy week 19:36:36 #action review wallet box PRs 19:36:41 #endmeeting