Add TX manifest proposal#41
Conversation
| | <code>"wallet_key"</code> || 32-byte x-only BIP340 Schnorr pubkey (hex) || <code>m/86h/<coin>h/0h/0/0</code> | ||
| |} | ||
|
|
||
| <code>coin</code> = 0 for mainnet, 1 for testnet. |
There was a problem hiding this comment.
I believe it's 0 for Bitcoin and 1776 for Liquid.
| |- | ||
| | <code>optional</code> || boolean || NO || If <code>true</code>, output may be omitted. Default: <code>false</code>. | ||
| |- | ||
| | <code>confidential</code> || boolean || NO || Whether this output is blinded (Liquid/Elements only). Overrides the chain default (see Blinding below). |
There was a problem hiding this comment.
Can this possibly be derived from the destination field? The provided address format will say if confidentiality is required.
There was a problem hiding this comment.
The address might be a simplicity covenant, in which case the address is the same for both.
Also, the destination might be "wallet" which allows the wallet to create an address, although I don't see a need for turning off confidential amounts for self addresses.
|
|
||
| '''<code>"simplicityhl"</code> (static SimplicityHL value).''' Fields: <code>value</code> (required; a SimplicityHL value expression: <code>"0x<hex>"</code> for byte arrays, <code>"Left(())"</code> / <code>"Right(())"</code> for Either types) and <code>simplicity_type</code> | ||
|
|
||
| '''<code>"Signature"</code> (BIP340 Schnorr signature).''' Fields: <code>sig_type</code> (required; currently only <code>"simplicity.sig_all_hash"</code>) and <code>source</code> (required; <code>{"type": "wallet", "key": <reference>}</code> where the reference resolves to a 64-hex-char x-only public key). The tool computes the sighash, signs with the wallet key matching the given pubkey, and injects the 64-byte signature as a <code>"simplicityhl"</code> witness. The value <code>"simplicity.sig_all_hash"</code> is namespaced to make clear it is Simplicity's own <code>sig_all_hash</code> jet commitment over the full transaction (computed via the Elements transaction environment), '''not''' the standard Elements SIGHASH_ALL. |
There was a problem hiding this comment.
Sometimes signatures may not have standalone witness names and instead have to be injected into tuples and tuples of tuples.
There was a problem hiding this comment.
This is true. In my example I changed the contract to have two separate witness fields, but let me try get a working example as you say
There was a problem hiding this comment.
Here is the injector code we use in simplex if you need some inspiration:
https://github.com/BlockstreamResearch/smplx/blob/master/crates/sdk/src/signer/wtns_injector.rs
| }, | ||
| "actions": { | ||
| "Pay": { | ||
| "params": { |
There was a problem hiding this comment.
I don't fully understand. Do "params" get populated by the wallet (prompting the user for some input), or instead taken from the "instance/build file" passed alongside the manifest?
There was a problem hiding this comment.
Yes, they are shown to the user. Would it make more sense to name these "args"?
There was a problem hiding this comment.
Do we expect the wallet to handle this prompting? It may be quite arbitrary and complex. I thought the dapp itself (the website) would be used to navigate the user, and then send all the data together with the manifest to the wallet just for the "confirmation" of the action.
| "manifest_version": "0.1.0", | ||
| "protocol": "p2pk-simplicity", | ||
| "description": "...", | ||
| "chain": "elements", |
There was a problem hiding this comment.
Also, I'd identify the chain according to BIP-122 and ELIP-144.
2 participants
Adds an ELIP for a new TX manifest format for wallets. Specifically aimed at making SimplicityHL contracts easier to integrate into wallets.