Stealth-адреса, транзакции и сообщения


  • administrators

    Обычные адреса Bitcoin-платформ не могут публиковаться публично, без потери конфиденциальности, поскольку все транзакции по этому адресу могут быть отслежены кем угодно. Адреса Stealth (скрытые адреса) позволяют публиковать общедоступный адрес, который может использоваться отправителями для получения нового адреса, к которому имеет доступ получатель, но никто другой не знает, связан ли он с Stealth-адресом.

    Хитрость заключается в том, что отправитель должен использовать nonce для получения адреса платежа, и этот nonce должен быть доставлен получателю, чтобы они знали, как восстановить средства. Nonce может быть передано в транзакции, так что отдельный канал не требуется для связи с nonce.

    Эта технология может использоваться и при создания новых открытых ключей для отправки зашифрованных сообщений.

    Обсудим четыре метода:

    1. Простейшая форма скрытых адресов, которая имеет некоторые недостатки.
    2. Адреса Stealth для максимальной конфиденциальности.
    3. Адреса Stealth для максимальной конфиденциальности плательщика от получателя.
    4. Адреса Stealth для отправки сообщений за пределами blockchain.

    Простые скрытые адреса

    Получатель имеет keypair A = aG. Получатель делает публичный ключ общедоступным (это stealth адрес).

    Отправитель имеет keypair B = bG.
    B - это nonce.

    У них есть общий secret S = bA = baG = abG = aB, хотя получатель еще не знает, как вычислить это, так как у них еще нет B.

    Плательщик строит kdf (S) = d и D = dG и E = A + D = aG + dG = (a + d) G = eG.

    Плательщик строит транзакцию, оплачивающую E, содержащую B, в OP_RETURN и транслирует ее, и она включена в блок.

    Получатель сканирует блок-цепочку для операторов OP_RETURN.
    Для всех операторов OP_RETURN, содержащих возможный открытый ключ, они вычисляют S = aB, затем вычисляют kdf (S) = d и D = dG и E = A + D и видят, что одна и та же транзакция, содержащая OP_RETURN, также оплачивает E.
    Если это так, тогда у получателя есть закрытый ключ для этого вывода, e, который можно использовать для расходования денег.

    Этот метод имеет некоторые недостатки:

    1. Закрытый ключ получателя a должен быть онлайн на компьютере, который сканирует blockchain, увеличивая вероятность компроментации безопасности.

    2. Любой может видеть, что инструкция OP_RETURN содержит возможный открытый ключ и, скорее всего Stealth-транзакцию, что увеличивает вероятность нарушения конфиденциальности.

    Оба этих недостатка решаются в следующем методе.

    Stealth-адреса для максимальной конфиденциальности публичных данных

    Получатель имеет две пары ключей, A = aG, для получения платежей и A'=a'G, для вычисления общего секрета. Оба открытых ключа становятся общедоступными (пара A, A' - стелс адрес).

    Отправитель имеет keypair B = bG. Они ранее получали платежи по этому адресу, поэтому хэш открытого ключа является общедоступным.

    У них есть общий секрет S=bA'=ba'G=a'bG=a'B, хотя получатель еще не знает, как вычислить это, так как они еще не имеют B.

    Отправитель строит kdf (S) = d и D = dG и E = A + D = aG + dG = (a + d) G = eG.

    Отправитель строит транзакцию, выплачивающую к E, где B является открытым ключом на одном из входов, передает его и он включен в блок.

    Получатель сканирует каждую транзакцию в blockchain. Для каждого открытого ключа на входе они вычисляют S = a'B, затем вычисляют kdf (S) = d и D = dG и E = A + D и смотрят, оплата по одной и той же транзакции, содержащей B, E. Если это так , они могут потратить эти деньги с помощью keypair A = aG.

    Обратите внимание: главный секретный ключ a не обязательно должен быть онлайн в сети при сканировании блоков, только a'. Также обратите внимание, поскольку OP_RETURN не используется, эта транзакция неотличима от большинства обычных транзакций pubkeyhash в blockchain.

    Поскольку этот метод создает транзакции, которые не отличимы от стандартных транзакций, он обладает максимальной публичной конфиденциальностью. Тем не менее, он медленный, поскольку каждая транзакция в blockchain должна сканироваться с вычисляемой сложностью O (nm), где n - число входов, а m - число выходов, который определенно медлены. Это можно преодолеть, всегда помещая B в первый вход, а также сканировать blockchain только во время, когда ожидается платеж.

    Одна из последних проблем заключается в том, что получатель может видеть вход, используемый отправителем, то есть он несовместим с нашими требованиями, то есть у отправителя не может быть конфиденциальности со стороны получателя. Это можно устранить, возвращаясь к OP_RETURN, разъясняемому в следующем разделе, хотя это связано с тем, что публичная конфиденциальность уменьшается.

    Stealth-адреса для максимальной конфиденциальности отправителя со стороны получателя платежей.

    Это то же самое, что и выше, когда у получателя есть две пары ключей A = aG и A '= a'G, а у плательщика есть пара ключей B = bG, за исключением того, что B помещается в оператор OP_RETURN, а не на ввод, тем самым делая эти транзакции совместимый с нашими требованиями, поэтому плательщик может иметь конфиденциальность у получателя.

    Следствием этого является то, что B содержится в OP_RETURN, и это доступно любому ☹ , кто анализирует blockchain, поэтому публичная конфиденциальность уменьшается.

    Stealth-адреса для отправки сообщений за пределами BlockChain

    Стелс-адреса также могут использоваться для обмена сообщениями.

    Получатель имеет пары ключей A = aG и A '= a'G.
    Публичные ключи делаются общедоступными (публичными).

    Отправитель имеет пары ключей B = bG и B '= b'G. Первый открытый ключ является общедоступным и повторно используется, последний открытый ключ является приватным и используется только один раз, чтобы отправить сообщение-подсказку получателю.

    Они имеют общий секрет S = bA '= ba'G = a'bG = a'B, хотя получатель еще не знает, как вычислить это, так как они еще не имеют B.

    Отправитель строит kdf (S) = d и D = dG и E = A + D = aG + dG = (a + d) G = eG, а затем шифрует сообщение, используя открытый ключ E с алгоритмом ECIES.

    Отправитель посылает B, E (или хэш E) и зашифрованное сообщение публично. Получатель ищет публичное место для всех потенциальных зашифрованных сообщений. Любой потенциальный В проверяется на Е или его хэш, так как приемник может вычислить

    S = a'B и d = kdf (s) и E = A + D = A + dG = aG + d = (a + d) G = Eq.

    Приемник может расшифровать сообщение с помощью закрытого ключа e (который имеет только получатель, а не отправитель).

    Второй секретный ключ получателя a' должен быть «онлайн», чтобы найти сообщение, но приватный ключ нужно использовать только для фактического расшифровки зашифрованного сообщения.

    Этот метод обмена сообщениями обладает тем свойством, что даже если сообщение отправлено в общественном месте, никто, кроме отправителя и получателя, не знает, кто отправил сообщение или кто его получил, только то, что сообщение существует, когда оно было отправлено, и примерно то, что его размер есть. Даже размер можно было бы скрыть, разместив много мелких сообщений, и время может быть размыто, отправляя кусочки в произвольные моменты времени.

    Все перечисленные методы доступны для понимания и имеют смысл быть, предлагаю добавить в протокол SmartHoldem Improvement Proposals подобный вид адресов и сообщений.

    Возможно разбавить всё кольцевыми подписями скрывающими отправителя транзакции, подмешивая несколько маскировочных выходов транзакции, скрывая, какие именно монеты были потрачены.

    Эти методы возможно использовать для создания действительно анонимных мессенжеров в отличии от псевдоанонимного telegram.



  • @technol0g было бы круто увидеть это на платформе SmartHoldem



  • Добавляйте, развивайте, совершенствуйте, делайте смартхолдем оригинальным - анонимным.
    Патентуйте все технологии, которые по вашему мнению дадут большое развитие будущего всего человечества
    Если надо делайте мессенджеры! 🙂

    Возможности попадаются редко - жизнь одна!



  • @TechnoL0g поддерживаю идею внедрения.



Looks like your connection to Community was lost, please wait while we try to reconnect.