bip-0375: replace bare OP_2 vector with an in-progress PSBT #2315

The valid test vector "bare OP_2 script is not a segwit v2 witness program" (added in #2253) passes only because its checks field limits it to the input eligibility check: its only input is not eligible, so the output scripts check fails. This replaces it with the vector @macgyver13 proposed below, which adds an eligible P2WPKH input carrying the ECDH share and DLEQ proof, keeps the bare OP_2 input with only PSBT_IN_NON_WITNESS_UTXO, and needs no checks.

The bare OP_2 input is unsigned, so the vector is In Progress; its row goes in the Valid PSBTs table at its position in the JSON file. #2316 re-signs the bare OP_2 vector this PR replaces, so the two conflict there: whichever lands second drops that vector when it rebases. A separate commit sets Version 0.1.4 with its changelog entry: each of my open BIP-375 pull requests (#2315, #2316, #2317, #2324) does the same, and whichever lands first keeps 0.1.4 while the others rebase to the next version.

Made with my usual tools: a computer, the Internet and an LLM. The mistakes, as usual, are all mine.

cc: @macgyver13

ACK

Thanks for catching the missing row. I agree the table should be complete, but I prefer to modify the vector from #2253 rather than add a category for it.

The vector "input eligibility: bare OP_2 script is not a segwit v2 witness program" only passes because checks limits it to input_eligibility. Its only input is the bare OP_2, which is not eligible. Additionally, PSBT_OUT_SCRIPT is set for the silent payment output, but BIP-352 derives that script from eligible inputs, and BIP-375 requires an ECDH share from each of them. With no eligible input, no valid PSBT_OUT_SCRIPT can exist, and the ECDH share on the OP_2 input does not count. It passes the segwit version rule, but it is not a valid silent payment PSBT.

Adding an eligible P2WPKH input that carries the ECDH share removes the need for checks and keeps the intent of the vector. The bare OP_2 input only has PSBT_IN_NON_WITNESS_UTXO, and since #2310 the segwit version check reads that field, so the vector still exercises the #2253 fix.

This new vector should go under In Progress, since the bare OP_2 input has no signature or PSBT_IN_FINAL_SCRIPTSIG. No new category is needed. The new row belongs just before "large PSBT with nine mixed inputs / six outputs - some inputs signed", which matches its position in the vector file.

Would you be willing to change the scope of #2315 to replace the #2253 vector with this one, or something like it, and add its In Progress row? Happy to open it separately if you would prefer.

<details> <summary>Proposed vector</summary>

{
  "description": "in progress: two mixed input types - only eligible inputs contribute ECDH shares (bare OP_2 excluded, not a segwit v2 witness program)",
  "psbt": "cHNidP8BAgQCAAAAAQQBAgEFAQEBBgEAAfsEAgAAAAABAR+ghgEAAAAAABYAFB4q14ctMpQTpW3wlovjOCIngxY7IgICyBe7dSGvw16pbzv7Jw5utQ3f+lVgYnuWH+wA8pllCL9HMEQCIBSy+IcHY6e2PvAVl0Nn5/k33wSx/IHSeS9IBgdqhovMAiAaQaLb0ZFUbVChPrPpzNJlrAkTgwuuSsDLkr6rKWzMmQEBAwQBAAAAIgYCyBe7dSGvw16pbzv7Jw5utQ3f+lVgYnuWH+wA8pllCL8IAAAAgAAAAAABDiD3Tt0fdbS7Pl10nBW/22Y0j2gFqbTUX+7houIB9QO7cQEPBAAAAAABEAT+////Ih0Cekh/wZ+3aYd7h0LW6hgRjzxOcrHqjG3mAqetSkHb4GghA+yk/xG3KOLg9gzmIilDpv9VudlfYnv5qZ0IS8hy1QpbIh4Cekh/wZ+3aYd7h0LW6hgRjzxOcrHqjG3mAqetSkHb4GhAihOzmFVF9yvW6JcUrrkJs+NUqEKpu4tWzQ7e0h34oZlZizEiikngvX6VzhBT98WyistUOmhwdgDjzomCLuMgIQABAD0CAAAAAc+Yjtd5Ul1URcuaoVBLXR9poD9LJFCgdgM11F8uiiWkAAAAAAD/////AfBJAgAAAAAAAVIAAAAAAQ4gVNtzmS5x6dVs2BAO0w7bVdDozw7SVKANTvg6yrRtoloBDwQAAAAAARAE/v///wABAwgIvQMAAAAAAAEEIlEgqSpj6dcCLqOvqZpw8ABEi7toRks0RksXO7Jvx2VRRJgBCUICekh/wZ+3aYd7h0LW6hgRjzxOcrHqjG3mAqetSkHb4GgDYeGx6d5eQssgB/fKVLng1X7ROTj61W0/GeV1E6j84DkA",
  "supplementary": {
    "inputs": [
      {
        "input_index": 0,
        "private_key": "7e31eeeb1aa2597b6d63b357541461d75ddae76b7603d24619f5ebed9e88ec31",
        "public_key": "02c817bb7521afc35ea96f3bfb270e6eb50ddffa5560627b961fec00f2996508bf",
        "prevout_txid": "71bb03f501e2a2e1ee5fd4b4a905688f3466dbbf159c745d3ebbb4751fdd4ef7",
        "prevout_index": 0,
        "amount": 100000,
        "non_witness_utxo": "020000000118a717663b0bab14b12a1a771323ff1e4079dd532e5dd13e28ea1081c700984a0000000000ffffffff01a0860100000000001600141e2ad7872d329413a56df0968be338222783163b00000000",
        "witness_utxo": "a0860100000000001600141e2ad7872d329413a56df0968be338222783163b",
        "sequence": 4294967294,
        "signed": true
      },
      {
        "input_index": 1,
        "private_key": "",
        "public_key": "",
        "prevout_txid": "5aa26db4ca3af84e0da054d20ecfe8d055db0ed30e10d86cd5e9712e9973db54",
        "prevout_index": 0,
        "amount": 150000,
        "non_witness_utxo": "0200000001cf988ed779525d5445cb9aa1504b5d1f69a03f4b2450a0760335d45f2e8a25a40000000000ffffffff01f049020000000000015200000000",
        "sequence": 4294967294,
        "signed": false
      }
    ],
    "sp_proofs": [
      {
        "scan_key": "027a487fc19fb769877b8742d6ea18118f3c4e72b1ea8c6de602a7ad4a41dbe068",
        "ecdh_share": "03eca4ff11b728e2e0f60ce6222943a6ff55b9d95f627bf9a99d084bc872d50a5b",
        "dleq_proof": "8a13b3985545f72bd6e89714aeb909b3e354a842a9bb8b56cd0eded21df8a199598b31228a49e0bd7e95ce1053f7c5b28acb543a68707600e3ce89822ee32021",
        "input_index": 0
      }
    ],
    "outputs": [
      {
        "output_index": 0,
        "amount": 245000,
        "sp_v0_info": "027a487fc19fb769877b8742d6ea18118f3c4e72b1ea8c6de602a7ad4a41dbe0680361e1b1e9de5e42cb2007f7ca54b9e0d57ed13938fad56d3f19e57513a8fce039",
        "script": "5120a92a63e9d7022ea3afa99a70f000448bbb68464b34464b173bb26fc765514498"
      }
    ]
  }
}

</details>

@macgyver13: You seem to have a concrete idea how you would like this issue to be solved and seem to have described it in enough detail that you could have just opened your own PR with a similar effort. Please feel free to open alternative PRs for any of the open BIP375 issues, if you feel that it is less work for you to create a pull request yourself instead of walking another author through your preferred fixes.

@twisredcrafts

@Twistedcrafts

Thanks, I changed the scope as you proposed: your vector replaces the #2253 one unchanged, with its In Progress row just before the large PSBT, and the Input Eligibility category is gone. It passes all four checks with no checks field, and it fails under the segwit version test from before #2253, so it still covers that fix.

ACK ec7f9b4

Thank you!