TapMiniscript #134
TapMiniscript #134
Conversation
8be8095 to
d6fd61a
Compare
multi_a() has the same properties than multi() but 'n' (since all keys may need to be dissatisfied, the top stack item of a satisfaction may be the empty vectore). It could also be 'o' when it contains a single key.. But a `multi_a(1,key)` can always be subsituted by a `pk(key)`.
It's worth noting since for instance the hash in a pkh(key) script would yield a different hash under Tapscript than under P2WSH.
d6fd61a to
0c247a0
Compare
|
ACK 0c247a0 |
| wrapper applied to the <code>v:</code> wrapper applied to the <code>older</code> fragment for 144 blocks. | ||
| wrapper applied to the <code>v:</code> wrapper applied to the <code>older</code> fragment for 144 blocks. Note how | ||
| <samp>key</samp> expressions in this table and the followings are implicitly 32 bytes "x-only" public key in Tapscript | ||
| and 33 bytes compressed public keys in P2WSH. |
There was a problem hiding this comment.
Maybe additionally clarify that under P2WSH the hash is generated with ripmed160(sha256(sha256(A))), whereas in taproot it's sha256(sha256(A_x)).
There was a problem hiding this comment.
Which hashes are you talking about? In Miniscript, if a hash is involved, it'll be written explicitly (hash256(), hash160(), sha256(), or ripemd160()).
There was a problem hiding this comment.
In reference to 70fee03: "It's worth noting since for instance the hash in a pkh(key) script would
yield a different hash under Tapscript than under P2WSH."
There was a problem hiding this comment.
Ah, pkh() always uses ripemd160(sha256(pubkey)), in P2WSH-miniscript, Tapscript-Miniscript, and in descriptors in general. It's only the public key encoding that's different in P2TR (because of xonly keys).
| @@ -420,7 +420,7 @@ <h4>Correctness properties</h4> | |||
| <tr><td><code>a:X</code></td><td><em>X</em> is B</td><td>W</td><td>d=d<sub>X</sub>; u=u<sub>X</sub></td></tr> | |||
| <tr><td><code>s:X</code></td><td><em>X</em> is Bo</td><td>W</td><td>d=d<sub>X</sub>; u=u<sub>X</sub></td></tr> | |||
| <tr><td><code>c:X</code></td><td><em>X</em> is K</td><td>B</td><td>o=o<sub>X</sub>; n=n<sub>X</sub>; d=d<sub>X</sub>; u</td></tr> | |||
| <tr><td><code>d:X</code></td><td><em>X</em> is Vz</td><td>B</td><td>o; n; d</td></tr> | |||
| <tr><td><code>d:X</code></td><td><em>X</em> is Vz</td><td>B</td><td>o; n; d; <small>(Tapscript only)</small> u</td></tr> | |||
There was a problem hiding this comment.
In the gist is says
d: remains available, and corresponds to the same script, but has different typing rules in tapscript miniscript (it always has the u type property)
Maybe add a comment below Then there are 5 type modifiers, which guarantee additional properties:.
For some fragments like andor(X,Y,Z) there's a complicated rule of how d and u are taken from the original. It's non-obvious to me that this guarantees "[d] always has the u type property". Can you clarify that?
There was a problem hiding this comment.
I'm confused by your question. Are you asking about d:, or about andor()? The latter does not always have the u property.
There was a problem hiding this comment.
andor() has rules for both the u and d property. It's unclear how those rules guarantee that any d also has u.
There was a problem hiding this comment.
@Sjors Oh, I see your confusion now. There is both a d: wrapper and a d property, which are unrelated. This change is about the d: wrapper, which under Tapscript always has the u property. The d property in general is unaffected.
|
The n-ary stuff is not included in this update yet? I'm also not seeing it mentioned in the Bitcoin Core PR (description). Is the |
|
@Sjors This PR was just about taproot extensions; it doesn't include musig/unspendable/n-ary/partial descriptors/... |
This integrates the necessary amendments to the specs to support Miniscript in Tapscript.
This is based on numerous previous discussions with a number of people. I think this gist reflects the latest state of the discussion.