Options contract funding path lets reissuance tokens escape contract

[apoelstra]

In the current funding_path of crates/contracts/src/options/source_simf/options.simf we have

fn funding_path(expected_asset_amount: u64) {
    ensure_input_and_output_script_hash_eq(0);
    ensure_input_and_output_script_hash_eq(1);
    assert!(dbg!(jet::eq_256(get_output_script_hash(0), get_output_script_hash(1))));

    assert!(jet::le_32(jet::current_index(), 1));
...

and we never constrain inputs 0 or 1 again. In other words, we only force their scripts to be the same, but not their asset types or amounts. This lets a user create 0- or 1-valued outputs in this slot, putting the rest of the token(s) into another output with no constraints on it. (Alternately, they can add a small extra L-BTC input to the transaction, put the L-BTC into outputs 0 and 1, and move all of the reissuance tokens out of the contract.)

This is not improved or changed by #20, though the problem becomes a bit clearer since the contract is overall simpler.

[KyrylR]

Oh, got it. If you have any ideas on how to do it properly with PSET, that would be great.

Right now I am stuck with the following rule:

The Asset must be a commitment equal to either the Grantor
Token Generator's Commitment with an Asset Blinding Factor of
1, or the Grantor Token Generator's Commitment with an Asset
Blinding Factor of 2

from https://blockstream.com/assets/downloads/pdf/options-whitepaper.pdf.

So I would appreciate any hints on how to check that the input and output reissuance assets are equal.

I would love to make those explicit, but due to the weirdo (maybe not weirdo) check on the node, I have to keep reissuance assets confidential

[KyrylR]

Hmm, maybe I have another idea, let me check

[KyrylR]

So, instead of checking that the reissuance assets are in the 0 and 1 indexes, I would check that all other assets are in their proper places.

Here is the check for the Options contract:

// Input 1: First reissuance token (not checked)
// Input 2: Second reissuance token (not checked)
// Input 3: Collateral and fee (checked -- line 132)

// Output 1: First reissuance token (not checked)
// Output 2: Second reissuance token (not checked)
// Output 3: Collateral (checked -- line 128)
// Output 4: First asset (checked -- line 129)
// Output 5: Second asset (checked -- line 130)
// Output 6: Change (checked -- line 134)
// Output 7: Fee (checked -- line 135)

Here is the check for the DCD contract:

// Input 1: First reissuance token (not checked)
// Input 2: Second reissuance token (not checked)
// Input 3: Third reissuance token (not checked)
// Input 4: Settlement asset (checked -- line 269)
// Input 5: Collateral (checked -- line 270)

// Output 1: First reissuance token (not checked)
// Output 2: Second reissuance token (not checked)
// Output 3: Third reissuance token (not checked)
// Output 4: Collateral (checked -- line 262)
// Output 5: Settlement asset (checked -- line 263)
// Output 6: Filler token (checked -- line 265)
// Output 7: Grantor collateral token (checked -- line 266)
// Output 8: Grantor settlement token (checked -- line 267)
// Output 9: Collateral change (checked -- line 272)
// Output 10: Asset change (checked -- line 273)
// Output 11: Fee (checked -- line 274)

With this approach, I do not need to deal with confidential assets at all.

Also, this way there is no place where an attacker could withdraw the confidential tokens (as reissuance assets MUST be confidential), so with this I prove that the reissuance assets are owned by the covenant by the end of the transaction.

[KyrylR]

Also, I forgot to mention that at the top of the contracts I have the following lines:

Options:

assert!(jet::eq_32(jet::num_inputs(), 3));
assert!(jet::eq_32(jet::num_outputs(), 7));

DCD:

assert!(jet::eq_32(jet::num_inputs(), 5));
assert!(jet::eq_32(jet::num_outputs(), 11));

I acknowledge that it hurts UX by requiring users to have change... though for now I do not see another possible fix

IMO this approach gets the job done

[KyrylR]

I am going to merge the PR to make it easier to integrate with Simplicity Dex, though the issue will stay open for further discussion, if any

[roconnor-blockstream]

I would love to make those explicit, but due to the weirdo (maybe not weirdo) check on the node, I have to keep reissuance assets confidential

I believe the proposal in the whitepaper is that we check that the blinded assets on the output are equal to the blinded assets from the input. This sort of defeats the purpose of confidential assets, the only reason these assets are confidential here is because of the strange way asset reissuance works in Elements.

[KyrylR]

Yeah, fully agree.

What I was not able to figure out is how to properly use Elements to construct a transaction in a way that allows me to keep reissuance assets confidential (which actually does not make sense in this case, as to check the commitment in the covenant I need to provide the unblinded reissuance asset id...)

[LesterEvSe]

This is an example of the code we think should be used for verification. What do you think about it, @apoelstra?

fn verify_reissuance_token(index: u32, abf: u256, vbf: u256) {
    let entropy: u256 = unwrap(unwrap(jet::issuance_entropy(index)));
    let (actual_asset, actual_amount): (Asset1, Amount1) = unwrap(jet::output_amount(index));

    match actual_asset {
        Left(conf_asset: (u1, u256)) => {
            let (out_asset_parity, out_asset_x): (u1, u256) = dbg!(conf_asset);            
            let token_id: u256 = jet::calculate_explicit_token(entropy);

            let gej_point: Gej = (jet::hash_to_curve(token_id), 1);
            let asset_blind_point: Gej = jet::generate(abf);

            let asset_generator: Gej = jet::gej_add(gej_point, asset_blind_point);
            let ((ax, ay), az): Gej = asset_generator;
            
            let az_inv: u256 = jet::fe_invert(az);
            let az_inv_sq: u256 = jet::fe_square(az_inv);
            let az_inv_cube: u256 = jet::fe_multiply(az_inv, az_inv_sq);
            
            let calc_ax: u256 = dbg!(jet::fe_multiply(ax, az_inv_sq));
            let calc_ay: u256 = dbg!(jet::fe_multiply(ay, az_inv_sq));

            let calc_out_asset_parity: u1 = match jet::fe_is_odd(calc_ay) {
                true => 0,
                false => 1,
            };

            assert!(jet::eq_256(calc_ax, out_asset_x));
            assert!(jet::eq_1(calc_out_asset_parity, out_asset_parity));

            match actual_amount {
                Left(conf_val: (u1, u256)) => {
                    let (out_val_parity, out_val_x): (u1, u256) = dbg!(conf_val);

                    // Somehow extend u64 to u256
                    let amount_scalar: u256 = 1;

                    let amount_part: Gej = jet::scale(amount_scalar, asset_generator);
                    let vbf_part: Gej = jet::generate(vbf);
        
                    let ((vx, vy), vz): Gej = jet::gej_add(amount_part, vbf_part);
                    let vz_inv: u256 = jet::fe_invert(vz);
                    let vz_inv_sq: u256 = jet::fe_square(vz_inv);
                    let vz_inv_cube: u256 = jet::fe_multiply(vz_inv, vz_inv_sq);

                    let calc_val_x: u256 = jet::fe_multiply(vx, vz_inv_sq);
                    let calc_val_y: u256 = jet::fe_multiply(vy, vz_inv_sq);

                    let calc_out_val_parity: u1 = match jet::fe_is_odd(calc_val_y) {
                        true => 0,
                        false => 1,
                    };

                    assert!(jet::eq_256(calc_val_x, out_val_x));
                    assert!(jet::eq_1(calc_out_val_parity, out_val_parity));
                },
                Right(value: u64) => {
                    panic!();
                }
            };
        },
        Right(asset: u256) => {
            panic!();

            // However, it can be checked using the following code:
            // assert!(jet::eq_256(
            //     asset,
            //     jet::calculate_explicit_token(entropy)
            // ));
        }
    };
}

[apoelstra]

I'm having a bit of trouble following here. Why are the reissuance tokens confidential at all? How can users be assured that all reissuance tokens are controlled by the covenant?

I didn't look too closely at your code but I'm surprised you need to do any field operations. I believe the GejNormalize jet converts a gej to a ge (though this is a weird name for this jet).

I believe that your "compute two points and add" construction can be replaced by an invocation of the linear_verify_1 jet.

[roconnor-blockstream]

The reissuance tokens are confidential because, as I recall, in elements in order to actually reissue tokens the asset must be provided in blinded form.

But AFAIU, we don't need to do any crypto here. Just make sure that the (blinded) reissuance IDs and amounts on the outputs match the (blinded) reissuance IDs and amounts of the input.

[roconnor-blockstream]

Also note, that assets and amounts are separately blinded, and only the asset needs to be blinded for reissuance.

[apoelstra]

The reissuance tokens are confidential because, as I recall, in elements in order to actually reissue tokens the asset must be provided in blinded form.

Yeah, sigh. https://github.com/ElementsProject/elements/blob/master/src/confidential_validation.cpp#L217-L223

I don't know how I wasn't aware of this. It's a super weird design.

Just make sure that the (blinded) reissuance IDs and amounts on the outputs match the (blinded) reissuance IDs and amounts of the input.

A crypto-lite and more flexible thing to do is to subtract the output commitment from the input commitment and check a signature with the result as pubkey (the signature can be on anything, but I guess it ought to cover the two commitments). But this would require wallet support (in principle a single-asset surjection proof is exactly this, but it wastes some bytes on metadata and anyway we don't have jets that can verify such an object).