Bitcoin wire format rigidity

[kantai]

From @lgalabru:

I keep wondering if the rigidity of our expectations, when diving into the outputs of a BTC transaction, is a good thing or not (the order, the total count, etc).
I understand that it simplifies the retrieval, but there are 2 downsides that I can think about:

• Combining Stacks mining / support with BTC transactions: transaction's costs are rising, BTC fee costs of Stacks mining could be amortized if the transaction could be used for something else.
• Combining / Multiplexing Stacks protocols with other protocols: can we / what kind of meta-protocols can be built by combining some Bitcoin protocols (Stacks, Lightning, wBTC, etc).

I agree with the above, and think there's some ways we can explore to reduce this rigidity. I think for things like the total count of outputs and the order of them, there's a good reason for doing this beyond simplicity (we want all transactions to cost the same whether they are burns or PoX transfers: we shouldn't favor one over the other).

Another option for the UTXO chaining requirement is performing Bitcoin signature validation in the stacks-node itself, rather than relying on bitcoind's own validation. That's probably easier said than done, but it's definitely possible.

[jcnelson]

Another option for the UTXO chaining requirement is performing Bitcoin signature validation in the stacks-node itself, rather than relying on bitcoind's own validation. That's probably easier said than done, but it's definitely possible.

Can you elaborate on this idea?

[kantai]

Yeah -- the thing we would need to do is identify that the scriptSig is in a format that we understand, for example, we could see a script that looks like:

<signature> <pubkey>

And assume that the spent output is the normal p2pkh script (we'd compute the hash160 of the pubkey ourselves). Then, we'd need to actually perform the Bitcoin signature validation on the transaction as if this were the case. If it passes the signature validation, then we can associate the transaction with that pubkey.

We could perform similar validation for other standardized script types.

[jcnelson]

We may need to bump this to stacks 2.1

[jcnelson]

A really simple way to remove the pain from this is to increase the window of consideration for a PreStxOp and similar SIP-007 on-Bitcoin operations to 5 blocks, instead of 1 block.