Quote from: piotr_n on Today at 01:44:22 PM

Am I getting it wrong thinking that "schnorr" is just an improved way of doing EC signatures, while "taproot" is an extension to the scripts interpreter?

Because reading some publications (and this forum topic), one could get an impression that schnorr and taproot are synonyms, whilst for me they are two different features. Although, I understand that they are planned to be deployed and activated together.

Schnorr without taproot isn't really that useful: it makes it simpler and safer to write threshold signatures but that's it-- you can already threshold signatures using burdensomely complicated client software. And threshold signatures by themselves don't even do that much-- they let you make signatures somewhat smaller but only when you don't need to be able to tell which parties signed. It's better --- but perhaps not worth the trouble of a consensus change by itself.

Taproot without schnorr isn't really that useful: without threshold signatures, which are burdensomely complex to write software for without schnorr, it only lets you have a single party key at the top (which is pretty useless.)

There is a third logical part of taproot, which is the merkelized script. This part is probably the most useful of the three on its own, but it's much more useful in combination. With it you can use trees of N of Ns to make thresholds work usefully even when you need to be able to tell which parties signed, and N of Ns are much easier to deal with than arbitrary thresholds, because the latter requires interactive secret key generation.

In order to have the property where arbitrary complex scripts are normally indistinguishable from one-of-one payments you need all three. They also can't just be independently implemented: taproot changes the pubkey that goes into schnorr verification to commit to the merkelized script.

There were other techniques proposed, including graftroot (allows you to add scripts to an output after someone has already paid to it), and improved signature flags-- but those were possible to implement independently without leaving the rest not very useful. There were also a number of next steps like signature aggregation which would have been best implemented in combination but were still left out because the three main features of the taproot bip were still useful without it.

Quote from: piotr_n on Today at 12:32:11 PM

I only found test vectors in bip340_test_vectors.csv - but they seem to be only checking sign_schnorr() and verify_schnorr() functions.
Are there any new test for entire scripts and transactions?

Looks like all the new testing is done with the python framework. I'll prod Pieter to add old style vectors.