pset: add optional asset blinding factor to input and output

[LeoComandini]

In some protocols where blinding is done by different parties,
the asset surjection proof for some output might be created by:

• someone who does not own an input with the same asset, or
• someone who does not know the asset blinding factor
  corresponding to the output asset commitment

This, in general, is the case of LiquiDEX v1 [1], e.g.

• Alice wants to swap x of asset A for y of asset B
• Alice owns a utxo with x of asset A
• Alice creates a spending that utxo and receiving an output
  with y of asset B.
• Alice draws at random the asset and value blinding factors
  for the output, sets the corresponding asset and value
  commitment. Sets the nonce commitment. Computes and sets
  the rangeproof.
• Alice computes the scalar offset contribution of the input
  and output (combined)
• Alice computes the value blind proofs for the input and output
• Alice creates the LiquiDEX proposal using the data obtained
  above:

{
  "version": 1,
  "tx": "...",
  "inputs": [{
    "asset": "aa...",
    "satoshi": x,
    "assetblinder": "...",
    "value_blind_proof": "...",
  }],
  "outputs": [{
    "asset": "bb...",
    "satoshi": y,
    "assetblinder": "...",
    "value_blind_proof": "...",
  }],
  "scalars": ["..."],
}

• Alice shares the proposal with Bob
• Bob adds more inputs for the asset B and fees
• Bob adds more outputs for the asset A, B and fees
• Bob blinds the transaction, i.e.:
  • draws at random abf and vbf for each new output, apart
    from the last one for which he uses the new inputs
    contribution and the scalar offset from the proposal to
    balance the tx.
  • creates rangeproofs for each new output
  • creates surjection proofs for each (blinded) fee output
  • creates surjection proofs for each A output, note that
    in general the input asset blinding factor is needed.
  • creates surjection proofs for each B output, including
    the one from Alice, which requires the output blinding
    factor. Note that Alice could not have created the
    surjection proof since she did not know any B input
    when she created the tx.

Input and output asset blinding factors are the last fields
needed to convert LiquiDEX v1 proposals in PSETs (and viceversa).

---

[1] https://leocomandini.github.io/2022/10/27/liquidexv1.html

[delta1]

utACK bc3870a with minor comments

[LeoComandini]

Hi @delta1 ,
I've addressed your comments and rebased.
Should I do something more to have this merged?

[delta1]

hey @LeoComandini, I was hoping to get another set of eyes on this.

@apoelstra could you please review?

[apoelstra]

Does anyone remember where the (very long past discussion was where I was opposed to putting raw secret data into PSETs?

I think this should have an ELIP number.

[LeoComandini]

Does anyone remember where the (very long past discussion was where I was opposed to putting raw secret data into PSETs)?

Pinged you in that chat

You also reviewed and merged the same change in rust-elements, see ElementsProject/rust-elements#201

[apoelstra]

You also reviewed and merged the same change in rust-elements, see ElementsProject/rust-elements#201

I had assumed that PRs to rust-elements from Blockstream employees which add PSET fields with no description or justification were implementing missing functionality. Not that they were controversial out-of-spec extensions. I'll review more carefully in the future.

[jsarenik]

Does anyone remember where the (very long past discussion was where I was opposed to putting raw secret data into PSETs?

I think this should have an ELIP number.

@apoelstra please share as I could not find it yet.

Some quick candidates may be:

• x-only ECDH without sqrt bitcoin-core/secp256k1#262
• WIP: Threshold signatures BlockstreamResearch/secp256k1-zkp#46
• hashes: Epic re-write rust-bitcoin/rust-bitcoin#2770
• We should not be running pkh logic through rawpkh rust-bitcoin/rust-miniscript#483

[apoelstra]

@jsarenik I found an internal discussion about it. I'm not sure when I will have time to review it.

Meanwhile probably the best way to move forward @LeoComandini is to open a ELIPs PR to add these fields so that we can move discussion into a public arena.

[LeoComandini]

@apoelstra , opened ELIP PR ElementsProject/ELIPs#18

[apoelstra]

Merged the ELIP.

Since this is LiquiDEX-specific and a proprietary extension, I think we should close this PR and instead only implement it in rust-elements/elements-miniscript.

[delta1]

Closing since this is now in rust-elements ElementsProject/rust-elements#207

@LeoComandini if you do need this in Elements then let's revisit this discussion