-
Notifications
You must be signed in to change notification settings - Fork 30
/
combining-taproot-with-psbt-via-descriptors.txt
73 lines (57 loc) · 3.71 KB
/
combining-taproot-with-psbt-via-descriptors.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
Combining Taproot with PSBT via descriptors
Summary notes of #bitcoin-core-dev irc discussion on 2019-07-15
Discussion log here:
http://www.erisian.com.au/bitcoin-core-dev/log-2019-07-15.html#l-548
elichai: We would need
1. new descriptors
2. classes and support for Witness V2 Bech32 addresses
3. classes for Taproot in the wallet
4. serialization/deserialization of Taproot and witness v2 addresses
sipa / achow:
To combine Taproot into PSBT, would need to touch signing/PSBT logic
and descriptors. If we have Taproot support in descriptors and PSBT,
we'll automatically have it in the wallet, just like right now the
user never provides keys, UTXOs, etc.
In the RPC, we have PSBT support for the full stack of operations
outside of the wallet, so Taproot can be implemented and tested
without ever touching the wallet code at all (assuming descriptor
wallets, since we don't have the equivalent of walletprocesspsbt
using descriptors yet, maybe we need that first), then all we need is
to add Taproot to PSBT/descriptors, and the full stack of operations
would be supported outside of the wallet.
Musig is harder though, as it requires state on the signer device.
The tree structure for multiple scripts would be in the descriptor.
The 32-byte x-coordinate idea (which we may update Taproot with) may
affect how that PSBT record is structured too, but it's not like we
need new parsing code; Bech32 parsing is already generic.
For example, an RPC that takes a descriptor and a bunch of private
keys, and signs with them, would be pretty generally useful.
For the extensions to PSBT... I think it's generally too early.
Once Taproot is finalized, I think the way to actually add it to PSBT
via descriptors will be pretty straightforward.
What will be needed in terms of data structures is:
1. a "taproot derivation" record in signing providers
2. descriptors that can fill that record
3. a way for that record to be serialized in PSBT
4. and signing logic to use it
For descriptors we likely want a fragment tap(KEY,[[X,Y],[Z,[T,U]]])
kind of construction, where you give the root key and the leaves in
some tree-encoding way where the X/Y/Z/T/U are subexpressions that
represent scripts.
They could be pk(), or multi(), ... or once we have miniscript
probably a whole bunch more things (I hope to publish more about that
soon) and that would then get converted into a "taproot key record"
for the key path and for each leaf in signingprovider/psbt.
src/script/descriptor.cpp L149-170 is an interface for all the "key"
expressions inside BIP32, with a number of implementations (pubkeys,
descriptors, origin info).
src/script/descriptor.cpp L335-497 is a generic implementation of a
"script" node in a descriptor, followed by implementations that add
node-specific logic (pk, pkh, sh, wpkh, wsh, multi, combi, addr, raw)
and after that is parsing (string to descriptor) code and inference
(script to descriptor) code.
If your end goal is integrating things into Bitcoin Core, I suspect
getting familiar with the code is the best way to spend time. If you
want to learn the code better (which i very much encourage you to!)
I think it's better to focus on one piece at a time and actually
integrate it.