Make bitcoin-util evalscript functionality available as library call

[ajtowns]

From bitcoin#29189 (comment)

Would something along the lines of https://github.com/ajtowns/bitcoin/commits/202309-evalscript/ be an interesting alternative?

For my part I would rather have a library function than a CLI tool.

Is having functionality like this available as a library function worth exploring as a feature in inquisition, to potentially eventually upstream to core?

The evalscript subcommand takes the following options:

• script
• arguments
• script_flags (array of strings matching core's internal SCRIPT_FLAG_* names)
• sigversion (base, witness_v0, tapscript, representing the different script versions supported)
• spent_output, tx, input, ipk (data about the tx that can be introspected in some way via signature operations)

It outputs a json object that looks like:

{
  "script": {
    "asm": "1 1 OP_ADD",
    "hex": "515193",
    "type": "nonstandard"
  },
  "sigversion": "witness_v0",
  "script_flags": [
    "CHECKLOCKTIMEVERIFY",
    "CHECKSEQUENCEVERIFY",
    "DERSIG",
    "NULLDUMMY",
    "P2SH",
    "TAPROOT",
    "WITNESS"
  ],
  "stack-after": [
    "02"
  ],
  "sigop-count": 0,
  "success": true
}

If it is interesting to make this available via a library, what should API look like? Should it be C++ or C?

[ajtowns]

cc @apoelstra

[apoelstra]

We'd definitely prefer C to C++. And yes, I think this would be super useful and replace the primary (only?) usecase for rust-bitcoinconsensus. Though if it were in -inquisition rather than Core itself... hard to say how people would feel about that. I've never needed this functionality personally.

And passing transaction data directly in, rather than having to marshall the whole transaction into a bytestring that the C code reparses, is even nicer.

[ajtowns]

I was thinking develop it in -inquisition then merge it into core once we've got something we like.

And passing transaction data directly in, rather than having to marshall the whole transaction into a bytestring that the C code reparses, is even nicer.

I don't understand? The C++ code would want CTransaction which is a C++ class based on std::vector and the like, so if we're exposing it via a C library, I don't see how you'd pass that data around without marshalling (on the caller side) and reparsing (on the C++ side)?

I think rust-bitcoinconsensus's API is just:

verify (spent_output_script: &[u8], amount: u64, spending_transaction: &[u8], input_index: usize) -> Result<(), Error>

Do we want to just start with duplicating that, or some other API?

[apoelstra]

Oh, I misunderstood you. When you said it "takes the following options" I missed that the transaction was just one object and everything else was non-transaction data. In my head you were somehow breaking the transaction up into version, sequence, inputs and outputs.

In practice I think doing this would be a really messy proposal and probably not even simpler than using the existing API.

Do we want to just start with duplicating that, or some other API?

Yeah, I would say we should start by just duplicating that.

[ajtowns]

evalscript as it stands does have separate arguments for the script, witness, internal pubkey and sigversion that would normally be determined by the tx/input index/scriptpubkey, which makes things easier for experimentation than having to bake them back into the transaction, so that might be what led you think that way?