Was scriptPubKey a mistake?

[lushly]

The original release of Bitcoin included the ability to use arbitrary lock scripts in scriptPubKey, but that ability was relatively quickly limited by introducing the standardness check. While arbitrary lock scripts are still valid from the consensus point of view, you would have to work with a miner to get them included into the blockchain, as only a few standard transaction types will be relayed by nodes in the default configuration.

It is still possible to use custom scripts through P2SH/P2WSH/P2TR. They have significant advantages over placing the unlock conditions in scriptPubKey. So there's no practical issue with the standardness check.

But it does mean that scriptPubKey has effectively become a weird binary format to define several standard transaction types in a very inefficient way. It requires each node to match the script against a few templates to determine what to do with the transaction. It is no longer generic, as some opcode combinations trigger special transaction processing, such as the extraction and additional evaluation of the redeemScript in P2SH.

The same could be achieved by replacing scriptPubKey with an enum field for output type and a payload field for details. It would slightly decrease transaction size and computation requirements to verify it. It would also make building applications that interact with the blockchain easier, since developers would no longer have to implement nonstandard transaction handling. One could be certain that if a transaction doesn't have a destination address, it's P2PK, bare multisig or OP_RETURN. No other options would be possible.

E. g. if output type is 1 (for P2PKH), the payload field contains a 20-byte key hash. Assuming that the output type field takes 1 byte, this saves 4 bytes per a P2PKH output. The opcodes OP_DUP OP_HASH160 OP_PUSHBYTES_20 OP_EQUALVERIFY OP_CHECKSIG are all replaced with output type.

If output type is 2 (for P2SH), the payload is a 20-byte redeemScript hash. We save 2 bytes per P2SH output. And so on.

I understand that such an upgrade would require a hard fork, and we don't do that in Bitcoin. However if that was somehow no longer a limitation, e. g. if Bitcoin was invented today, would removing scriptPubKey be the right thing to do? Are there any upsides to the current situation other than that it's what we have?

(I'm sure this question has been asked many times before, but I couldn't find much info by searching.)

[Faisal2202]

Hmm... I don't think this question has arisen before, so you want to replace the current scriptPubKey system with a different system like another field "enum" to identify the nature of the tx, well, I just read that in terms of scriptPubKey, segwit V1 is better in consolidation phase and in larger tx the Segwit V0 is better.  So, let's say we did a hard fork which is a little impossible (difficult) at the moment, and a new system has been implemented.

Are you certain that the Segwit V0 and Segwit V1 will be working on them? Just a thought. This upgrade of your can also cause further standardization issues in the future as well. I don't know much but what you think I think you have better idea.

[vjudeu]

I understand that such an upgrade would require a hard fork, and we don't do that in Bitcoin.

Not really, because you can locally store your data in whatever format you want. So, if you create a converter between the original format, and your own format, then it could be fine, without any hard-fork.

if Bitcoin was invented today, would removing scriptPubKey be the right thing to do?

Maybe, but not in the way you think. In general, if you read the whitepaper, then it describes only one address type: P2PK. And also note that you can get all address types behind nothing more than a public key, if you use the latest address type, which is P2TR.

Which means, that if we would have P2PK, and nothing else, then other address types could be added behind a regular signature. Which means, that the first version could allow only public keys and signatures, but some later upgrade could add Script into the whole equation, while keeping it committed to the public key, and while still requiring a valid signature (and also a valid script, just like P2SH was added, to require not only a valid stack push, but also executing it).

E. g. if output type is 1 (for P2PKH), the payload field contains a 20-byte key hash. Assuming that the output type field takes 1 byte, this saves 4 bytes per a P2PKH output. The opcodes OP_DUP OP_HASH160 OP_PUSHBYTES_20 OP_EQUALVERIFY OP_CHECKSIG are all replaced with output type.

If output type is 2 (for P2SH), the payload is a 20-byte redeemScript hash. We save 2 bytes per P2SH output. And so on.

If your main goal is just data compression, and nothing else, then it would be a no-fork. Which means, that you don't even need a soft-fork to do that, but you can implement your own version, without asking anyone for permission. The only reason, why standardization would be a good idea, is to improve performance, and exchange data between new nodes in a new format, without the need of constantly converting it back and forth.

Some article with similar ideas: https://www.truthcoin.info/blog/small-txns/
My previous post about it: https://bitcointalk.org/index.php?topic=5326218.msg56641996#msg56641996

[lushly]

Are you certain that the Segwit V0 and Segwit V1 will be working on them?

Sure, why not? Those would become another enum value each. E. g. output type 4 is for P2WPKH, the expected payload is a 20-byte key hash. Output type 5 is for P2WSH, the expected payload is a 32-byte witness script hash.

Not really, because you can locally store your data in whatever format you want. So, if you create a converter between the original format, and your own format, then it could be fine, without any hard-fork.

That wouldn't achieve much, though. I'm talking about the format that Bitcoin nodes use to exchange data. Also, not all transactions that exist on the current blockchain can be serialized that way. More explicit standardization would be one of the goals for this change; it can't be achieved by a client-side implementation.

Maybe, but not in the way you think. In general, if you read the whitepaper, then it describes only one address type: P2PK. And also note that you can get all address types behind nothing more than a public key, if you use the latest address type, which is P2TR.

Both P2PK and P2PKH were available in the first released version of Bitcoin, see this message.

Which means, that if we would have P2PK, and nothing else, then other address types could be added behind a regular signature. Which means, that the first version could allow only public keys and signatures, but some later upgrade could add Script into the whole equation, while keeping it committed to the public key, and while still requiring a valid signature (and also a valid script, just like P2SH was added, to require not only a valid stack push, but also executing it).

I'm not sure what you mean? Bitcoin script was available from the beginning. There was never a transaction type that wouldn't use script.

If your main goal is just data compression, and nothing else, then it would be a no-fork. Which means, that you don't even need a soft-fork to do that, but you can implement your own version, without asking anyone for permission. The only reason, why standardization would be a good idea, is to improve performance, and exchange data between new nodes in a new format, without the need of constantly converting it back and forth.

If it somehow became the standard way of storing transactions, block size and fees would be calculated based on transaction size serialized this way. Which means more transactions in a 1MB block and lower fees.

[vjudeu]

That wouldn't achieve much, though. I'm talking about the format that Bitcoin nodes use to exchange data.

New nodes could use the new format to exchange data. Obviously, old nodes should stay where they are, because in other cases, it would be a hard-fork.

Also, not all transactions that exist on the current blockchain can be serialized that way.

Could you provide any Script, that cannot be converted into TapScript, and committed to some public key?

it can't be achieved by a client-side implementation

Why not? It is the first step, to use it locally, and show some statistics, for example: "In this new model, the size of the chain is reduced by 20%". Also, there are many reasons to apply it locally, for example to allow improving compression algorithms over time, without forking the network with each proposed upgrade.

Both P2PK and P2PKH were available in the first released version of Bitcoin

I know that they were. But note that P2PKH could be wrapped into P2PK, if needed. And the same with every other Script. Your question was "if Bitcoin was invented today", and not "if Bitcoin was released with two standard address types". Because if I would want to release some new altcoin today, then I probably wouldn't add "pubkeys behind hashes", but everything would be committed to the public key instead, similar to how P2TR works (but probably with prefixes like 02 and 03 for all public keys, including signature R-values).

I'm not sure what you mean? Bitcoin script was available from the beginning. There was never a transaction type that wouldn't use script.

Again, you asked about doing things from scratch, not about keeping it compatible with the current model.

If it somehow became the standard way of storing transactions, block size and fees would be calculated based on transaction size serialized this way. Which means more transactions in a 1MB block and lower fees.

1. If you want to make it a no-fork, then everything should be still calculated, based on the old format.
2. Changing fees does not require touching consensus rules, so it is possible to lower fees, without touching the block size limit.

[NotATether]

I understand that such an upgrade would require a hard fork, and we don't do that in Bitcoin.

Not really, because you can locally store your data in whatever format you want. So, if you create a converter between the original format, and your own format, then it could be fine, without any hard-fork.

It would have been possible to add an optimization for P2PKH by adding just one byte at the beginning that indicates P2PKH script, and the include the script hash, to save about three bytes. However, the existence of segwit precludes this fix so it will probably never get optimized out as developers have basically deprecated legacy addresses.

[lushly]

Could you provide any Script, that cannot be converted into TapScript, and committed to some public key?

A Taproot output requires a witness program to unlock. If we're talking about serializing existing spent outputs (historical data), converting them into P2TR would make their spending transactions invalid, as most of them weren't (and couldn't be) unlocked using a TapScript witness. You can't change the scriptSigs on the inputs either (or convert them into witnesses), since you don't have the private keys used to sign them. So by doing that, you would make it impossible to verify the integrity of the blockchain.

I know that they were. But note that P2PKH could be wrapped into P2PK, if needed. And the same with every other Script. Your question was "if Bitcoin was invented today", and not "if Bitcoin was released with two standard address types". Because if I would want to release some new altcoin today, then I probably wouldn't add "pubkeys behind hashes", but everything would be committed to the public key instead, similar to how P2TR works (but probably with prefixes like 02 and 03 for all public keys, including signature R-values).

Oh, I see what you mean now. If P2PKH used Schnorr signatures to begin with, it would be possible to preserve the uniform output format and just add new types of scriptSig/witness later. Sure, this might be a better option. You would still have to discern between the different input types, same way Taproot uses different validation algorithms depending on witness length. This basically moves the enum into the input, so until an output is spent, an external observer wouldn't know what kind of transaction it is, or whether it is even spendable.

2. Changing fees does not require touching consensus rules, so it is possible to lower fees, without touching the block size limit.

The fees depend on how many transactions can fit inside the block. If we could make transactions smaller, it would automatically lower the fees (given constant demand). Same way SegWit did.