I was referring to the human factor in communicating to your cosigners your master public keys.
Forgive me because I didn't really do a thorough reading on TapRoot or Schnorr for that matter. With key aggregation, is it still possible to derive the individual public keys used for the transaction using the single public key revealed in such a transaction? My understanding that the individual public keys are not known but only the aggregated key will be within the script.
But again, it does make sense if the aggregated public key can be used to obtain something that can still be used to sign transactions to produce a valid signature. Please CMIIW.
To be honest I have no idea if one of the public keys can be retrieved from an aggregate public key, according to the MuSig
whitepaper you need to find the reverse of the formula on page 12.
I don't think that the aggregated public key by itself will be helpful to an adversary though, or an aggregate with too few private keys of the co-signers.
So the question is now, how practical it is for an adversary to compute the list of all bitcoin addresses with a balance [and actually they don't even have to do that, as LoyceV already has such a list] and then given that there are millions of addresses, they still need thousands of compute minutes to crack them all, depending on the average number of transactions in a block.
do you mean trying to guess a private/public key pair and hoping to have gotten one with funds?... if so, why are you referring to number of transactions in a block?
Let's say the adversary wants to steal all the outputs from the transactions on a particular day. They need to know the average number of transactions in a block and that'll give them a rough idea of how many private keys need to be cracked (notwithstanding some transactions have outputs from multiple addresses/private keys), so they can calculate how much computing power they need to crack that many private keys in 10 minutes, the average block creation time.
I'm assuming an attacker is more interested in active addresses than dormant ones, though they will probably get the dormant addresses first because even if you have the private key to someone else's address, if they are moving some coins in an unconfirmed non-RBF transaction then you need to also gain control of a majority of the hashrate, a politically impossible task. Dormant addresses aren't moving anything anywhere.
I cannot understand your attack-scenario:
1) why an attacker should be more interested in active addresses than dormant ones? (I think to early times dormant P2PK with a lot of value)
2) why attacker needs to control hashrate? I suppose the attacked wouldn't have knowledge of being attacked until it sees the malicious transaction in mempool, and if that transaction is a non-RBF one, it would be included in a block as a normal transaction without possibility to block it (unless the
attacked can control the hashrate): so hashrate indipendence seems more a feature than a problem for an attacker who has discovered a someone else private key
To 1), I did admit that they would target dormant transactions first, I was just outlining how an attack against addresses with unconfirmed outputs would work.
To 2), it is only necessary to control hashrate if the attacker also wants to steal the unconfirmed outputs in the address as well. This is so they can block the transaction that's taking the outputs away and create their own transaction (normally this isn't possible with a 51% majority but in this case they also have the private keys) to send the unconfirmed bitcoins to their own address.
Because of this, if all addresses were constantly on the move and that all addresses were made to send their entire balance to some empty addresses, then the threat of widespread cracking of private keys is mitigated.