Sus cálculos son correctos, excepto que no hay exactamente 2 ^ 256 claves privadas, hay "FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141" (este número se nombra Nen el código fuente ETH y es el orden del generador de la curva elíptica secp256k1, a partir de la cual se generan los pares de claves de Ethereum).

En respuesta a su pregunta, sí, las claves privadas asignadas a la misma dirección podrán gastar el dinero en esa dirección por orden de llegada. ¡Crearán la misma clave pública, con la que se realiza el algoritmo de verificación ECDSA, por lo que las firmas generadas por cualquiera de las claves privadas se verificarán con la misma dirección!

En go-ethereum/accounts/key.go , tenemos una clave privada generada a partir de S256 que es la curva de secp256k1, lo que significa que será menor que Nla predeterminada.

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 también genera los pares de claves de acuerdo con secp2656k1 aunque de una manera ligeramente diferente :)

Genial explicación ilustrativa de lo que Nrealmente es y por qué 2 claves podrán gastar dinero de la misma cuenta

Imagine que las claves privadas son millas recorridas en su automóvil y las claves públicas son el número de millas en el odómetro de su automóvil. Si el odómetro pasa de 999,999 a 000,000, una persona con millas recorridas = 1,000,001 tendrá la misma 'clave pública' y, por lo tanto, la misma dirección que una persona con millas recorridas = 1.

La aritmética del grupo EC es sorprendentemente similar a esto, pero en lugar de 999,999, ¡tenemos el número aparentemente arbitrario dado arriba! Debido a esta propiedad, incluso con sus diferentes 'claves privadas', podrá crear firmas que se verifiquen con la misma clave pública y, por lo tanto, gastar ETH desde la misma dirección.

aburrida explicacion matematica

Las claves privadas son números de 256 bits, y para calcular la clave pública a partir de una clave privada, se multiplica por el generador, g, del grupo de curvas elípticas. El generador en uso se define en los parámetros de las bibliotecas secp256k1 que se utilizan en ETH. También es un punto de curva elíptica, y como las curvas elípticas son cíclicas, existe ntal que n.g = 1(esto se llama orden generador).

Con esta ecuación podemos ver que si tuviéramos una clave privada kcon k>n, tendríamos k.g = (k-n).g = k'.g, ¡porque k'posiblemente sea la clave privada de otra persona! Entonces tenemos claves generadas en módulo aleatorio n, en lugar de 2^256.

Mi respuesta revisada a la pregunta del titular principal es que inevitablemente hay 2^96 claves que producirán direcciones en conflicto porque el límite en el espacio de direcciones es 2^160, y el espacio de claves es casi 2^256. Entonces, aunque cada clave pública distinta y el resumen de hash de Keccak resultante se asigna claramente a una sola clave privada, dado el uso de Keccak en las etapas de formateo de direcciones, se aplica el principio del casillero y crea la posibilidad de una colisión de los 160 bits finales para dos diferentes resúmenes de hash que comparten los últimos 160 bits, más sobre esos supuestos a continuación:

Para cualquier clave privada distinta válida (entre 1 y n-1, donde n = '0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141'según la curva secp256k1, se generará una clave pública 'distinta' (después de aplicar el punto Generador para envolver la curva) y, por lo tanto, no hay posibilidad de colisiones ya que no hay dos diferentes las claves privadas podrían asignarse a la misma clave pública.

El repositorio oficial de ethereum en Github tiene una biblioteca llamada eth-keys para Python que genera claves privadas y tiene una verificación de errores para asegurarse de que el exponente secreto sea menor que n.

Con respecto a las colisiones de direcciones:

Si la primera suposición anterior es cierta, entonces las probabilidades de que dos claves públicas diferentes produzcan un resumen de Keccak_256 que tenga 160 bits finales idénticos serían comparables (aunque menos probables) a tratar de encontrar dos cadenas aleatorias mediante una búsqueda de fuerza bruta que producir 160 bits finales idénticos en sus respectivos resúmenes de hash.

Estas colisiones parciales de resumen de hash Kecccak_256 ciertamente deberían existir a pesar de las probabilidades poco prácticas de encontrar una tan larga, comparable a un generador de direcciones de vanidad de ethereum que intenta generar los 40 caracteres para un requisito específico (es decir, 40 1 o la siguiente dirección perfectamente válida que nadie está es probable que alguna vez genere una clave para sin una computadora cuántica lo suficientemente fuerte ' 0xFEEDFEEDFEEDFEEDFEEDFEEDFEEDFEEDFEEDFEED ')) que tendría una dificultad de 1461501637330902918203684832716283019655932542976 igual a 2 ^ 160 o 16 ^ 40 (es decir, tener que buscar con fuerza bruta que muchas dirección de vanidad).

Si bien todavía es lo suficientemente inviable (mi estimación es 2**160) para encontrar dos resúmenes hexadecimales de Keccak_256 que tengan los mismos 40 caracteres hexadecimales finales para dos imágenes previas aleatorias, este caso requeriría encontrar dos claves públicas de ethereum diferentes (como preimágenes) que generan hash en dos resúmenes Keccak_256 distintos que comparten los mismos 40 caracteres hexadecimales finales.

Por lo tanto, el principio del casillero es aplicable, pero no a la curva en sí, ya que hay nclaves privadas potenciales que se asignan claramente a nlas claves públicas (el espacio de claves es 2^256-432420386565659656852420866390673177326, menos algunas inválidas como todos los 0), sin colisiones individuales. , pero en cambio, inevitablemente hay colisiones en las direcciones derivadas (ya que el espacio de direcciones distinto es 2 ^ 160, no estoy seguro teóricamente de cuántas colisiones parciales de este tipo pueden existir en los resúmenes de Keccak_256 (así que publico esa parte en crypto.stackexchange para una inmersión más profunda ).

Idea : una forma en que esto podría resolverse es si se usara todo el Keccak Digest como la dirección de Ethereum, aunque la compensación podría ser que habría consecuencias en los costos del gas y otras pérdidas de eficiencia, como requerir más almacenamiento de datos como lo obtendría la cadena de bloques. inflado para cada dirección en 96 bits y todas las transacciones de cuentas relacionadas (y tal aumento sumaría kilobytes, gigabytes, terabytes de diferencia rápidamente).