Ihre Berechnungen sind richtig, außer dass es nicht genau 2 ^ 256 private Schlüssel gibt - es gibt "FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141" (diese Zahl wird Nim ETH-Quellcode genannt und ist die Reihenfolge des Generators der elliptische Kurve secp256k1, aus der Ethereum-Schlüsselpaare generiert werden).

Als Antwort auf Ihre Frage: Ja, private Schlüssel, die derselben Adresse zugeordnet sind, können das Geld an dieser Adresse nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ ausgeben. Sie erstellen denselben öffentlichen Schlüssel, gegen den der ECDSA-Verifizierungsalgorithmus ausgeführt wird, und daher werden Signaturen, die von einem der privaten Schlüssel generiert wurden, gegen dieselbe Adresse verifiziert!

In go-ethereum/accounts/key.go haben wir einen privaten Schlüssel, der aus S256 generiert wurde, was die Kurve von secp256k1 ist, was bedeutet, dass sie kleiner als Nder Standardwert sein werden.

func newKeyFromECDSA(privateKeyECDSA *ecdsa.PrivateKey) *Key {
    id := uuid.NewRandom()
    key := &Key{
        Id:         id,
        Address:    crypto.PubkeyToAddress(privateKeyECDSA.PublicKey),
        PrivateKey: privateKeyECDSA,
    }
    return key
}

func newKey(rand io.Reader) (*Key, error) {
    privateKeyECDSA, err := ecdsa.GenerateKey(secp256k1.S256(), rand)
    if err != nil {
        return nil, err
    }
    return newKeyFromECDSA(privateKeyECDSA), nil
}

go-ethereum/crypto/secp256k1/secp256 generiert die Schlüsselpaare ebenfalls gemäß secp2656k1, wenn auch auf etwas andere Weise :)

Coole anschauliche Erklärung dafür, was Nwirklich ist und warum 2 Schlüssel Geld von demselben Konto ausgeben können

Stellen Sie sich vor, private Schlüssel sind Meilen, die in Ihrem Auto gefahren wurden, und öffentliche Schlüssel sind die Anzahl der Meilen auf dem Kilometerzähler Ihres Autos. Wenn der Kilometerzähler von 999.999 auf 000.000 übergeht, hat eine Person mit gefahrenen Kilometern = 1.000.001 denselben „öffentlichen Schlüssel“ und damit dieselbe Adresse wie eine Person mit gefahrenen Kilometern = 1.

Die EC-Gruppenarithmetik ist dieser überraschend ähnlich, aber statt 999.999 haben wir die scheinbar willkürliche Zahl, die oben angegeben ist! Aufgrund dieser Eigenschaft können Sie selbst mit Ihren unterschiedlichen „privaten Schlüsseln“ Signaturen erstellen, die gegen denselben öffentlichen Schlüssel verifiziert werden, und somit ETH von derselben Adresse ausgeben!!

Langweilige mathematische Erklärung

Private Schlüssel sind 256-Bit-Zahlen, und um den öffentlichen Schlüssel aus einem privaten Schlüssel zu berechnen, multiplizieren Sie ihn mit dem Generator, g, der Gruppe elliptischer Kurven. Der verwendete Generator wird in den Parametern der in ETH verwendeten secp256k1-Bibliotheken definiert. Er selbst ist auch ein elliptischer Kurvenpunkt, und da elliptische Kurven zyklisch sind, gibt es einen nsolchen, dass n.g = 1(dies wird Generatorordnung genannt).

Mit dieser Gleichung können wir sehen, dass wir, wenn wir einen privaten Schlüssel kmit k>nhätten, k.g = (k-n).g = k'.g, für a hätten k', das möglicherweise der private Schlüssel von jemand anderem ist! Wir haben also Schlüssel, die zufällig modulo generiert werden n, und nicht 2^256.

Meine überarbeitete Antwort auf die Hauptfrage der Überschrift lautet, dass es zwangsläufig 2^96 Schlüssel gibt, die kollidierende Adressen erzeugen, da die Grenze für den Adressraum 2^160 und der Schlüsselraum fast 2^256 beträgt. Obwohl also jeder unterschiedliche öffentliche Schlüssel und der daraus resultierende Keccak-Hash-Digest eindeutig nur einem privaten Schlüssel zugeordnet ist, gilt angesichts der Verwendung von Keccak in den Phasen der Adressformatierung das Schubladenprinzip und schafft das Potenzial für eine Kollision der nachlaufenden 160 Bits für zwei verschiedene Hash-Digests, die die letzten 160 Bit teilen, mehr zu diesen Annahmen unten:

Für jeden gültigen unterschiedlichen privaten Schlüssel (zwischen 1 und n-1, wobei n = '0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141'gemäß Kurve secp256k1 ein „unterschiedlicher“ öffentlicher Schlüssel generiert wird (nachdem der Generatorpunkt angewendet wurde, um die Kurve zu umschließen) und daher keine Kollisionsgefahr besteht, da sich keine zwei unterscheiden Private Schlüssel könnten demselben öffentlichen Schlüssel zugeordnet werden.

Das offizielle Ethereum-Repo auf Github hat eine Bibliothek namens eth-keys für Python, die private Schlüssel generiert und über eine Fehlerprüfung verfügt, um sicherzustellen, dass der geheime Exponent kleiner als ist n.

Bezüglich Adresskollisionen:

Wenn die erste obige Annahme wahr ist, dann wäre die Wahrscheinlichkeit, dass zwei verschiedene öffentliche Schlüssel einen Keccak_256-Digest mit identischen abschließenden 160 Bits erzeugen, vergleichbar (wenn auch weniger wahrscheinlich) mit dem Versuch, zwei beliebige zufällige Zeichenfolgen über eine Brute-Force-Suche zu finden, was dies tun würde erzeugen identische 160 Trailing-Bits in ihren jeweiligen Hash-Digests.

Solche partiellen Kecccak_256-Hash-Digest-Kollisionen sollten sicherlich existieren, trotz der unpraktischen Wahrscheinlichkeit, eine so lange zu finden, vergleichbar mit einem Ethereum-Vanity-Adressgenerator, der versucht, alle 40 Zeichen für eine bestimmte Anforderung zu generieren (dh 40 Einsen oder die folgende vollkommen gültige Adresse, die niemand ist wahrscheinlich jemals einen Schlüssel für ohne einen ausreichend starken Quantencomputer ' 0xFEEDFEEDFEEDFEEDFEEDFEEDFEEDFEEDFEEDFEED ')) generieren, der eine Schwierigkeit von 1461501637330902918203684832716283019655932542976 hätte, was 2 ^ 160 oder 16 ^ 40 entspricht (dh eine Brute-Force-Suche durchführen muss, um solche Kombinationen zu finden Vanity-Adresse).

Während es immer noch nicht machbar genug ist (meine Schätzung ist 2**160), zwei Keccak_256-Hex-Digests zu finden, die die gleichen nachgestellten 40 Hex-Zeichen für zwei zufällige Pre-Images haben, müsste dieser Fall zwei unterschiedliche öffentliche Ethereum-Schlüssel (wie z pre-images), die zu zwei unterschiedlichen Keccak_256-Digests hashen, die die gleichen 40 nachgestellten Hex-Zeichen teilen.

Daher ist das Schubladenprinzip anwendbar - aber nicht auf die Kurve selbst, da es npotenzielle private Schlüssel gibt, die eindeutig nöffentlichen Schlüsseln zugeordnet sind (Schlüsselraum ist 2 ^ 256-432420386565659656852420866390673177326, abzüglich einiger ungültiger wie alle 0), ohne einzelne Kollisionen , aber stattdessen gibt es unvermeidlich Kollisionen bei abgeleiteten Adressen (da der eindeutige Adressraum 2^160 ist, bin ich mir nicht sicher, wie viele solcher Teilkollisionen auf Keccak_256-Digests existieren können (also poste ich diesen Teil auf crypto.stackexchange für einen tieferen Tauchgang ).

Idee : Eine Möglichkeit, dies zu lösen, wäre, wenn der gesamte Keccak Digest als Ethereum-Adresse verwendet würde, obwohl der Kompromiss darin bestehen könnte, dass dies Folgen für die Gaskosten und andere Effizienzverluste hätte, wie z. B. die Notwendigkeit von mehr Datenspeicherung als die Blockchain für jede Adresse um 96 Bit und alle damit verbundenen Kontotransaktionen aufgebläht (und eine solche Erhöhung würde sich schnell zu einer Differenz von Kilobyte, Gigabyte, Terabyte summieren).