Skip to content

Commit f901f33

Browse files
authored
Merge pull request #1958 from mintlayer/wasm_binding_doc_improvements
Small improvement in WASM docs - explain what `additional_info` is
2 parents 77adc27 + 145976b commit f901f33

2 files changed

Lines changed: 32 additions & 4 deletions

File tree

wasm-wrappers/WASM-API.md

Lines changed: 16 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -223,12 +223,26 @@ Sign the specified input of the transaction and encode the signature as InputWit
223223
otherwise emit 1 followed by the corresponding transaction output encoded via the appropriate "encode_output_"
224224
function.
225225

226+
`additional_info` must contain the following:
227+
1) for each `ProduceBlockFromStake` input of the transaction, the pool info for the pool referenced by that input;
228+
2) for each `FillOrder` and `ConcludeOrder` input of the transaction, the order info for the order referenced by
229+
that input.
230+
Note:
231+
- It doesn't matter which input witness is currently being encoded. E.g. even if you are encoding a witness
232+
for some UTXO-based input but another input of the same transaction is `FillOrder`, you have to include the order
233+
info when encoding the witness for the UTXO-based input too.
234+
- After a certain hard fork, the produced signature will "commit" to the provided additional info, i.e. the info
235+
will become a part of what is being signed. So, passing invalid additional info will result in an invalid signature
236+
(with one small caveat: for `FillOrder` we only commit to order's initial balances and not the current ones;
237+
so if you only have `FillOrder` inputs, you can technically pass bogus values for the current balances and
238+
the resulting signature will still be valid; though it's better to avoid doing this).
239+
226240
### Function: `encode_witness_htlc_secret`
227241

228242
Given a private key, inputs and an input number to sign, and the destination that owns that output (through the utxo),
229243
and a network type (mainnet, testnet, etc), and an htlc secret this function returns a witness to be used in a signed transaction, as bytes.
230244

231-
`input_utxos` have the same format as in `encode_witness`.
245+
`input_utxos` and `additional_info` have the same format and requirements as in `encode_witness`.
232246

233247
### Function: `encode_multisig_challenge`
234248

@@ -247,7 +261,7 @@ and a network type (mainnet, testnet, etc), this function returns a witness to b
247261
`key_index` parameter is an index of the public key in the challenge corresponding to the specified private key.
248262
`input_witness` parameter can be either empty or a result of previous calls to this function.
249263

250-
`input_utxos` have the same format as in `encode_witness`.
264+
`input_utxos` and `additional_info` have the same format and requirements as in `encode_witness`.
251265

252266
### Function: `encode_signed_transaction`
253267

wasm-wrappers/src/lib.rs

Lines changed: 16 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -700,6 +700,20 @@ pub fn encode_witness_no_signature() -> Vec<u8> {
700700
/// `input_utxos` must be formed as follows: for each transaction input, emit byte 0 if it's a non-UTXO input,
701701
/// otherwise emit 1 followed by the corresponding transaction output encoded via the appropriate "encode_output_"
702702
/// function.
703+
///
704+
/// `additional_info` must contain the following:
705+
/// 1) for each `ProduceBlockFromStake` input of the transaction, the pool info for the pool referenced by that input;
706+
/// 2) for each `FillOrder` and `ConcludeOrder` input of the transaction, the order info for the order referenced by
707+
/// that input.
708+
/// Note:
709+
/// - It doesn't matter which input witness is currently being encoded. E.g. even if you are encoding a witness
710+
/// for some UTXO-based input but another input of the same transaction is `FillOrder`, you have to include the order
711+
/// info when encoding the witness for the UTXO-based input too.
712+
/// - After a certain hard fork, the produced signature will "commit" to the provided additional info, i.e. the info
713+
/// will become a part of what is being signed. So, passing invalid additional info will result in an invalid signature
714+
/// (with one small caveat: for `FillOrder` we only commit to order's initial balances and not the current ones;
715+
/// so if you only have `FillOrder` inputs, you can technically pass bogus values for the current balances and
716+
/// the resulting signature will still be valid; though it's better to avoid doing this).
703717
#[wasm_bindgen]
704718
#[allow(clippy::too_many_arguments)]
705719
pub fn encode_witness(
@@ -755,7 +769,7 @@ pub fn encode_witness(
755769
/// Given a private key, inputs and an input number to sign, and the destination that owns that output (through the utxo),
756770
/// and a network type (mainnet, testnet, etc), and an htlc secret this function returns a witness to be used in a signed transaction, as bytes.
757771
///
758-
/// `input_utxos` have the same format as in `encode_witness`.
772+
/// `input_utxos` and `additional_info` have the same format and requirements as in `encode_witness`.
759773
#[allow(clippy::too_many_arguments)]
760774
#[wasm_bindgen]
761775
pub fn encode_witness_htlc_secret(
@@ -861,7 +875,7 @@ pub fn multisig_challenge_to_address(
861875
/// `key_index` parameter is an index of the public key in the challenge corresponding to the specified private key.
862876
/// `input_witness` parameter can be either empty or a result of previous calls to this function.
863877
///
864-
/// `input_utxos` have the same format as in `encode_witness`.
878+
/// `input_utxos` and `additional_info` have the same format and requirements as in `encode_witness`.
865879
#[allow(clippy::too_many_arguments)]
866880
#[wasm_bindgen]
867881
pub fn encode_witness_htlc_multisig(

0 commit comments

Comments
 (0)