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.

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.

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.

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.


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.

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


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 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.

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.)

I recently found out about CoinShuffle++, and it seems really interesting. However the only implementation I could find that is still active is the one by Decred. It makes a few modifications to the protocol. Namely they use DiceMix Light with a centralized server and ephemeral peer session keys (as stated on GitHub). Their docs state that it's okay, since "CSPP ensures anonymity even while trying to join a session hosted by a malicious server." Could you please clarify if that statement is still true given their modifications? I don't see how it could be.

If my understanding of the paper is correct, a malicious server could perform an active MITM attack on the key exchange between the peers and later learn the contents of all the messages they exchange. However to do so the server would have to impersonate each of the peers using a fake signing key. Since that key no longer corresponds to an actual UTXO on the blockchain, the peer that is being impersonated would be unable to produce a valid transaction signature using the signing key which the other peers expect. This leads to confirmation failing, so no anonymity is lost.

But if one used ephemeral keys, this is no longer a limitation. Am I missing something, or is there nothing stopping the server from performing this attack undetected?