[PSET] Add Blinder role

[tiero]

The blinder role is responsible for taking an unsigned partial transaction (thus it needs to check that every partial input has a empty PartialSignature) with unblinded outputs and proceeds to make them confidential by replacing their asset and values with commitments and by adding a nonce, and range and surjection proofs.
In this first version of the blinder role, we do not care about blinding issuance inputs since we do not support non-confidential issuance yet.

The process of blinding the outputs of a transaction is composed of the following steps:

1. Unblind tx inputs

First of all, we need to unblind every confidential utxo used as input of the transaction to get their asset/value commitments and blinding factors.
In order to accomplish this, every partial input must have a valid WitnessUtxo or NonWitnessUtxo set, so that we can determine if the utxo it refers to is confidential by checking if it has a range and a surjection proof.
Thus, to unblind all the confidential inputs we need the user to provide a list of valid blinding private keys.

for every partial input {
   1. get utxo from WitnessUtxo/NonWitnessUtxoField of partial input
   2. unblind utxo with respective blinding private key provided
   3. store unblinded value, asset, and blinding factors 
}

Take a look at how this step is implemented in the liquid-js library.

2. Generate blinding factors

The second step is to create asset and value blinding factors for every tx output, except for the fee out that must be kept non-confidential (this output is recognizable because it's the only one in a tx that has an empty script).
Every asset blinding factor is generated randomly by a strong rng function.
Every value blinding factor except for one of the last output is generated randomly by a strong rng function.
The value blinding factor of the last output is generated by calling the FinalValueBlindingFactor function, passing the previously unblinded input assets/values and blinding factors, and passing also the output values and the just created random asset/value blinidng factors:

for every output -1 (exclude the fee out!) {
   generate and store random asset blinding factors
}

for every output -2 (exclude fee and last output) {
   generate and store random value blinding factors
}

generate last value blinding factor with FinalValueBlindingFactorInput
add the last vbf to the array of value blinding factors

Here you can see how this step is implemented in the liquid-js library.

3 Blind tx outputs

Now that we are ready, it's time to effectively blind all tx outputs.
Then, for every output, we create the asset and value commitments from the unblinded asset/value and the respective blinding factors we created before.
We create an ephemeral random private key we need for generating the range proof.
The public key derived from it is used as the output nonce.
Last, we create the range and surjection proofs, check this out for the implementation details for creating the proofs.

for every output {
   1. skip if the current output is the fee one
   2. create value and asset commitments for the current output
   3. create random private key
   4. set derived public key as the nonce of the current output
   5. create range proof with current output data, ephemeral privkey and current blinding pubkey
   6. create a random seed (entropy for surjection proof)
   7. create surjection proof with output data and random seed
}

[stevenroose]

Just a heads-up that we are in the process of revisiting the blinding portion of the PSET process.

I'm very excited about the work being done here (used to work with Go a lot and I still like the language!), so I wouldn't want you guys to spend a lot of time on this only to have to redo some of the work later.

I would suggest keep an eye on this issue: ElementsProject/elements#879

We're aiming to get a document out with the described new fields etc before we start implementing it in Elements itself, so that you guys know about the changes as soon as possible.

[tiero]

Hello @stevenroose we merged our initial implementation already because we have couple of products/services that we need this library for. We will adapt in case there would be a any incompatibility. Also, a formal specification of the Blinder Role could help future implementers in other languages/stack too.

You can take a look at the integration test in blinder_test.go for an high-level understanding of how it looks like, where a TX with confidential outputs is broadcasted.
(We use nigiri-travis for an Elements regtest inside a CI pipeline)

I will keep an eye on that issues btw