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

Пожалуй, самый известный в русскоязычном Интернете пример того как сервис пытается решить эту проблему - "азино три топора". Они выпускают отдельные ролики на тему того: "посмотрите и запомните как выглядит наш сайт и не попадитесь уловки мошенников". Но мы то знаем, что мошенники внешний вид сайта подделать могут очень просто. Поэтому такое доказательство принадлежности сайта именно "азино трем топорам" - недостаточное.

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

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

Например: ключ сервиса "ya_normalny_pacan". Вопрос пользователя "how do you do". Скрипт проверки сцепляет строки. Получается строка: "how do you doya_normalny_pacan". Потом считает хэш полученного слова: "b7fe1c279a92ce3f59fea88f0135943de7323c7000ca15f53e7cad69d2cc3a30". Пользователь сверяет это слово с тем, что ему выдает заведомо правильный сайт. Если совпадает, то все окей.

Мошенник не знает слова "ya_normalny_pacan". Допустим, он наугад выбрал другое слово "ya_nenormalny_pacan". Тогда его ответ пользователю получится такой: "9fdb5b905c96a9e1559ff9cecf147881b0243836afcaba03cd5ed8f6f22bc779". Пользователь видит, что ответ отличается и уходит с сайта мошенника.

Как то так. Конечно, 64-значные ответы сложно сравнивать простому человеку, поэтому надо немного усложнить скрипт расчета ответа таким образом, чтобы он выдавал ответ в виде 4-8 символов. Тогда человек точно без шпаргалок сможет сверить ответ сервиса. Еще для зарегистрированных пользователей можно сделать ответ, заданный ими самими. Например, пользователь у себя в личном кабинете указывает, что на вопрос "how do you do" сайт должен отвечать "ofigenno". И этот ответ должен ретранслироваться на все сайты сервиса.

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

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

Я на гитхаб https://github.com/ilyamain/dear выложил простой бесплатный скрипт, который вот это вот делает. Если кому надо более сложный скрипт - обращайтесь, решим вопрос

Понял хорошо!

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

Да, для этого все и сделано. Это и есть проверка PoW (proof of work, именно work). Я и не говорил, что майнерам будет легко. Они за это бабки получают . Но зато, они теперь посчитают наиболее оптимальную подборку транзакций, а не наиболее красивый хэш. Согласитесь - более интеллектуальная работа

P.S. Я извиняюсь за долгие ответы. У меня на форуме статус новичка. Форум мне постоянно говорит, что я могу отправлять одно сообщение в какое то там время (считай за весь нормальный вечер могу отправить одно сообщение). У меня одна ветка не отвечена уже примерно 3 недели. Прям стыдно перед пацанами

Ответил в личку, но мне bitcointalk напомнил, что я тут дух; а духу не положено обращаться к дедам . Поэтому не знаю, дошло ли моё сообщение.

На всякий случай, основные моменты, дублирую сюда.

Вот сюда (http://witchcms.xyz/) выложил демоверсию. Там куча ограничений. Более полная (но также еще не доработанная) версия на гитхабе: https://github.com/ilyamain/witch.

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

Про 2-4 часа. Ну это чтобы сеть успела определиться с офранами. В принципе, стандартно, но если делать безопасную транзакцию, чтобы майнеры китайские не перехватили пароль и не подменили транзакцию, то потребуется сначала отправить намерение о совершении транзакции с публичным ключом. Потом дождаться "закрепления блока". И только потом отправлять саму транзакцию. Если время между формированием блоков 20 минут, а максимальная длина ветки офранов - 5 штук (вместе с принятым получается 6 штук), то примерно 4 часа на двухэтапную транзакцию и уйдет.

А где можно посмотреть Ваш итоговый вариант (ну или хотя бы прочитать полностью описание того, что получилось)?

Я это прекрасно понимаю. Это и было "загвоздкой" до тех пор, пока не придумал (с Вашей подсказкой) другой способ. Чувствую, что мы немного не понимаем друг друга. Давайте я на днях выложу демонстрационную версию своих наработок (уже почти готова демонстрационная версия, но я ее буду отправлять не только программистам, но и потенциальным пользователям, поэтому хочу немного подразукрасить, чтобы прилично смотрелась ). Я думаю, увидев что получилось, Вы меня лучше поймете. Там, конечно, даже до альфа-версии ой-ой-ой как далеко. Но смысл того, как проводятся транзакции уже отчетливо виден. В принципе, все относительно безопасно. Сейчас думаю как можно было бы ускорить транзакции, чтобы на один платеж не уходило по 2-4 часа (вот это у меня сейчас слабое место для критики).


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

Ну, как я уже сказал выше, это немного кажется непонятным, пока не увидите своими глазами. Думаю, уже скоро закончу "разукрашивание". Потом скину сюда ссылку.


Но видите: у Вас все равно остается проблема, что один пользователь подключается к разным "соседям" и делает двойную трату. И с этим никак не справиться.

Да, конечно, я понимаю различия

Я вообще изначально хотел сделать просто адреса со сменными паролями (чтобы адрес не менялся, а пароль можно было поменять). Но Вы подсказали куда более элегантное решение - передавать все банкнотами. Сейчас в своем проекте делаю что то среднее между Вашим предложением и тем, что у меня было изначально. Только я делаю обычную децентрализованную сеть. С распределенной, как Вы уже сами заметили, есть много нерешаемых вопросов. Например, та же самая транзакция на разные адреса, запущенная с разных концов сети. Может, все-таки стоит вернуться к децентрализованной сети? Она себя вполне успешно показала во множестве альткоинов. Если интересно, могу показать что у меня получается. Может понравится, тогда объединим усилия.

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

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

Возвращаясь к Вашему проекту. По большому счету добиться анонимности можно намного проще. Для этого вполне достаточно стандартного биткоинового PoW. Но Вы зачем то все усложнили.

Извиняюсь за долгий ответ. Да, я раньше читал эту Вашу тему. И даже попытался дать совет по ее совершенствованию (что то среднее между тем, что я хочу сделать и то, что хотите сделать Вы). Но почему то Вы хотите настоять именно на распределенном консенсусе. Я же предлагаю в этом смысле не изобретать ничего нового, а сделать привычную децентрализованную сеть. Всё будет работать прекрасно и анонимно. Уговорить Вас мне не удалось

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



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

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

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


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

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

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


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

Предлагаю такой вариант проверки качества блоков вместо перебора хэшей и увеличения сложности. Критика (конструктивная) приветствуется.

Сначала о том, что это дает:
- уменьшает вероятность ситуации, когда 51% мощности захватывается одной группой майнеров. Для этого им надо захватить сразу несколько разных параметров. Если майнеры захватывают один из параметров, вес этого параметра уменьшается
- майнерам выгоднее заниматься не подбором хэшей, а сбором транзакций. Что в принципе и является их основной задачей, а не подбор хэшей. Подбор хэшей - это очень сложная и бесполезная работа (типа "копайте от забора и до обеда").
- уменьшается выгодность майнинга на видеокартах. Почти бесполезен майнинг на асиках.
- расширяет возможность программирования процесса формирования блоков на языки, не имеющие доступ к видеокартам.

Недостатков пока не нашел. Возможно, они есть. Для этого и выкладываю эту тему на форум


Порядок такой:

1. На каждом блоке ставится таймштамп в заголовке. Майнер принимает этот блок только при соблюдении двух условий: первое - время по UTC в данный момент больше хотя бы на секунду, чем таймштамп блока; второе - между таймштампом полученного блока и предыдущего блока прошло как минимум 1200 секунд (ну или другое установленное время).

2. Естественно проверяется валидность всех транзакций, проверка правильности подсчета хэшей и т.п. Если где то найдена ошибка - блок просто отклоняется.

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

Далее описание того, как проверяется качество конкурирующих блоков:

4. У блока "А" и у блока "Б" подсчитывается 1 - количество транзакций в них (далее А1 и Б1); 2 - сумма передаваемых в транзакциях токенов (далее А2 и Б2); 3 - время в секундах между таймштампом каждого из них и таймштампом предыдущего блока (далее А3 и Б3); 4 - хэш каждого блока (А и Б), выполненный последовательно столько раз, сколько в нем разница между таймштампами (далее А4 и Б4).

Немного о том, почему хэширование последовательное. Во первых что такое последовательное хэширование. Думаю, такой упрощенный скрипт лучше тысячи слов   :
result = this_block;
while (i<delta_timestamp) {
  result = hash(result);
  i++;
}
return result;
А теперь о том, зачем оно последовательное. Большинство ALU видеокарт будут сидеть-курить, ждать когда посчитается предыдущая итерация. А это позволит уравнять скорость расчета хэша на видеокарте и на процессоре. Что в свою очередь немного сбавит спрос на китайские видюхи , а также позволит программировать процесс формирования блоков на языках программирования, у которых нет доступа к видеокарте (например PHP). Ну и конечно же, это очень усложнит расчет на АСИКах.

Возвращаемся к алгоритму проверки качества конкурирующих блоков.

5. Сравниваем А1 и Б1 (количество транзакций в блоке) по логарифмической шкале. Например: пусть А1 = 8, Б1 = 4. Тогда по первому параметру у блока А количество баллов log("8")=0,90309. А у блока Б1 log("4")=0,60206.
Почему параметры сравниваются по логарифмической шкале - чтобы явное преимущество блока по одному из параметров не давало гарантии к его принятию всеми майнерами независимо от значений других блоков. Для еще более качественного уравнивания силы вклада отдельного параметра, можно увеличивать/уменьшать основание логарифма для этого параметра или умножать результат на корректирующий коэффициент. Все зависит от конкретного проекта и требований. Здесь рассмотрим общий вариант.

6. Аналогично по логарифмической шкале сравниваем А2 и Б2 (суммы передаваемых токенов). Пусть А2 = 0,456, Б2 = 12,3. Тогда количество баллов получится: -0,341 и 1,09 соответственно.

7. Сравниваем А3 и Б3 (разницу таймштампов блоков). Количество баллов определяется таким образом: минимально допустимая разница (выше в пример была приведена цифра 1200) делится на разницу между указанной в таймштампе сравниваемого блока и ей самой. От результата берется логарифм. Делится на корректирующий коэффициент (константу).
Приведу пример, чтобы через 20 минут (1200 секунд) блок получил чуть больше 1 балла, а через 30 минут (1800 секунд) блок получил чуть меньше 0,1 балла: result = log(timestamp/(1199-timestamp))/7. Где 7 - корректирующий коэффициент; 1199 - на секунду меньше 1200, чтобы избежать деления на 0.
Ну а для нашего случая пусть А1 = 1300, а Б1 = 1600. Тогда у блока А получится 0,3534 балла, у блока Б получится 0,1565 баллов.

8. Сравниваем хэши (естественно предварительно проверив их в п.2. на правильность). Переводим значения обоих хэшей в десятичную систему. Большее значение делим на меньшее, от результата берем логарифм (это если надо найти не меньший хэш, а больший; если хочется именно меньший, то можно делить не хэши а разницу между хэшем и максимально возможным его значением ну или еще какой-нибудь вариант, эти детали зависят от того, в каком проекте проверяются блоки). От полученного логарифма еще раз берем логарифм (или увеличиваем основание логарифма - кому как больше нравится). Логарифм от логарифма надо брать, чтобы значимость этого параметра не была намного больше других трех, так как отношение большего хэша к меньшему может быть очень велико. Тогда блоку с меньшим хэшем достанется 0 баллов, а блоку с большим хэшем достанется какое то положительное число.

Для нашего примера: пусть А4 дал нам 0 баллов, а Б4 дал нам 1,051 балл.

9. Можно тупо сложить эти параметры для каждого блока и выбрать большее. Но, чтобы еще уменьшить вероятность атаки 51%, можно каждый параметр каждого блока умножить на коэффициент, который прописан в предыдущем блоке. Это позволит уменьшить силу отдельного параметра, если он в предыдущих блоках показывал все большую и большую монополизацию майнеров. Эти коэффициенты могут меняться в пределах от 20% до 40%. То есть, например, если в нескольких блоках подряд большое влияние на выигрыш блока в соревнованиях с конкурентами оказывает параметр суммы передаваемых токенов, то сила этого параметра уменьшается в пользу других параметров. По каким алгоритмам определяется сила этих коэффициентов не буду расписывать, а то слишком "многабукф" получается . Если кому интересно, отдельно опишу.

Ну и для окончания расчетов для нашего примера (дабы все-таки определить победителя ). Пусть, предыдущим блоком заданы коэффициенты К1, К2, К3 и К4 для соответствующих параметров такие: 23%, 25%, 28%, 24%.
Тогда для блока А получится суммарный балл: 0,90309*23%+(-0,341)*25%+0,3534*28%+0*24% = 0,22141
Для блока Б получится суммарный балл: 0,60206*23%+1,09*25%+0,1565*28%+1,051*24% = 0,70703
В итоге блок Б принимаем, а блок А - отвергаем.

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

Спасибо! Понял. Буду изучать LevelDB.

Надеюсь, она не сильно отличается от mysql )))

Подскажите, пожалуйста, в каком виде на данный момент считается лучше всего хранить блоки? Ну, то есть, например: "в виде файлов txt", "в виде записи в базе данных" (если так, то какой движок и почему он лучше), или есть варианты хранения еще как то по другому?

Может, ссылки какие на эту тему посоветуете?

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


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

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


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

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


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

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