schnorr signatures – Taproot, potential quantum bug, and general clarification

Here seeking information. I have 4 questions marked with parens

Would like some clarification pertaining to the Mark Friedenbach article:

The point of contention with Mark seems to be the idea of the space savings for the N-N Musig2 everyone signs/happy path being embedded into the the root of the MAST/Taproot?

(1) please correct if I’m wrong about the way I’m describing this.

I did see Pieter’s presentation at Bitdevs from a while back reference, “plain pubkey security model in mind” for taproot. But, it wasn’t apparent that this would hypothetically make it quantum vulnerable,.. as Mark’s article says, “a naked secp256k1 pubkey on chain at the time the output is created which has absolute spend authority for the underlying bitcoins”.

(2) Would love for someone to rebut or verify this claim.

From what I’ve gathered.. Taproot is a combination of Schnorr, MAST, Musig, etc.. but the exact, small piece of all of this, which is “Taproot”, is explained by 3 fellows as:

  • Greg, “a special delegating CHECKSIG which I call Taproot.”
  • Poelstra, “trick to hide a commitment inside a pubkey”
  • Pieter, “pay to a script pubkey of taproot EC point P.”

(3) Are these accurate concise snippets for the crux of Taproot, which is we don’t need a separate branch for the N-N everyone agrees spend?

(4) Also, is OP_CHECKSIGADD the now realized “CHECKSIG” greg mentions in the O.G. taproot post

segregated witness – Are high-s ECDSA signatures forbidden in segwit witnesses?

I must have looked that up five times by now, but did segwit actually forbid high-s ECDSA signatures in witnesses, esp. in standard single-sig constructions such as P2SH-P2WPKH or P2WPKH? Or are high-s signatures still only non-standard even in segwit inputs?

(I’m aware that the transaction malleability problem due to low-s/high-s is mitigated by moving the signature into the witness, that’s not my question.)

How can digital signatures assure the sender their message has been correctly received?

PKI ensure that if the message reaches its destination it has not been altered (if signed with sender private key) and/or has not be compromissed (if crypted with recipient public key).

If the sender wants to make sure that the recipient has actually received the message, a higher level protocol must be used. For example the recipient could send a signature of the original (optionaly decrypted) message using their private key. So if the round trip:

A -> message signed with A private key -> B
A <- signature of the original message with B private key <- B

completes, then A can be sure that B has received the correct message.

If you do not set up that round trip, even with modern system where the sender can be sure that the message reaches the recipient system, you have no protection against the message being destroyed between its arrival on a machine and the moment when the human being named B could read it.

This would be more or less an implementation of what was the QSL in the early days of radio frequency message (mainly using Morse code). BTW that QSL was still in use in the 80’s to ensure that a message had been received and understood (*): until the sender had not received a QSL to message number xxx they periodically try to send it again or try a phone call to know whether the recipient system was off or out of use (at least at French Met Office).


(*) as QSL to message … had to be manually sent, it meant that somebody could read the message number and declared having understanded the full message.

Is it possible to create a webform that requires multiple signatures from people in different departments?

If so, is there a video or how do I set it up? Is there a way to allow webform submissions to be edited by the person who submitted them?

2 Passports with different signatures

I recently noticed that I have different signatures on both of my passports. I acquired my 2nd passport for eligibility to stay at a foreign country to study in a long term. I would like to visit where I was originally from but am afraid if Customs will question my signatures on both of my passports. Will this cause any trouble when travelling? Thank you for your help!

key management – How to export all local signatures

I have 2 separate keyrings and would like to transfer all public keys and the corresponding signatures I have made to my other key.

~ 10 years ago I created a Master key on an offline computer with both a signing and encryption subkey.

I ended up not using the subkey because I started using gpg4win on an online computer with a different keyring and have since collected > 40 signatures and locally signed them all.

I would like to now start using my old key that has been offline for 10 years however I do not want to rebuild all of the public keys I have collected and signed.

I think the best thing to do is to export all the public keys with a local signature and then with the offline key ultimately trust my gpg4win key. Then generate a revoke certificate for the online gpg4win key and stop using it.

the gpg --exportcommand doesn’t seem to let me export ALL of the public keys.

Please let me know your thoughts and/or if there is a more elegant solution to transfer my keyring to my old, offline, key.

Random Number for Transaction Signatures In R Values , how It is created?

I wonder about the random Number used in signatures that result in R values ?
xcoridnate R = G(k)
how it is created ? does it have specific chars length ?
Is there a specific Random generator Used ? or restriction Arguments ?
I saw A Python Code online and found It is limited to max number of field points
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
but as it is in hex format i didn’t know what does it mean
so wat is the max number to be used as it will processed as an integer

hash – Why there is nothing that automatically checks signatures or checksums of files downloaded in browsers?

There is such a mechanism – Subresource Integrity. It allows a web site to specify a checksum for any <script> or <link> element on the page, where the link being provided presumably points off to a CDN, or a partner site, or some other resource that the main web page source doesn’t have control over. You can learn how to use it here.

It wouldn’t make sense in the normal context of pages being provided by a single site, because if the download from the site might be untrustworthy, so would any checksum provided by that site. It’s used where there’s a demarcation of trust between the page being loaded and the subresources that that page loads.

Are Digital Signatures tuned to become harder as computers become faster?

For example, how long does a typical CPU take to verify a single secp256k1 signature? Wouldn’t this need to change in time so that signatures can’t be brute forced? How is it decided how "strong" the signature verification should be?

schnorr signatures – In MuSig-DN why not use a truly random number for the nonce instead of a pseudorandom function?

This question was answered by Tim Ruffing on Twitter.

The answer is simply that it’s not easy to get truly random numbers
right in practice. For example, you need to collect entropy in your
system, and it’s hard to write a “test” that checks if your numbers
are really random.

Broken random number generators have led to numerous real-world
failures e.g.

Random Number Bug in Debian Linux

and

https://arstechnica.com/information-technology/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/

So it’s better to simply avoid real random number generators in
practice, and this is well-established best practice for “normal”
single-singer signatures (Schnorr sigs, ECDSA). MuSig-DN makes this
possible for multisignatures, too.

But your point is correct in theory. If you have a working source of
truly random numbers, this will just do the job.

Pieter Wuille and Jonas Nick added on Twitter:

A working source of random numbers and a place to keep them securely
and tamper-proof between the rounds of the signing process.

Or just a place, to keep a counter securely and tamper-proof between
the signing sessions. Ideally combined with an RNG.

But that is also true for the generation of the private key and we tolerate that there?

Perfectly right, yes. I think the answer here is two-fold:

  1. We can at least try to avoid real numbers as much as possible. Even for key
    generation, we can derive all keys from a single seed, and then we
    really rely on randomness only once in the life of a wallet for that
    seed

  2. It seems that the randomness is particularly brittle when it comes
    to nonces used in signatures. For example, if you fix a single bit in
    the nonce, then a few signatures may already be enough to derive the
    secret key.