C'est tout à fait vrai: toutes les transactions ne sont pas des "pay-to-hash", on peut aussi payer une clé publique directement (comme dans une coinbase transaction).
Donc en toute rigueur, l'entropie (si on utilisait que des transactions "pay-to-public-key") est celle de l'espace de clés publiques, c'est à dire l'ordre du champ fini utilisé dans ECDSA version Bitcoin.
Pour rappel , l'ordre de ce champ est (en notation hexa)
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE BAAEDCE6AF48A03BBFD25E8CD0364141
soit, en décimal (si ma conversion est correcte):
115792089237316195423570985008687907852497281912153965919141788534086393282883 > 1077
L'entropie des clés privées est donc très supérieure à 2160 mais, pour en bénéficier à plein, il faut recevoir ses fonds sur des clés publiques et non sur des adresses.
Je ne peut que agrée a ce calcul mais pour être complet il faut tenir compte du Aléa.
Une clef public ECDA plus elle est utilisé permet des attaques par rejeux ( voir les hack PS3 pour exemple )
Pour ceux qui n'ont pas compris en quoi une depense change la donne .
Recevoir des bitcoin sur addresse n'est pas recevoir des bitcoin sur une clef public .
Quand vous dépensez cette argent vous apporter aussi la connaissance de la clef public correspondant a cette adresse et un message signé .
Je pense que dans les fait un cold wallet sur une adresse bitcoin qui n'a fait aucune dépense est plus sur contre une attaque ciblé
1.) Pay to clef public
2.) Pay to addresse sans depense ( plusieur addresse public peuvent avoir la même adresse bitcoin )
3.) Pay to addresse avec depense ( debut attaque ECDA possible selon les implémentations)