Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
8 апреля 2011, 3:09:47 AM   # 1
 
 
Сообщений: 98
Цитировать по имени
цитировать ответ
по умолчанию Re: [RFD] алгоритм выбора монет и анонимности

Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome"
Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE
Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e
подробнее...


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
    Абстрактные
    Алгоритм создания транзакции не оптимизирован для анонимности. Это утечка информации, которая потенциально может быть использована для отслеживания денег, протекающих через систему. Хотя это не может представлять интерес для некоторых людей, это беспокойство другим. Для того, чтобы максимально увеличить анонимность для тех, кто желает его поведение создания транзакции в стандартном клиенте должно быть смещено в максимально возможной степени в стороне анонимности. Это смещение может быть легко достигнуто без каких-либо дополнительных сборов сделки.

    Проблема
    Одним из свойств Bitcoin является его способность быть анонимным. Эта способность не является совершенным, но оно есть. Тем не менее, текущая реализация позволяет достаточно бокового канала утечки информации, чтобы сделать его менее трудным для кого-то, чтобы отследить поток денежных средств через различные переводы. Закрытие этих боковых каналов не может остановить решительный аналитик, особенно если у них есть достаточные вычислительные ресурсы, но это, безусловно, сделает их работу сложнее. Для того, чтобы сделать работу трекера труднее, нам нужно минимизировать количество информации, которая позволяет следящее рисовать связь между двумя Bitcoin адресами.

    Основная проблема с текущим программным обеспечением является алгоритмом выбора монет (по "монета" Я имею в виду предыдущий выход транзакции, т.е. Vin [Икс] .prevout. Я иногда буду использовать термины "монета" а также "адрес" взаимозаменяемо). Кстати, операционные издержки не влияют на эту дискуссию, и предполагается, должны быть включены в "к оплате" - количество Bitcoins передается от одного человека к другому.

    Алгоритм выбора, который я называю "наиболее подходящий" Алгоритм, сводится к:
    • Если есть монета, которая точно соответствует сумме оплаты, а затем использовать его
    • В противном случае, найти монету (если таковая имеется), которая превышает сумму платежа по наименьшей сумме; т.е. если платеж 10BTC и у вас есть монеты 11BTC и монета 15BTC, используйте монету 11BTC
    • В противном случае, найти наилучшее сочетание монет, подводящее ближе всего к сумме платежа.
    Алгоритм выбора делает его немного легче для кого-то, чтобы отслеживать владение данной монеты, которая может позволить следящему связать две сделку с данным индивидом.

    Правило 1 легко. Монета идет от адреса A, чтобы обратиться Б. После этого транзакция тривиальна.

    Правило 2 немного сложнее, но не так много. Стандартный клиент не позволяет единый платежу нескольких получателей, поэтому один из двух выходов (изменение) должен контролироваться одним и тем же лицом, которое контролирует адрес A. поколение транзакций рутинные несколько смягчает этот путем случайного выбора идет ли изменение в Vout [0] или Vout [1]. Но мы знаем (и, следовательно, трекер также знает), что клиент будет пытаться выбрать монету, которая приходит как можно ближе по величине к оплате, поэтому весьма вероятно, что выход с меньшим значением является изменением, а выход с большим значением является оплата. Чем больше разница между выходными значениями, тем больше это, вероятно. Это по-прежнему думаю, конечно.

    Примеры (выходные адреса O1 и O2, входные адреса A, B, C и т.д.):
    А = 4, О1 = 3, О2 = 1: О2, скорее всего (но не гарантировано) платеж. Поэтому О1, вероятно, контролируется отправителем, и O2, вероятно, контролируется получателем.
    A = 100, O1 = 99, O2 = 1: Опять же, O1, вероятно (но не гарантируется) оплата
    А = 10, О1 = 4, O 2 = 6: Так как O1 и O2 близки друг к другу, либо один, скорее всего, платеж.
    A = 10, O1 = 5, O2 = 5: Невозможно сказать, что оплата и которая является изменение.

    Правило 3 тривиально. Один из выходов будут иметь значение больше, чем любая отдельная входную монета, а другой выходной сигнал будет иметь значение меньше, чем любые отдельные монеты. Выходная монета, которая имеет меньшее значение, это изменение, а выход монета с большим значением является оплатой. В отличие от правила 2, что собственность гарантируется, и никаких предположений или догадок не нужны.
    Примеры:
    А = 2, В = 3, 4 = О1, О2 = 1: О1 платеж, О2 является изменение. Если платеж был 1BTC, то монета B не нужен вообще для сделки.
    А = 2, В = 2, C = 3, О1 = 1, О2 = 6: О2 оплата, О1 является изменение. Как и в первом примере, если платеж был 1BTC, то любые один из входов удовлетворял бы компенсацию, а два других не будет включен.
    А = В = ?, ?; O1 = 4, O2 = 4: Это не может произойти. Если это так, один из двух входных монет должна быть больше или равна сумме платежа, так что другой не будет включен.


    Потенциальные Coin Выбор алгоритмов
    Трекер знает, что все входные монеты в сделке находятся под контролем одного человека (за исключением особых ситуаций, которые не охвачены стандартного клиента). Таким образом, операции должны использовать как несколько входов, как это возможно.

    Операции с одним выходом отдать, кто получил деньги (это очень маловероятно, что вы будете делать платеж самостоятельно).

    Рандомизации, какой выход является оплата и которая является изменение хорошо, так что имейте это.

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

    Держа эти принципы в виду, я предлагаю следующие алгоритмы:

    1) Выбрать монету, которая ровно в два раза стоимость оплаты
    Это делает два выхода идентичны, что делает его невозможно догадаться, что оплата и которая является изменение. Варианты: выбрать два или более монет, которые в сумме ровно в два раза больше суммы платежа; выбрать одну монету, которая примерно в два раза превышает сумму платежа (это приведет к двум выходами, которые близки по значению, и, как показано выше, вы не можете надежно угадать, является оплата)

    2) Выберите две монеты таким образом, чтобы либо (а) значение каждого входа должно быть меньше суммы платежа и суммы на более чем (но не равен) от суммы платежа, или (б) значение каждого входа больше, чем к оплате

    Пример:
    А = 4, В = 2, О1 = 5, О2 = 1

    Шпион, глядя на этой сделке не может сказать, если она удовлетворяет условие (а) или условие (б), поэтому они не могут определить, что является оплатой и которая является изменением. Для выполнения условия (а), О1 является оплатой, и условия (б) О2 платежа.

    3) Выберите две монеты: одну, значение которого точно соответствует компенсации, а другая монета в случайном порядке.
    Пример:
    А = 5, В = 2; О1 = 5, О2 = 2

    Это довольно очевидно, что мы делаем здесь, но так как мы (и трекер) знают, оплата и изменения случайны, трекер не может знать, что оплата и которая является изменение.

    4) специальная вариация (1) (я называю это одно в "В йо лице!" выбор): Выберите несколько монет, добавив более чем суммы платежа, а также, если возможно обеспечить, по крайней мере одна монета является излишним.
    Пример:
    А = 2, В = 3, С = 1, D = 1, Е = 2, 4 = О1, О2 = 5

    Это ясно из рассмотрения этой сделки, что несколько комбинаций монет могут удовлетворить любой О1 или О2, так что трекер не может сказать, что оплата и которая является изменением. Обратите внимание, что этот алгоритм, в отличие от других, гарантированно найти набор монет, которые могут быть использованы.

    Важные соображения
    Функция создания Транзакции должна быть в состоянии использовать любого из перечисленных выше алгоритмов. Конкретный алгоритм должен быть выбран случайным образом. Случайность может быть взвешена по отношению к алгоритмам 1 и 2.

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

    Текущий алгоритм может потенциально цикл 1000 раз, ищущих лучшее сочетание монет, чтобы прийти ближе к сумме платежа. Эти алгоритмы устраняют эту нагрузку.

    Важно, что поведение по умолчанию клиента Bitcoin направлено на анонимность. Для того, чтобы анонимности, чтобы добиться успеха, это должно быть трудно или невозможно отличить сделки, порожденных кто-то ищет анонимность, и сделки, порожденные, кто не заботится о анонимности. Если случайный выбор алгоритма используется только теми, которые ищут анонимность, то трекер просто нужно искать сделки, которые не соответствуют "наиболее подходящий" алгоритм.

    (Minor редактирует, чтобы очистить форматирование)
    Джим Hyslop сейчас офлайн Пожаловаться на Jim Hyslop   Ответить с цитированием Мультицитирование сообщения от Jim Hyslop Быстрый ответ на сообщение Jim Hyslop


    Как заработать Биткоины?
    Без вложений. Не майнинг.


    8 апреля 2011, 4:29:30 AM   # 2
     
     
    Сообщения: 1484
    Цитировать по имени
    цитировать ответ
    по умолчанию Re: [RFD] алгоритм выбора монет и анонимности

    Получил 1806 Биткоинов
    Реальная история.





    Обратите внимание, что монеты в Кошельке сначала рандомизированы, и тогда Выбор монет инициируется.
    jgarzik сейчас офлайн Пожаловаться на jgarzik   Ответить с цитированием Мультицитирование сообщения от jgarzik Быстрый ответ на сообщение jgarzik

    8 апреля 2011, 10:20:31 AM   # 3
     
     
    Сообщения: 1222
    Цитировать по имени
    цитировать ответ
    по умолчанию Re: [RFD] алгоритм выбора монет и анонимности

    Звучит логично и рационально при первом чтении.
    Я согласен, что выбор монет должна быть направлена ​​на внесение выходов близко к одинакового размера (некоторые более идти на 3-й партии, то меньше будет 3-й партии).
    da2ce7 сейчас офлайн Пожаловаться на da2ce7   Ответить с цитированием Мультицитирование сообщения от da2ce7 Быстрый ответ на сообщение da2ce7

    8 апреля 2011, 12:14:21 PM   # 4
     
     
    Сообщения: 826
    Цитировать по имени
    цитировать ответ
    по умолчанию Re: [RFD] алгоритм выбора монет и анонимности

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

    8 апреля 2011, 12:32:54 PM   # 5
     
     
    Сообщения: 540
    Цитировать по имени
    цитировать ответ
    по умолчанию Re: [RFD] алгоритм выбора монет и анонимности

    Важной частью будущего алгоритма выбора монет должна быть возможность проводить самостоятельно сгенерированные монеты (которые не имеют никакой истории), когда это важно.

    Этот патч ( http://bitcointalk.org/index.php?topic=5333.msg77952#msg77952 ) Является первым шагом. Затем один должен добавить некоторый механизм выбора из адреса (ов).
    Хал сейчас офлайн Пожаловаться на Халах   Ответить с цитированием Мультицитирование сообщения от Хал Быстрый ответ на сообщение Хал

    9 апреля 2011, 12:28:01 AM   # 6
     
     
    Сообщений: 98
    Цитировать по имени
    цитировать ответ
    по умолчанию Re: [RFD] алгоритм выбора монет и анонимности

    Обратите внимание, что монеты в Кошельке сначала рандомизированы, и тогда Выбор монет инициируется.
    Правда, но рандомизация действительно, кажется, не так уж много, за исключением, возможно, если у вас есть несколько монет, которые точно правильное значение. В этом случае, монета будет случайным образом выбран.
    Джим Hyslop сейчас офлайн Пожаловаться на Jim Hyslop   Ответить с цитированием Мультицитирование сообщения от Jim Hyslop Быстрый ответ на сообщение Jim Hyslop

    11 апреля 2011, 7:12:11 PM   # 7
     
     
    Сообщений: 61
    Цитировать по имени
    цитировать ответ
    по умолчанию Re: [RFD] алгоритм выбора монет и анонимности

    Хорошо, так что я работал над этим немного для вас.

    Я взял функцию SelectCoinsMinConf в main.cpp и изменили его в соответствии с вашими описаниями, так что я SelectCoins1Conf, SelectCoins2Conf и SelectCoins3Conf (4 собирается занять немного больше работы, чтобы держать операции мало). Эти функции вызываются функции SelectCoins. Я не совсем уверен, что переменные nConfMine и nConfTheirs, но они, кажется, должны делать с тем, как глубоки транзакции в блок цепи, так что я на самом деле не перепутались с ними.

    Посмотрите в приложенном файле ниже (не может получить файл прикрепить, папка загрузки полна) это просто имеет новые функции и функции измененного SelectCoins. Скажи мне, что ты думаешь. У меня не было времени, чтобы проверить это. Я должен что-то настройки для testnet.


    Код:
    / *
    Выберите монету, которая ровно в два раза стоимость оплаты
    Это делает два выхода идентичны, что делает его невозможно догадаться, что оплата и который
    изменение. Варианты: выбрать два или более монет, которые в сумме ровно в два раза больше суммы платежа; Выбрать
    одна монета, которая примерно в два раза сумма платежа (это приведет к двум выходами, которые близки
    в стоимостном выражении, и, как показано выше, вы не можете надежно догадаться, является оплата)
    * /

    // Посмотрите на монету, которая находится в пределах 10% от удвоенного нужного размера
    BOOL SelectCoins1Conf (int64 nTargetValue, внутр nConfMine, внутр nConfTheirs, установите& setCoinsRet)
    {
    setCoinsRet.clear ();

    CRITICAL_BLOCK (cs_mapWallet)
    {
    вектор vCoins;
    vCoins.reserve (mapWallet.size ());

    для (показать на карте:: итератора он = mapWallet.begin (); это = mapWallet.end (!); ++ это)
    vCoins.push_back (&(* Это) .second);
    random_shuffle (vCoins.begin (), vCoins.end (), GetRandInt);

    Еогеасп (CWalletTx * pcoin, vCoins)
    {
    если (! pcoin->IsFinal () || pcoin->fSpent || ! pcoin->Подтверждено())
    Продолжать;

    ИНТ nDepth = pcoin->GetDepthInMainChain ();

    если (nDepth < (pcoin->IsFromMe ()? nConfMine: nConfTheirs))
    Продолжать;

    Int64 п = pcoin->GetCredit ();

    если (п <= 0)
    Продолжать;

    если (п == nTargetValue)
    {
    setCoinsRet.insert (pcoin);
    вернуться (истина);
    } Иначе, если ((п == (2 * nTargetValue)) ||
     (п >= (1.9 * nTargetValue)) ||
     (п <= (2.1 * nTargetValue)))
    {
    setCoinsRet.insert (pcoin);
    вернуться (истина);
    }
    }
    }

    возвращать (ложь);
    }

    / *
    Выберите две монеты таким образом, чтобы либо (а) значение каждого входа должно быть меньше суммы платежа и
    Суммы к более (но не равно) сумма платежа, или (б) значение каждого входа больше
    чем сумма платежа

    Пример:
    А = 4, В = 2, О1 = 5, О2 = 1

    Шпион, глядя на эту сделку не могу сказать, если она удовлетворяет условию (а) или условие
    (Б), поэтому они не могут определить, что является компенсацией и которая является изменением.
    Для выполнения условия (а), О1 является оплатой, и условия (б) О2 платежа.
    * /
    BOOL SelectCoins2Conf (int64 nTargetValue, внутр nConfMine, внутр nConfTheirs, установите& setCoinsRet)
    {
    setCoinsRet.clear ();

    CRITICAL_BLOCK (cs_mapWallet)
    {
    вектор vCoins;
    vCoins.reserve (mapWallet.size ());

    size_t pCount = 0;

    для (показать на карте:: итератора он = mapWallet.begin (); это = mapWallet.end (!); ++ это)
    {
    vCoins.push_back (&(* Это) .second);
    ++pCount;
    }
    random_shuffle (vCoins.begin (), vCoins.end (), GetRandInt);

    CWalletTx * pfoundlargercoin1 = NULL;

    CWalletTx * smaller_coins [pCount];
    size_t smaller_count = 0;
    Int64 smaller_value = 0;

    Еогеасп (CWalletTx * pcoin, vCoins)
    {
    если (! pcoin->IsFinal () || pcoin->fSpent || ! pcoin->Подтверждено())
    Продолжать;

    ИНТ nDepth = pcoin->GetDepthInMainChain ();

    если (nDepth < (pcoin->IsFromMe ()? nConfMine: nConfTheirs))
    Продолжать;

    Int64 п = pcoin->GetCredit ();

    если (п <= 0)
    Продолжать;

    если (п > nTargetValue)
    {
    если (pfoundlargercoin1 == NULL)
    {
    pfoundlargercoin1 = pcoin;
    Продолжать;
    } еще
    {
    setCoinsRet.insert (pfoundlargercoin1);
    setCoinsRet.insert (pcoin);
    вернуться (истина);
    }
    } Иначе, если (п < nTargetValue)
    {
    smaller_coins [smaller_count ++] = pcoin;
    smaller_value + = п;
    }
    }
    если (smaller_value < nTargetValue ||
    smaller_value == nTargetValue && smaller_count < 2)
    возвращать (ложь);
    для (INT iLoop1 = 0; iLoop1 < smaller_count; ++ iLoop1)
    {
    для (INT = iLoop2 iLoop1; iLoop2 < smaller_count; ++ iLoop2)
    {
    если (smaller_coins [iLoop1] ->GetCredit () + smaller_coins [iLoop2] ->GetCredit () >= NTargetValue)
    {
    setCoinsRet.insert (smaller_coins [iLoop1]);
    setCoinsRet.insert (smaller_coins [iLoop2]);
    вернуться (истина);
    }
    }
    }
    }

    возвращать (ложь);
    }

    / *
    Выберите две монеты: одну, значение которого точно соответствует компенсации, а другая монета в случайном порядке.
    Пример:
    А = 5, В = 2; О1 = 5, О2 = 2

    Это довольно очевидно, что мы делаем здесь, но так как мы (и трекер) знают платежа и
    изменения случайны, трекер не может знать, что оплата и которая является изменение.
    * /
    BOOL SelectCoins3Conf (int64 nTargetValue, внутр nConfMine, внутр nConfTheirs, установите& setCoinsRet)
    {
    setCoinsRet.clear ();

    CRITICAL_BLOCK (cs_mapWallet)
    {
    вектор vCoins;
    vCoins.reserve (mapWallet.size ());

    size_t pCount = 0;

    для (показать на карте:: итератора он = mapWallet.begin (); это = mapWallet.end (!); ++ это)
    {
    vCoins.push_back (&(* Это) .second);
    ++pCount;
    }
    random_shuffle (vCoins.begin (), vCoins.end (), GetRandInt);

    CWalletTx * smaller_coins [pCount];
    size_t smaller_count = 0;
    Int64 smaller_value = 0;

    CWalletTx * pfrandomcoin = NULL;
    CWalletTx * pexactcoin = NULL;

    Еогеасп (CWalletTx * pcoin, vCoins)
    {
    если (! pcoin->IsFinal () || pcoin->fSpent || ! pcoin->Подтверждено())
    Продолжать;

    ИНТ nDepth = pcoin->GetDepthInMainChain ();

    если (nDepth < (pcoin->IsFromMe ()? nConfMine: nConfTheirs))
    Продолжать;

    Int64 п = pcoin->GetCredit ();

    если (п <= 0)
    Продолжать;

    если (п == nTargetValue)
    {
    pexactcoin = pcoin;

    }
    еще
    pfrandomcoin = pcoin;

    если (pexactcoin! = NULL && pfrandomcoin! = NULL)
    {
    setCoinsRet.insert (pexactcoin);
    setCoinsRet.insert (pfrandomcoin);
    вернуться (истина);
    }
    }
    }

    возвращать (ложь);
    }
    / *
    Специальная вариация на тему (1) (я называю это одним из "В йо лице!" Выбор): Выбор несколько монет добавляющих
    более, чем сумма платежа, и если возможно обеспечить, по крайней мере одна монета является излишним.
    Пример:
    А = 2, В = 3, С = 1, D = 1, Е = 2, 4 = О1, О2 = 5

    Это ясно из рассмотрения этой сделки, что несколько комбинаций монет могли удовлетворить либо
    O1 или O2, так что трекер не может сказать, что оплата и которая является изменение. Обратите внимание, что этот алгоритм,
    в отличие от других, гарантированно найти набор монет, которые могут быть использованы.
    * /
    BOOL SelectCoins4Conf (int64 nTargetValue, внутр nConfMine, внутр nConfTheirs, установите& setCoinsRet)
    {
    setCoinsRet.clear ();

    CRITICAL_BLOCK (cs_mapWallet)
    {
    вектор vCoins;
    vCoins.reserve (mapWallet.size ());

    size_t pCount = 0;

    для (показать на карте:: итератора он = mapWallet.begin (); это = mapWallet.end (!); ++ это)
    {
    vCoins.push_back (&(* Это) .second);
    ++pCount;
    }
    random_shuffle (vCoins.begin (), vCoins.end (), GetRandInt);

    CWalletTx * smaller_coins [pCount];

    CWalletTx * pfoundlargercoin1 = NULL;
    size_t smaller_count = 0;
    Int64 smaller_value = 0;

    Еогеасп (CWalletTx * pcoin, vCoins)
    {
    если (! pcoin->IsFinal () || pcoin->fSpent || ! pcoin->Подтверждено())
    Продолжать;

    ИНТ nDepth = pcoin->GetDepthInMainChain ();

    если (nDepth < (pcoin->IsFromMe ()? nConfMine: nConfTheirs))
    Продолжать;

    Int64 п = pcoin->GetCredit ();

    если (п <= 0)
    Продолжать;

    если (п > nTargetValue)
    {
    если (pfoundlargercoin1 == NULL)
    {
    pfoundlargercoin1 = pcoin;
    Продолжать;
    } еще
    {
    setCoinsRet.insert (pfoundlargercoin1);
    setCoinsRet.insert (pcoin);
    вернуться (истина);
    }
    } Иначе, если (п < nTargetValue)
    {
    smaller_coins [smaller_count ++] = pcoin;
    smaller_value + = п;
    }
    }
    если (smaller_value < nTargetValue ||
    smaller_value == nTargetValue && smaller_count < 2)
    возвращать (ложь);
    для (INT iLoop1 = 0; iLoop1 < smaller_count; ++ iLoop1)
    {
    для (INT = iLoop2 iLoop1; iLoop2 < smaller_count; ++ iLoop2)
    {
    если (smaller_coins [iLoop1] ->GetCredit () + smaller_coins [iLoop2] ->GetCredit () >= NTargetValue)
    {
    setCoinsRet.insert (smaller_coins [iLoop1]);
    setCoinsRet.insert (smaller_coins [iLoop2]);
    вернуться (истина);
    }
    }
    }
    }

    возвращать (ложь);
    }

    BOOL SelectCoins (Int64 nTargetValue, установите& setCoinsRet)

    randomproof сейчас офлайн Пожаловаться на randomproof   Ответить с цитированием Мультицитирование сообщения от randomproof Быстрый ответ на сообщение randomproof

    

    Как заработать Биткоины?

    Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

    bitcoin-zarabotat.ru
    Почта для связи: bitcoin-zarabotat.ru@yandex.ru

    3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW