Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
2 декабря 2010, 12:14:17 AM   # 1
 
 
Сообщений: 25
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

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


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

Вы не делают блок сети линейный ориентированный граф, делают операции каждого индивида ациклический ориентированный граф, который (обычно) линейна.

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

Вот как это может работать: Определит функцию хэширования GETTHEBLOCK (входы), который принимает весь список закрытых ключей и сколько они занимают, и производит очень большое число, основанное на ней, таким образом, закрытый ключ с балансом нуль поступает на вход не влияет на выход, и, кроме того, такой, что рассмотрение хэша может надежно выявить, сколько общие единица валюты она воплощает. Все числа без знака (так как они просто битовые массивы, как и любой компьютер), так что не может быть отрицательным сальдо. Создать открытый / закрытый пары ключей "ПРОИСХОЖДЕНИЕ"И определить, что закрытый ключ, чтобы иметь T денежных единиц (T является максимальным числом, что конфигурация разрешений algroithm). Создайте первый блок B0 пропускание, что пара секретного ключа / баланс GETTHEBLOCK производить основной блок B0.

Производят вторые открытые / закрытые пары ключей "", Создание ациклический ориентированный граф с одним узлом значением B0, это представляет собой первый "сделка" формально дает, что личный ключ баланс нуля. То есть, принимая частный ключ / баланс пару ПРОИСХОЖДЕНИЯ и частный ключ / баланс пару А, А может воссоздать B0.

Теперь вот магия. GETTHEBLOCK определяется таким образом, что ORIGIN может передать сообщение А, что позволяет модифицировать блок к тому, что GETTHEBLOCK будет производить, если ПРОИСХОЖДЕНИЕ имело й меньше валюты и А имело й больше валют (возможно, они должны вести переговоры фактического изменения, происходит в интерактивном режиме, кто знает). Если ПРОИСХОЖДЕНИЕ имеет транзакции, А не имеет, и наоборот, и могут быть объединены "чисто", Клиенты также обмениваться информацией (возможно, заранее). Каждая сторона вступает в сделку в их транзакции граф истории как наследодатель сам последнего блока, что сделка будет применяться к чисто.

Клиенты не смогут повторно создать обновленный блок, потому что они не имеют закрытый ключ каждого человека (за исключением, может быть, для ПРОИСХОЖДЕНИЯ когда этот баланс равен нулю, поэтому они могут проверить B0 для себя). Но они все еще могут проверить, что они имеют повышенный баланс, и о том, что общее количество валюты не изменился, поэтому она должна исходить из чужого секретного ключа, предположительно человека они делают обмен с.

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

Там нет центральной власти здесь нет блока цепи. Однако, нет никакого риска подделки, так как люди не будут принимать увеличение предложения денег по определению (Это может быть технически невозможно тоже, если денежная масса является пределом для контейнера для хранения, неподписанные int64 или любой другой). Единственная реальная проблема (если вообще возможно - см ниже) в два раза расходы. Если А решает дважды провести весь баланс B а также С, из того же самого блока, В и С не будут в состоянии совершить сделку друг с другом, потому что они не могут "чисто" сделать так, что они могут быть вынуждены применить операцию к старому блоку, и один из них должен будет аннулировать транзакцию с А. Возможно, там может быть два отдельных историй сейчас, один, где B получил "фактический" сделка и один, где C получил "фактический" сделка. Или как я вычислить его, в конце концов, никто не захочет обменяться со вторым B или блока C, потому что они уже будут иметь другой ключ уже получил валюту, и единственный вариант B или C будет иметь, чтобы вести против старшего блока где они имеют меньший баланс. Это может все быть смягчено с центральной клиринговой сетью, которая передает транзакцию мгновенно каждому подключен (или могут сделать это быстро распределяется как текущий блок цепь, не имеет значения), так что принимающая сторона просто нужно подождать несколько секунд до окончания сделка, чтобы увидеть, что все в поле зрения принимает сделку.

Теперь GETTHEBLOCK может даже не существовать, это может быть невозможно. Большинство функциональных возможностей должно быть возможным. Вы можете сделать это удовлетворяет первое условие, что частные ключи с балансом нуля, не влияют на выход, возможно, подписав баланс с этим закрытым ключом, то умножив это число (лечащее его как номер) на балансе. Но не могли бы вы сделать это удовлетворяет второе условие, что вы можете проверить, сколько валюты он воплощает в себе, рассматривая его? Вы даже не должны возвращать число, просто истина / ложь, что это одно и то же число, что это была предыдущая сделка (и так как все будут знать секретный ключ ORIGIN, они могут определить, сколько валюты была в блоке B0 ). Вам может понадобиться так что-то творческое, как с использованием альтернативного государственно-частного ключа алгоритма, в котором сумма отдельных байтов или битов является постоянным, так keyЧbalance несет ту же картину.
awwright сейчас офлайн Пожаловаться на awwright   Ответить с цитированием Мультицитирование сообщения от awwright Быстрый ответ на сообщение awwright


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


8 декабря 2010, 2:54:39 ​​AM   # 2
 
 
Сообщения: 980
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

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





УДАР.
Киба сейчас офлайн Пожаловаться на киб   Ответить с цитированием Мультицитирование сообщения от Kiba Быстрый ответ на сообщение Киба

8 декабря 2010, 11:02:01 PM   # 3
 
 
Сообщений: 25
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

Хорошо, я расклеивание 10 BTC щедрот для тех, кто может найти такую ​​функцию или доказать, что он не существует, с разумным описанием того, что сочетание функций делает делает это невозможным.

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

9 декабря 2010, 11:54:21 AM   # 4
 
 
Сообщения: 826
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

Хорошо, я расклеивание 10 BTC щедрот для тех, кто может найти такую ​​функцию

Я нашел эту функцию, и я требую моей 10 BTC.
13NyUj5StfFDLCT1xrwDWShp51H9Ve9xMW

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

9 декабря 2010, 4:35:23 PM   # 5
 
 
Сообщений: 25
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

К сожалению, это не сделает вас счастливым, потому что функция просто отображает его входы к выходу, что приводит к очень большой хэш (но вы сказали, что это нормально).
Не совсем, потому что (1) хэш (по определению) возвращает битовую строку фиксированной длины, а в числе она возвращает не должно превышать определенное значение / размера, (2) баланс не будет криптографический привязан к Секретный ключ, я мог бы изменить баланс из "хешированное" выход и она будет незамеченной, и (3) пар с балансом нуля будет влиять на выход.

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

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

9 декабря 2010, 4:46:10 PM   # 6
 
 
Сообщения: 826
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

К сожалению, это не сделает вас счастливым, потому что функция просто отображает его входы к выходу, что приводит к очень большой хэш (но вы сказали, что это нормально).
Не совсем, потому что (1) хэш (по определению) возвращает битовую строку фиксированной длины, а в числе она возвращает не должно превышать определенное значение / размера, и (2) баланс не будет криптографический привязан к закрытый ключ, я мог бы изменить баланс из "хешированное" выход, и она будет незамеченной.

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

Вы хотели уверенность в том, что баланс не изменился "из ссылки", Так как вы можете легко рассчитать баланс выхода моей хэш-функции и сравнить его с эталонным балансом, она отвечает ваш вызов. 🙂

Но я позволю вам компенсацию 10 BTC.
ribuck сейчас офлайн Пожаловаться на ribuck   Ответить с цитированием Мультицитирование сообщения от ribuck Быстрый ответ на сообщение ribuck

9 декабря 2010, 4:58:40 PM   # 7
 
 
Сообщений: 25
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

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

Вы хотели уверенность в том, что баланс не изменился "из ссылки", Так как вы можете легко рассчитать баланс выхода моей хэш-функции и сравнить его с эталонным балансом, она отвечает ваш вызов. 🙂
В некоторых случаях это может быть не фиксированным размером, но хэш-функция никогда не будет производить выход, пропорциональный входной, что только регулярная функция, в противном случае, то, что отличает хэш от общей функции? Я смотрел на http://en.wikipedia.org/wiki/Cryptographic_hash_function который определяет фиксированный размер, но, что есть и другие вещи, которые не являются строго необходимыми, как "это невозможно найти сообщение, которое имеет заданный хэш" (Хотя это, безусловно, будет справедливо, если вы не можете определить очень большой частный ключ, используемый в качестве входа).

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

12 июня 2011, 2:46:43 AM   # 8
 
 
Сообщений: 92
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

Если ваш размер хэша меньше, чем размер входного сигнала, будет столкновение. Там будет несколько состояний с той же хэш, в котором люди имеют разные остатки. Так что это будет невозможно однозначно сказать, следует ли сделка быть разрешено или нет
Стреловые сейчас офлайн Пожаловаться на гусек   Ответить с цитированием Мультицитирование сообщения от фока Быстрый ответ на сообщение стаксель

12 июня 2011, 3:07:59 PM   # 9
 
 
Сообщений: 87
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

Хорошо, я расклеивание 10 BTC щедрот для тех, кто может найти такую ​​функцию или доказать, что он не существует, с разумным описанием того, что сочетание функций делает делает это невозможным.

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

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

  • Функция может быть легко вычислена
  • Учитывая выход, это неосуществимо, чтобы найти вход соответствия
  • Учитывая вход, это невозможно найти другой вход с тем же выходом
  • Это невозможно найти какие-либо два входа с тем же выходом (атаки на день рождения)

Ваше требование о том, что баланс нуля не может быть включена в хэш нарушает последние два свойства. Третье свойство нарушается, так как ввод данных может быть сделан из другого входа, который имеет тот же хэш, просто путем добавления счета с балансом, равным нулю. Конечное свойство наиболее тривиальным нарушается; в любое время добавляется новый (ноль) баланс, хэш остается неизменным. Я буду игнорировать их с целью обсуждения, но я считаю, только их действительное доказательство несуществования криптографический хэш-функции, и претендовать на награду.

Как уже обсуждалось, вы ищете хэш-функция, которая производит выход фиксированного размера, которые, хотя и не явно свойство хэш-функции, является разумным для любой практической системы. Теперь рассмотрим требование о том, что хэш может быть рассмотрен, чтобы проверить, что общая сумма денег в обращении не изменилось. (Я немного неясно, на этом, я предполагаю, что это то, что вы говорите). Выход фиксированного размера может хранить только фиксированное количество информации. 256-битный хэш может хранить только 256 бит информации. Принципиальное преимущество хэш как SHA является то, что они разрушительны. Вы питаетесь в сообщении переменной длины и получить выход фиксированного размера. Информация теряется в процессе, так что невозможно восстановить исходное сообщение от его хэша. Поскольку все больше и больше входов добавляются GETTHEBLOCK_1 (больше бит информации), то в конечном итоге не будет в состоянии соответствовать точному распределению средств в хэш. Это нормально, потому что все, что вы хотите в хэш является проверка общего количества валюты.

Итак, давайте рассмотрим альтернативный метод: сложение. Забудьте традиционные хэш-функцию на мгновение. Вы добавляете сальдо каждого счета в системе вместе, и взять сумму в качестве выхода (если это действительно важно, чтобы выходной быть фиксированной длиной, подушечка результата соответственно). Это один из простейших вычислений хешей для любого числа входов (следующее свойство: 1). Тем не менее, это тривиально, чтобы найти другой набор весов, которые имеют ту же сумму (нарушают свойства 2, 3, и 4). Теперь рассмотрим количество адресов в наличии. Глядя на странице загрузки статистики SourceForge, я собираюсь сделать консервативную оценку 300000 клиентов. Каждый из этих клиентов производит 100 пары ключей в первый раз при запуске, и пользователи будут производить, в среднем, в консервативной оценке, 1 пары ключей в неделю. Несмотря на то, нулевые остатки не отражены в хэше, они должны быть либо добавлены к нарастающему итогу (без изменений) или разветвленных вокруг. Это составляет 30 миллионов противовесов, которые должны быть добавлены вместе каждый раз, когда сделка сделана (консервативную оценку 5 в минуту), и это по-прежнему полностью игнорирует приватные ключи (которые даже не нужно учитывать в проверке). Я говорю это нарушает первое свойство, даже если он работает в линейное время, просто потому, что п очень велико. Кроме того, будет невозможно масштабировать по мере появления все больше и больше противовесов. Текущая модель работает, потому что узлы смотреть на балансе и сделки, убедитесь, что он является действительным, а затем сделать некоторый SHA хэширования, а затем клиенты доверяют, что узлы делают их математику правильно.

Наконец, кто имеет все частные ключи в первую очередь? Кто вычисление GETTHEBLOCK_1 и каким образом он "безопасно" собирать личные ключи?

Что касается GETTHEBLOCK_2, что о хэш (хэш (закрытый ключ1) Х баланса1) + Хэш (хэш (закрытый ключ2) Х баланса2) + Хэш (хэш (закрытый ключ3) Х баланса3) И так далее, где + есть конкатенация х умножение и хэш является стандартной криптографической хэш-функции по вашему выбору?

Bitcoin адрес: 1AJnX8Rf29kw72D4L9hBBEdHmZZRMYjW6
theboos сейчас офлайн Пожаловаться на theboos   Ответить с цитированием Мультицитирование сообщения от theboos Быстрый ответ на сообщение theboos

26 июня 2011, 3:34:16 AM   # 10
 
 
Сообщений: 25
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

Ваше требование о том, что баланс нуля не может быть включена в хэш нарушает последние два свойства. Третье свойство нарушается, так как ввод данных может быть сделан из другого входа, который имеет тот же хэш, просто путем добавления счета с балансом, равным нулю. Конечное свойство наиболее тривиальным нарушается; в любое время добавляется новый (ноль) баланс, хэш остается неизменным. Я буду игнорировать их с целью обсуждения, но я считаю, только их действительное доказательство несуществования криптографический хэш-функции, и претендовать на награду.
Я указал, что хэш должен быть криптографически безопасный, так что да, криптографический хэш функции фиксированной длины, для GETTHEBLOCK_2, которая может быть произвольной длины, за исключением.

Прикрепление счет с балансом нуля не изменяет распределение средств, и при этом не меняет вход, так что нет никакого нарушения. Если это невозможно сделать и остаются криптографически безопасными, что просто должно быть доказано. Только в этом требование (криптографически безопасный или нет) может быть сделано следующим образом: хэш (закрытый ключ1) Чbalance1 + Хэш (закрытый ключ2) Чbalance2 + ... + Хэш (закрытый ключN) ЧbalanceN (где "+" обозначает добавление и / или XOR). Но опять же, это не может быть криптографически безопасным.

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

26 июня 2011, 4:52:20 AM   # 11
 
 
Сообщения: 1582
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

Все это должно сделать это: Определить функцию хэширования GETTHEBLOCK_1 (входы), который принимает карту (частный ключ, баланс) пар, и производит очень большое число, основанное на ней, таким образом, что любые пары с балансом нуль поступает на вход не влияет на выход, и дополнительно таким образом, что изучение хэша может надежно доказать, что сумма валюты воплощенной в нем не изменилась от ссылки.
Кажется, довольно просто:
1) Возьмите карту секретного ключа, пар баланса.
2) Опустить любые пары с балансом, равным нулю.
3) Сортировка пар.
4) Возьмите SHA1 хэш.
5) Добавление SHA1 хеш к общему количеству всех остатков, выраженных в любом формате с фиксированной длиной.

Это должно соответствовать вашим требованиям. Добавление или удаление нулевой пар баланс не будет влиять на расчет на шаге 4 (поскольку они устраняются на стадии 2), ни общей сложность на этапе 5, потому что они не влияют на общем. Таким образом, выходной сигнал такой же, с или без пары нулевого баланса.

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

26 июня 2011, 3:18:23 PM   # 12
 
 
Сообщений: 25
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

Вы можете доказать, сумма валюты не изменилась, потому что любое изменение суммы валюты потребует изменения один из частных пар ключ / баланса, которые изменят хэш на шаге 4.
Это не криптографический проверить, что сумма значений всех ключей так же, как другой хэш иного распределения ценностей / валют / фонды, извините за путаницу. Идея заключается в том, я должен быть в состоянии сравнить GETTHEBLOCK_x ((закрытый ключ1, баланс11), (Закрытый ключ2, баланс21)) И GETTHEBLOCK_x ((закрытый ключ1, баланс12), (Закрытый ключ2, баланс22)), И проверить, является ли баланс11+баланс21 == баланс12+баланс22 .

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

Это случается немного отход от традиционного хэша, в том, что он должен сохранить ровно один кусочек информации информацию каким-то образом: сумма значений, даже если вы не можете точно сказать, сколько, вы должны быть в состоянии сравнить его с другим блоком.
awwright сейчас офлайн Пожаловаться на awwright   Ответить с цитированием Мультицитирование сообщения от awwright Быстрый ответ на сообщение awwright

26 июня 2011, 3:33:14 PM   # 13
 
 
Сообщения: 1582
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

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

26 июня 2011, 9:23:01 PM   # 14
 
 
Сообщений: 25
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

Я не понимаю ваше возражение. Это криптографический проверить, что суммы одинаково, точно так же, как система Bitcoin гарантирует, что транзакция не импортирует больше денег от предыдущей сделки, чем та сделки на экспорте. Все входы криптографически защищены хэшей, поэтому никакой особой магии не требуется, чтобы проверить психическое здоровье, вы просто делаете это непосредственно.
Потому что до сих пор так, что иное распределение частных ключей, создающих различный хэш может выполнять ту же общую сумму валюты. Сумма будет таким же, но хэш будет отличаться, и при запуске баланса через SHA1, он будет почти уничтожить информацию о наличных деньгах в обращении. Там нет никакого способа, чтобы сравнить сумму значений пар (ключ, значение), когда хэши не то же самое, что есть даже не вероятностный способ их сравнения (что может быть достаточным для GETTHEBLOCK_1).

Предположим, у меня есть следующие примеры пар ключей / значений с суммой 7: {(А, 5), (В, 2)}

Я должен быть в состоянии проверить из хэша этого множества, что он содержит один и тот же баланс, что и другое распределение значений, может быть, {(В, 2), (С, 1), (D, 4)}, и аналогично, Мне нужно, чтобы иметь возможность проверить, из хэша {(D, 5)}, что перечисленные хэши не воплощают ту же сумму значений, как другие (как 5! = 7). Хэш будут отличаться при различных закрытых ключах связаны с различными значениями, но сравнение суммы всех значений в закрытых ключи, и только для этого сравнения, должно быть возможно.
awwright сейчас офлайн Пожаловаться на awwright   Ответить с цитированием Мультицитирование сообщения от awwright Быстрый ответ на сообщение awwright

26 июня 2011, 9:50:55 PM   # 15
 
 
Сообщений: 70
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

Я не думаю, что хэш будут защищать то, что Вы желаете защитить. Люди с только хэшем должны быть уверены в том, что деньги не сфабрикованы, но тот, кто делает хеширование может подделать, и если они не будут вынуждены доказывать, что полный учет генерирует хэш, нет никакого способа узнать. Таким образом, вы можете также просто добавить незашифрованое всего в хэш отсортированного списка.

Вы можете хранить карту в "унарный", Другими словами {(А, 5), (В, 2)} будет храниться в виде "AAAAABB" (Лексически отсортированы перед расширением)

Затем зашифровать с помощью открытого ключа.

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

27 июня 2011, 8:32:33 AM   # 16
 
 
Сообщений: 25
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

Я не думаю, что хэш будут защищать то, что Вы желаете защитить. Люди с только хэшем должны быть уверены в том, что деньги не сфабрикованы, но тот, кто делает хеширование может подделать, и если они не будут вынуждены доказывать, что полный учет генерирует хэш, нет никакого способа узнать. Таким образом, вы можете также просто добавить незашифрованое всего в хэш отсортированного списка.
Сумма значений должна быть криптографический безопасной, иначе вы могли подделать хэш и говорите, что общее отличаются от фактических сумм от входа в хэш. И это не достаточно, чтобы просто быть уверенным в том, что сумма не быстро растет, вы должны иметь уверенность в том, что она не изменилась. Это означает, что если вы собираетесь использовать длину зашифрованных данных, вы не должны подушечкой его.

Вы можете хранить карту в "унарный", Другими словами {(А, 5), (В, 2)} будет храниться в виде "AAAAABB" (Лексически отсортированы перед расширением)

Затем зашифровать с помощью открытого ключа.

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

27 июня 2011, 4:54:48 PM   # 17
 
 
Сообщений: 70
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

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

Если карта Вашего счета {(A, 5), (B, 2)} можно добавить все учетные записи, а затем взять общую сумму, 7, и добавить случайное слово, так что вы 7_snei238nbd, а затем просто знак того, что с закрытый ключ, кто делает хеширование. Третьи лица могут проверить подпись, но они не могут подделать сообщения.

Вы можете пойти дальше и взять SHA-256 хэш данных учетной записи, и добавить его в общий и нонса перед подписанием. Тогда, если подписчик / мясорубка оспаривается или "аудит" они не могут произвольно присвоить значения ключей. Они запираются в выявлении, как значения были назначены на клавиши в момент подписания.
vector76 сейчас офлайн Пожаловаться на vector76   Ответить с цитированием Мультицитирование сообщения от vector76 Быстрый ответ на сообщение vector76

30 июня 2011, 11:45:01 PM   # 18
 
 
Сообщений: 70
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

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

30 июня 2011, 11:53:59 PM   # 19
 
 
Сообщений: 25
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

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

Если карта Вашего счета {(A, 5), (B, 2)} можно добавить все учетные записи, а затем взять общую сумму, 7, и добавить случайное слово, так что вы 7_snei238nbd, а затем просто знак того, что с закрытый ключ, кто делает хеширование. Третьи лица могут проверить подпись, но они не могут подделать сообщения.

Вы можете пойти дальше и взять SHA-256 хэш данных учетной записи, и добавить его в общий и нонса перед подписанием. Тогда, если подписчик / мясорубка оспаривается или "аудит" они не могут произвольно присвоить значения ключей. Они запираются в выявлении, как значения были назначены на клавиши в момент подписания.
Нет Баунти? лол
Это не начать решать эту проблему, я идентифицированный, прочитал мой оригинальный пост еще раз и посмотреть, что я пытаюсь выполнить, а затем прочитать требования для того, что хэш должен делать. Она должна быть криптографически защищенной от восстановления отдельных входов. Я ищу официальное письменное исследование здесь. Предварение общей суммы хэша пара не криптографический безопасное в контексте данной проблемы. Изучение вывода, чтобы определить сумму входов (но никакой другой информации не может быть возмещена, как частные ключи) должен гарантировать, что это та же сумма входов, которые используются для создания хэша. Выход 7; не является безопасным, потому что может быть что-нибудь, что-то, чьи входы не суммируются до 7, или даже нонсенс, что это не хэш вообще. Использование одноразового номера в функции лишает его от хэша, потому что вход производит непредсказуемый выход.

А также, я должен был бы свой адрес Bitcoin.
awwright сейчас офлайн Пожаловаться на awwright   Ответить с цитированием Мультицитирование сообщения от awwright Быстрый ответ на сообщение awwright

1 июля 2011, 12:51:05 AM   # 20
 
 
Сообщения: 141
Цитировать по имени
цитировать ответ
по умолчанию Re: Hash на основе теории Бесцепных сделков

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



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

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

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

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW