Ваши расчеты верны, за исключением того, что закрытых ключей не ровно 2 ^ 256 — есть «FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141» (это число Nуказано в исходном коде ETH и является порядком генератора эллиптическая кривая secp256k1, из которой генерируются пары ключей Ethereum).

Отвечая на ваш вопрос, да, приватные ключи, сопоставленные с одним и тем же адресом, оба смогут тратить деньги по этому адресу в порядке живой очереди. Они создадут тот же открытый ключ, для которого выполняется алгоритм проверки ECDSA, поэтому подписи, сгенерированные любым закрытым ключом, будут проверяться по одному и тому же адресу!

В go-ethereum/accounts/key.go у нас есть закрытый ключ, сгенерированный из S256, который является кривой secp256k1, что означает, что они будут меньше, чем Nпо умолчанию.

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 тоже генерирует пары ключей в соответствии с secp2656k1, хоть и немного другим способом :)

Классное иллюстративное объяснение, что на Nсамом деле и почему 2 ключа смогут тратить деньги с одного аккаунта

Представьте, что закрытые ключи — это мили, пройденные вашей машиной, а открытые ключи — это количество миль на одометре вашего автомобиля. Если одометр перейдет от 999 999 к 000 000, человек с пробегом = 1 000 001 будет иметь тот же «открытый ключ» и, следовательно, тот же адрес, что и человек с пробегом = 1 миля.

Групповая арифметика EC удивительно похожа на это, но вместо 999 999 у нас есть кажущееся произвольным число, указанное выше! Благодаря этому свойству, даже с вашими разными «закрытыми ключами», вы сможете создавать подписи, которые проверяются на одном и том же открытом ключе, и, следовательно, тратить ETH с одного и того же адреса!

Скучное математическое объяснение

Закрытые ключи представляют собой 256-битные числа, и для вычисления открытого ключа из закрытого ключа вы умножаете его на генератор gгруппы эллиптических кривых. Используемый генератор определяется в параметрах библиотек secp256k1, используемых в ETH. Сама она также является точкой эллиптической кривой, а поскольку эллиптические кривые цикличны, существует nтакое, что n.g = 1(это называется порядком генератора).

С помощью этого уравнения мы можем видеть, что если бы у нас был закрытый ключ kс k>n, у нас было бы k.g = (k-n).g = k'.g, потому k'что это, возможно, чей-то закрытый ключ! Таким образом, у нас есть ключи, сгенерированные случайным образом по модулю n, а не 2^256.

Мой пересмотренный ответ на основной вопрос заголовка заключается в том, что неизбежно существует 2 ^ 96 ключей, которые будут создавать коллизии адресов, потому что ограничение на адресное пространство составляет 2 ^ 160, а пространство ключей составляет почти 2 ^ 256. Таким образом, несмотря на то, что каждый отдельный открытый ключ и получающийся в результате хеш-дайджест Keccak однозначно сопоставляются только с одним закрытым ключом, учитывая использование Keccak на этапах форматирования адреса, применяется принцип «ячейки» и создается возможность коллизии 160-битных замыкающих битов для двух разных ключей. хеш-дайджесты, которые разделяют последние 160 бит, подробнее об этих предположениях ниже:

Для любого действительного отдельного закрытого ключа (от 1 до n-1, где n = '0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141'согласно кривой secp256k1 будет сгенерирован «отличный» открытый ключ (после применения точки Генератора для обертывания вокруг кривой) и, таким образом, нет возможности для коллизий, поскольку никакие два разных закрытые ключи могут сопоставляться с одним и тем же открытым ключом.

В официальном репозитории ethereum на Github есть библиотека eth-keys для Python, которая генерирует закрытые ключи и имеет проверку на наличие ошибок, чтобы убедиться, что секретный показатель меньше n.

Что касается конфликтов адресов:

Если первое вышеприведенное предположение верно, то вероятность того, что два разных открытых ключа создадут дайджест Keccak_256 с идентичными 160 битами в конце, будет сравнима (хотя и менее вероятна) с попыткой найти любые две случайные строки с помощью поиска методом грубой силы, который производят идентичные 160 завершающих битов в своих соответствующих хеш-дайджестах.

Такие частичные коллизии хеш-дайджеста Keccak_256, безусловно, должны существовать, несмотря на непрактичные шансы найти такой длинный, сравнимый с генератором тщеславных адресов Эфириума, пытающимся сгенерировать все 40 символов в соответствии с конкретным требованием (например, 40 единиц или следующий совершенно действительный адрес, который никто не знает). вероятно, когда-либо будет сгенерирован ключ для без достаточно сильного квантового компьютера ' 0xFEEDFEEDFEEDFEEDFEEDFEEDFEEDFEEDFEEDFEED ')) который будет иметь сложность 1461501637330902918203684832716283019655932542976 равно 2^160 или 16^40 (т. тщеславный адрес).

Хотя по-прежнему невозможно (моя оценка составляет 2 ** 160) найти два шестнадцатеричных дайджеста Keccak_256, которые имеют одинаковые конечные 40 шестнадцатеричных символов для любых двух случайных прообразов, в этом случае потребуется найти два разных открытых ключа ethereum (как pre-images), которые хешируются в два разных дайджеста Keccak_256, которые имеют одни и те же 40 завершающих шестнадцатеричных символов.

Следовательно, принцип сортировки применим, но не к самой кривой, поскольку существуют nпотенциальные закрытые ключи, которые четко отображаются на nоткрытые ключи (пространство ключей равно 2 ^ 256-432420386565659656852420866390673177326, за вычетом некоторых недействительных, таких как все 0), без каких-либо одиночных коллизий. , но вместо этого неизбежно возникают коллизии на производных адресах (поскольку отдельное адресное пространство составляет 2 ^ 160, я теоретически не уверен, сколько таких частичных коллизий может существовать в дайджестах Keccak_256 (поэтому я размещаю эту часть на crypto.stackexchange для более глубокого погружения ).

Идея : один из способов решить эту проблему — использовать весь Keccak Digest в качестве адреса эфириума, хотя компромисс может заключаться в том, что будут последствия для затрат на газ и другие потери эффективности, такие как потребность в большем объеме хранения данных, поскольку блокчейн получит раздутый для каждого адреса на 96 бит и всех связанных транзакций аккаунта (и такое увеличение быстро составило бы килобайты, гигабайты, терабайты разницы).