Return to Answer

I think that the correct way to store a key pair is to keep complete information about it. There isn't any need to negate if a correct key is given.

A key is manipulated/altered/modified/composited/tweaked independently of the operation of negation described in the BIP340-342.

I think that the quote ("may need to") supports that position:

Note that because tweaks are applied to 32-byte public keys, taproot_tweak_seckey may need to negate the secret key before applying the tweak.

https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

In other words, above mentioned negating should not be mixed with other operations. Also, the negation is not necessary when you have complete information about keys being used. In short, never negate unless you don't know which one out of two keys is correct/actual one.

I think that the correct way to store a key pair is to keep complete information about it. There isn't any need to negate if a correct key is given.

A key is manipulated/altered/modified/composited/tweaked independently of the operation of negation described in the BIP340-342.

I think that the quote ("may need to") supports that position:

Note that because tweaks are applied to 32-byte public keys, taproot_tweak_seckey may need to negate the secret key before applying the tweak.

https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

In other words, above mentioned negating should not be mixed with other operations. Also, the negation is not necessary when you have complete information about keys being used. In short, never negate unless you don't know which one out of two keys is a correct/actual one.

I think that the correct way to store a key pair is to keep complete information about it. There isn't any need to negate if a correct key is given.

A key is manipulated/altered/modified/composited/tweaked independently of the operation of negation described in the BIP340-342.

I think that the quote ("may need to") supports that position:

Note that because tweaks are applied to 32-byte public keys, taproot_tweak_seckey may need to negate the secret key before applying the tweak.

https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

In other words, above mentioned negating should not be mixed with other operations. Also, the negation is not necessary when you have complete information about keys being used. In short, never negate unless you don't know which one out of two keys is correct.

I think that the correct way to store a key pair is to keep complete information about it. There isn't any need to negate if a correct key is given.

A key is manipulated/altered/modified/composited/tweaked independently of the operation of negation described in the BIP340-342.

I think that the quote ("may need to") supports that position:

Note that because tweaks are applied to 32-byte public keys, taproot_tweak_seckey may need to negate the secret key before applying the tweak.

https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

In other words, above mentioned negating should not be mixed with other operations. Also, the negation is not necessary when you have complete information about keys being used. In short, never negate unless you don't know which one out of two keys is correct/actual one.

I think that the correct way to store a key pair is to keep complete information about it. There isn't any need to negate if a correct key is given.

A key is manipulated/altered/modified/composited/tweaked independently of the operation of negation described in the BIP340-342.

I think that the quote ("may need to") supports that position:

Note that because tweaks are applied to 32-byte public keys, taproot_tweak_seckey may need to negate the secret key before applying the tweak.

https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

In other words, above mentioned negating should not be mixed with other operations. Also, the negation is not necessary when you have complete information about keys being used.

I think that the correct way to store a key pair is to keep complete information about it. There isn't any need to negate if a correct key is given.

A key is manipulated/altered/modified/composited/tweaked independently of the operation of negation described in the BIP340-342.

I think that the quote ("may need to") supports that position:

Note that because tweaks are applied to 32-byte public keys, taproot_tweak_seckey may need to negate the secret key before applying the tweak.

https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

In other words, above mentioned negating should not be mixed with other operations. Also, the negation is not necessary when you have complete information about keys being used. In short, never negate unless you don't know which one out of two keys is correct.