Topic: Анонимная криптовалюта. Часть 2. (Read 1809 times)

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

----

1. как в вашей сети понять, что достигнут консенсус? где конечная точка, в которой все ноды понимают, что вот он момент, когда мы признаем эти транзакции валидными?

Именно, что мешает у Вас две транзакции с одного устройства, а это нельзя такое также удаляется, как и двойная трата.

Ничто не мешает отправить такое в сеть
1. 17Qy623y1VF8atdkbKNUVE4S7pcmLP8Mcj потом [хеш-адрес получателя1] [ваша подпись] [номер устройства1] [подпись устройства1]

2. 17Qy623y1VF8atdkbKNUVE4S7pcmLP8Mcj потом [хеш-адрес получателя2] [ваша подпись] [номер устройства1] [подпись устройства1]

Сила сети в её единстве!

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

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

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

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

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

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

Чтобы лучше это понять, я покажу новый механизм на примере взаимодействия нескольких пользователей:

Пусть у нас есть следующие пользователи имеющие в буфере следующие транзакции:

User1: 05 40 60 70 Х

User2: 06 41 61 71 Х

User3: 07 42 62 72 Х

User4: 08 43 63 73 Х

User5: 09 44 64 74 Х

User6: 10 45 65 75 Х

Х транзакция двойной траты

Армия ботов разослала эти транзакции двойной траты, каждому пользователю. Если проверку делать только по буферу транзакций, то всё будет нормально именно поэтому они были пользователями приняты, однако, когда эти пользователи будут обмениваться своими данными они будут обнаруживать двойные траты.

Теперь давайте рассмотрим новый механизм взаимодействия. Пусть пользователь User6 начнет обмениваться данными с пользователем User4, как только каждый из них обменялся данными он сразу же обнаруживает операцию двойной траты, что должны делать нормальные пользователи в данном случае. Они работают по следующим правилам, вначале вырезают транзакции двойной траты, а потом эти транзакции собирают по определенным правилам, т.е.

User4: 08 43 63 73
                             после удаления
User6: 10 45 65 75


User4: 08 43 63 73 10 45 65 75
                                               после соединения транзакций (правила соединения немного сложнее, но я упростил для понимания)
User6: 08 43 63 73 10 45 65 75

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

Это было раньше, а теперь мое дополнение. Это дополнение очень важное.

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

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

Хочу обратить ваше внимание, что если кто-то из пользователей User4 или User6 провзаимодействует с оставшимися пользователями, то он опять "заразиться транзакцией двойной траты", но это будет не страшно, т.к. если пользователь окажется нормальным, то транзакции двойной траты опять вырежут. Но самое главное в этом то, что цепочка транзакций растет несмотря на помехи.

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

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

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

Спасибо за пожелание, если хотите почитать про криптовалюту лишенного этого недостатка, то предлагаю https://bitcointalksearch.org/topic/m-1949631

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

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

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

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

Спасибо за помощь!



Что ж версия 2 тоже оказалась нерабочей, удаляюсь думать и беру временную паузу, возможно и найду решение, а возможно и нет.

Кто решает, какие это " 10 авторитетных узлов" будут властвовать?

То есть сеть, получается, не распределённая, а имеются конкретных 10 нод, которые должны считаться правдивыми, доминантными?  Кто эти ноды будет контролировать, вы? ))

Если я не так понял опять, то ответьте на вопрос:
Так как любой может строить любые альтернативные  цепочки блоков (форки) в любом количестве и любой длинны, то КАКОЙ ПРИНЦИП определяет какая из этих цепочек должна быть "подлинной"?


У Сатоши все понятно: Подлинной считается самая длинная цепочка, с большим количеством блоков.
А так как есть PoW и сложность, то самая длинная цепочка будет та, которую поддерживает больше всего мощностей.


А у вас нет абсолютно никакой защиты. Если вы предлагаете верить избранным 10 узлам, то это централизованная сеть, если это узлы с высокой долей - это PoS. Если это не какие-то особые узлы, а просто рандом - по смотреть мой предыдущий пост - что мешает злоумышленникам создавать альтернативные варианты сети и отвергать первоначальные ноды за дабл-спенд?

Другой пример:

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

Попробую ещё раз, если опять "в стену", удаляюсь


От куда группа нод знают, что такое  "все пользователи сети" ?

Повторюсь. Изолируем 100,000 виртуальных нод в подсети, перекидываем монету (вход A) 10,000 раз, с адреса на адрес, все 100,000 нод одобряют эти транзы, добавляют в блоки. Эту же монету отсылаем в открытой сети на биржу. Ждём "консенсуса", продаём ее.
Затем подключаем подсеть к интернету.

Остальные ноды в сети узнают, что Адрес A потратил монету ещё 10,000 транзакций назад. Следовательно, транзакция " A -> Биржа " не является валидный и все блоки, подтверждающие ее - орфаны)))


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


Прочитайте же вы уже наконец, что такое PoW...
нода- это виртуальная единица, которую можно множить неограниченно практически без затрат. Соответственно, можно наделать нод больше чем 51%, 70%, 90%.... В любой виртуалке.
Доказательство работы и сложность майнинга это не виртуальная величина, и имеет якорь в реальном мире. Хешрейт невозможно "виртуально намножить", чтобы совершить атаку 51% нужны большие вложения, нужны реальное железо, энергия. На экономической невыгодности атаки и держится безопасность.

А что у вас? )))

Для лучшего понимания у меня есть ещё более простая программка, она показывает формирование консенсуса для 6 пользователей:

Вот начальный этап:


Здесь показано, что у каждого устройства в буфере транзакций находиться только одна его транзакция, помните, что такое обозначение сокращенное, в реальности она будет иметь вид:

[хеш-адрес отправителя] [хеш-адрес получателя] [ваша подпись] [номер устройстваA] [подпись устройстваA]

такой вид транзакции для упрощения обозначаем как а потому что это транзакция с устройства А

для остальных аналогично.


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

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

Именно так и выращивается консенсус:


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

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

Вот пример:

Пусть у нас есть монета с хеш-адресом 17Qy623y1VF8atdkbKNUVE4S7pcmLP8Mcj

Вы как хозяин монеты создаете с разных устройств 2 транзакции вида

1. 17Qy623y1VF8atdkbKNUVE4S7pcmLP8Mcj потом [хеш-адрес получателя1] [ваша подпись] [номер устройства1] [подпись устройства1]

2. 17Qy623y1VF8atdkbKNUVE4S7pcmLP8Mcj потом [хеш-адрес получателя2] [ваша подпись] [номер устройства2] [подпись устройства2]

Т.е. Вы пытаетесь из одной монеты сделать две, это и называется двойная трата.


Теперь рассмотрим цепочки транзакций. Возьмем ваш пример:

a-b-c-d-e-f-g цепочка первого пользователя

a-m-n-v-x-z-k-u цепочка второго пользователя


Под транзакцией а я понимая именно такой вид:

CVQy623y1VF8atdkbKNUVE4S7pcmLP8Mcj потом [хеш-адрес получателя] [ваша подпись] [номер устройстваA] [подпись устройстваA]

т.е. это транзакция именно устройства А


Под транзакцией b я понимая именно такой вид:

89dy623y1VF8atdkbKNUVE4S7pcmLP8Mcj потом [хеш-адрес получателя] [ваша подпись] [номер устройстваB] [подпись устройстваB]

т.е. это транзакция именно устройства B

и так далее...


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

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

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

Сама цепочка - это фактически конечная версия последовательности транзакций в текущем строящемся блоке. Если такая транзакция встречается у другого пользователя, то это говорит не о двойной трате, а о том, что там другая последовательность и другое видение этого строящегося блока.

Весь консенсус формируется именно тогда когда находиться максимально длинная цепочка у практически всей сети и вот из её последовательности и начинают строиться блок.

Как взаимодействуют цепочки, опять вернемся к вашему примеру:

a-b-c-d-e-f-g цепочка первого пользователя

a-m-n-v-x-z-k-u цепочка второго пользователя

Вначале давайте найдем более длинную цепочку, она у пользователя2 и имеет 8 транзакций, в то время как у пользователя1 цепочка имеет только 7 транзакций. Итак в нашем случае мы будет проводить над цепочками операцию поглощение:

Берем цепочку пользователя1 и сравниваем на совпадения с цепочкой пользователя2, те что совпали удаляем. В данном случае наша цепочка стала b-c-d-e-f-g.

Теперь эту цепочку мы присоединяем к концу цепочки пользователя2, т.е.

a-m-n-v-x-z-k-u + b-c-d-e-f-g = a-m-n-v-x-z-k-u-b-c-d-e-f-g

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

И вот такие операции происходят по всей сети. Без разницы откуда придет цепочка и её размеры, сеть после различных проверок создаст с ней консенсус.


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

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

[a-m-n-v-x] - только из них строим блок а остальные z-k-u-b-c-d-e-f-g  остаются на следующий блок.

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

Смотрите, совершается транзакция A-B, после этого, совершается транзакция B-C, и так далее, есть цепочка транзакций a-b-c-d-e-f-g

В это же время где-то (в другом сегменте сети) происходит другая цепочка транзакций с тем же первым входом - a-m-n-v-x-z-k-u

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

Что дальше? Как решается, какая из этих цепочек окажется фиктивной?  

Как вы представляете себе синхронизацию сети?
Вы хоть понимаете, что любой может оставить n  нод в локальной сети, сделать транзу A-B, совершать последующие транзакции, сколько угодно,  а потом сделать в открытой сети дабл спенд транзакции с входом A, дождаться пока она будет принята многими нодами и нарастет цепочка последующих, и подключить интернет к своей локалке. ))

И окажется, что все цепочка транз после A - фиктивна? Какая именно?
Как определяется, какая группа нод круче другой? )))

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

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

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

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

А потому подкопив монет, какой-нибудь хитрый китаец создает при 1000 монет 1000 виртуальных машин с разными ip-адресами и начинает майнить.

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

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

Казалось бы данный мудила испортил весь майнинг и надо что-то делать.

Я же скажу, что нет. Дело в том, что наш условный мудила усилил сеть сразу на 1000 устройств, которые будут висеть в онлайне и обеспечивать безопасность.

Децентрализации и распределенные сети - это всегда избыточность.

А потому лучше убить майнинг и усилить безопасность, чем бороться и подвергаться более серьезной угрозе - атаки Сибил. Вот если она пройдет тогда ляжет вся сеть.

А так по монетке за блок, то не такая уж высокая цена.

Кроме того данный принцип майнинга напоминает в этом плане алгоритм консенсуса POS, там ведь тоже такой принцип у кого больше денег у того и шанс получить награду выше.

У нас же дело не в деньгах, а в количестве устройств. Чем большим денег хочешь майнить, тем больше устройств надо подключить. Чем больше устройств будет подключено, тем более надежной и защищенной будет сеть.

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

Чтобы показать понятно, буду пробовать объяснять на примере.

Как Вы и сказали создано 500 разных транзакций, но подписано одним ключом. Каждая из этих транзакций ушла разным пользователям и была принята. Будем считать, что я один из этих пользователей и я принял вашу транзакцию, обозначим её X.

Пусть в настоящее время в буфере транзакций я имею:

05 40 60 70 Х

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

Пусть его буфер содержит следующие транзакции:

66 43 Х 55 89 34 67

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

1. Вырезаю транзакцию двойной траты из своего блока и из блока данных от другого пользователя

Мой буфер транзакций становиться вида:

05 40 60 70


Буфер транзакций другого пользователя становиться вида:

66 43 55 89 34 67


После этого я работаю с этими транзакциями, по правилам консенсуса, а именно соединяю их по определенным правилам и получаю следующую цепочку в своем буфере транзакций:

66 43 55 89 34 67 05 40 60 70

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

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

Если ситуация повторяется, то делаю тоже самое.

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

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

Собственно говоря почему мы можем позволить себе вырезать транзакции двойной траты, всё просто они подписаны одним ключом. Транзакции других пользователей подписать нельзя и следовательно нельзя их как-то подделать и навредить им, а потому убирая такие транзакции, мы убираем только транзакции спамера.

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


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

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


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

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


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

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

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

Модель консенсуса (в текущем виде) ошибочна, тут нет смысла комментировать что-то конкретное.
Что значит 80-90% консенсус?))) Что остальные 20%? Орфан? Форк?
Зачем ещё хеш клиента??  Ну, подпишу я 500 разных  транз одним ключом, и каждую буду транслировать через отдельную виртуальную ноду с этим вашим уникальным "хешем клиента", и что? Какие 499 из них сеть должна будет отвергнуть? По какому принципу?
Как вы решите проблему уязвимости к атаке Сибиллы? https://en.m.wikipedia.org/wiki/Sybil_attack

Я не пришёл сюда с вами спорить, отвечать на вопросы мне не надо, это просто наводящие.
У вас куча конструктивной энергии, прекрасно, что вы пришли в крипту, рано или поздно что-то придумаете точно, с таким энтузиазмом.

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




А теперь смотрите, Вы передали мне купюру вместе со своим паролем. Значит пароль Вы тоже знаете, что мешает Вам передумать и забрать обратно свои деньги, просто опять поменяв пароль.

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

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

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





Присутствие одного номинала, позволяет иметь следующие преимущества:

1. Все деньги одинаковы, нет приоритета для взлома и слежки.

2. У разных номиналов появляется проблема дать сдачу или заслать ровную сумму.

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





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

Как это будет осуществляться. Для начала давайте посмотрим на рисунок и вспомним, как у нас выращивается консенсус: вот такая ситуация будет примерно после 20 итераций, у сети состоящей из 10 пользователей


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

06 09 04 01 07 03 05 02

Самая первая транзакция 06 - это транзакция пользователя с номером 6. А потому ему будет предоставлено право получить одну монету за формирование этого блока.

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

Повторяю нам майнеры не нужны, т.к. сеть и так хорошо находит консенсус.




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

Для того и создал тему, если не я то, кто-то другой создаст, как противодействие тупым законам.

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

Вот как только российское правительство введет налоги на крипту, твоя идея-проект будет пользоваться мега спросом.
а пока удачи развивай проект у него есть будущее

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

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

Поэтому начиная уже с 15 пользователей и больше применять следующую схему.

Вначале найти исчисление более крупного числа, для 15 это будет 100. Для 220 это будет 1000 и тому подобное. Если текущее число меньше половины до более крупного числа, в примерах это 15 меньше 50 для 100, 220 меньше 500 для тысячи. То тогда использовать для хеша 10% от половины крупного числа, т.е. для 15 использовать 5 первых транзакций, а если бы количество пользователей перевалило за 50, т.е. 51, то уже использовать 10% от 100 и это 10 первых транзакций.

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

Вот как пример допустим часть пользователей считает, что сейчас в сети 47-50 пользователей, другая часть 51-55. Таким образом у них будут разные хеши даже при полном консенсусе, т.к. одна группа считает хеш по первым 5 транзакциям, а другая по первым 10 транзакциям. Такая ситуация со временем исправиться, т.к. при обмене информацией обновляется карта сети и в зависимости от текущего количества, то изменит подсчет хеша та или иная группа.

Тоже полезно 

Я именно и хочу совместить с мессенджером и возможно даже расширить его функционал. Деньги можно в автоматическом режиме передавать собеседнику по чату.

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

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

Пронумеровал вашу цитату, для лучшего ответа.

Ответ на п1.
Давайте представим такой диалог человеку, которому нужно (ЧкН) и продавца(П). Разговор в Телеграм:

ЧкН заходит в Телеграмм, заходит к продавцу и начинает чат, хоть и зашифровано, но для подстраховки помним о СОРМ:

ЧкН: Очень нужно, прямо сейчас.
П: Не вопрос, сколько?
ЧкН: Средненько?
П: понял. Стоит 50 анонимов.
ЧкН: почему дороже.
П: за срочность
ЧкН: хорошо, скидывай адреса
П: 17Qy623y1VF8atdkbKNUVE4S7pcmLP8Mcj
    N8Qy623y1VF8atdkbKNUVE4S7pcmLP8Mcj
    V7Qy623y1VF8atdkbKNUVE4S7pcmLP8Mcj
    и так остальные
ЧкН: как переведу всё отпишусь
П: ок

Или другой разговор:

Бабушка(Б) покупающая пиццу на дом, постоянно переводящая пенсию в нашу систему от воровства и государства. Заказывает у оператора(О):

О: Ваш разговор записывается для разрешения спорных случаев. В случае, если запись отсутствует, то признается полностью правота клиента. Домашняя пицца на дом слушаю!
Б: Внучка мне бы пиццу.
О: Вам какую?
Б: По деревенски люблю.
О: Стоимость пиццы составляет 10 анонимов.
Б: Хорошо
О: Ваш адрес?
Б: xxxx - такой-то
О: Ваш заказ пицца по деревенски на адрес xxxx. Правильно?
Б: Да
О: переводите деньги на эти адреса, просто их скопируйте и вставьте в кошелек, в разделе перевод, как только переведете ваш заказ тут же будет отправлен

Особой разницы нет, скопировать адреса и вставить их будет несложно.



Ответ на п2.

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

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

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

Масштабировать будет превосходно, т.к. с количеством участников вырастит количество первых транзакций по которым считается хеш. Допустим у 10 можно считать по первым 5, у 100 уже можно считать по первым 40-50, у 1000 по первым 400-500 и так далее.

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

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

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

Далее мне не понятно, что значит порог принятия консенсуса 80-90%. То есть платеж проходит с некоторой вероятностью или допускаются частичные коллизии? Как вообще это будет синхронизироваться при масштабировании сети? Вы пробовали промоделировать не пять узлов, а хотя бы миллион? С этими вот случайными соединениями не наступит ли просто хаос?

Проект netsukuku достаточно интересен, но мне кажется будущее уже за беспроводными Mesh-сетями.

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

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

| id | хеш-адрес отправителя | хеш-адрес получателя| хеш-подпись отправителя | хеш-адрес вашего клиента | хеш-подпись вашего клиента |

Думаю первые 4 колонки понятны, объясню оставшиеся две и главное зачем они добавлены. Если Вы посмотрите на рисунки, где я показываю имитацию взаимодействия в такой сети, то увидите, что для 10 участников может быть только максимальная цепочка из 10 транзакций.

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

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

Итак Вы видели структуру транзакций, но чтобы мне было Вам наглядней объяснить, я принял следующие сокращения: устройство 1 с именем User1(тоже упрощаем имя для лучшей наглядности) имеет в буфере обмена свою какую-то транзакцию, для наглядности я обозначил её 01.

И так устройство 1 имеет транзакцию 01 и так далее до десяти. Так как условный пример я приводил на 10 устройствах.

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


Предлагаю обратить внимание на транзакции User01 и User03. В отличие от других у них только 2 одинаковые для них транзакции 03 (транзакция User3) и 01 (транзакция User1). Если отбросить всю остальную сеть, то для них консенсус уже наступил, т.к. они имеют у себя полностью одинаковые блоки со своими транзакциями в определенном порядке.

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

Таким образом, чтобы образовалась такая последовательность транзакций 03 01 нужно чтобы User1 подключился к User3 и если они в буфере будут иметь только свои транзакции, то образуется такая последовательность.

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

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

Поэтому, Вы зная о такой особенности, можете применить vpn для скрытия своего ip-адреса.

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

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

Про консенсус хочется поподробнее сейчас. А вообще не все делают сейчас по принципу победителя, IOTA имеет без блокчейна механизм (сейчас разбираюсь что и как) и вот еще нашел p2p сеть поверх физической, заявлена анонимность, все дела: http://netsukuku.freaknet.org - достаточно старый проект, есть инфа по-русски в том числе, на хабре в частности.

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

Факты прослушки трафика в TOR имели место, имели. Больше вопросов особых нет, а Вы можете и дальше доверять мнению проверенных источников.

Странно, что есть еще люди которые верят в TOR. Удивили, честно!

Странно, что никто даже покритиковать не хочет.

Тогда покритикую я сам себя

Основная трудность, которая возникнет на этапе реализации - это как не странно построение самой распределенной сети. Дело в том, что на сегодняшний день в стандарте IPv4 (это IP-адрес, который мы все привыкли видеть) закончились номера. Поэтому многие пользователи имеют так называемые серые адреса. Эти серые адреса выдает NAT - это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса.

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

Если по простому. То у Вас дома есть как бы своя локальная сеть, которая вам выдает свои внутренние ip-адреса, после прохождения NATa ваш ip-адрес меняется.

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

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

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

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

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

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

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

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

Итак, какие достоинства анонимности мы получаем:

1.   Распределенная сеть, где все полностью равноправны.

2.   Постоянно изменяющиеся хэш-адреса у монет. Огромная трудность для анализа.

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

4.   Отсутствие комиссии.

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

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

7.   Возможность обмануть когда у вас силой забирают деньги. Ведь данные деньги на кошельке легко можно разделять на несколько кошельков.

8. Постепенность прохождения суммы. Смысл в том, что в отличии от других криптовалют, она переводиться не вся сразу за транзакцию, а постепенно, т.е. полный переход прав растянут во времени, а это ещё сильнее затрудняет анализ блокчейна.




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

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

Очень сильно напрашивается аналогия с рекомбинацией молекул ДНК:


Данный алгоритм не требует каких-то жестких рамок, например, ограничение по времени. Главное его достоинство, что консенсус формируется постепенно и чем больше времени проходит, тем на большее количество участников он распространяется.

Я на языке программирования С++ смог собрать небольшой эмулятор анонимной распределенной сети и посмотреть, как он будет взаимодействовать.

Вот так выглядит сеть в начальном состоянии:


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

Транзакции участников пронумерованы. Например, у участника с номером один User01, транзакция имеет вид 01, у участника номер два User02 транзакция имеет номер 02 и так далее.

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

Вот состояние сети после 5 итераций:


Прошу обратить внимание на формирование консенсуса у участников User2, User5, User7.


Вот состояние сети после 10 итераций, это новое моделирование, а потому и консенсус будет другой, но он станет больше. Смотрим:


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

А вот после 20 итераций:


Нужно понимать, что взаимодействия осуществляются случайным образом, однако будет понятно, что после некоторой величины сеть приходит к 100% консенсусу. В данном случае для 10 участников такое случается практически всегда при 40 итерациях.

Для формирования консенсуса всей сети нам не нужно её 100% значение, а потому можно урезать длины цепочек, а также снизить порог принятия консенсуса сети допустим до величины 80%-90%.

Как я уже сказал, что нам не нужен 100% сети, т.к. в реальных условиях он может быть недостижим. Допустим некоторые участники в данный момент не проводят свои транзакции.

Это значит, что нам нужно формировать консенсус из количества транзакций примерно равному 50% от количества участников. Например, в нашем примере, консенсус будет формироваться только первыми 5 транзакциями, а остальная длина цепочки уже не важна.

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

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

В прошлой своей теме https://bitcointalksearch.org/topic/--1962101, я разрабатывал принципы на которых должна строиться полностью анонимная криптовалюта, однако, я потерпел неудачу, т.к. она оказалась настолько специфической, что под неё не подходил не один алгоритм консенсуса, даже тот, что придумал я.

А потому я продолжил свои изыскания и мне улыбнулась удача.

В итоге я получил анонимную криптовалюту со следующими достоинствами:

1) Анонимная распределенная сеть, подчеркиваю не децентрализованная, где есть узлы покрупнее, а именно распределенная, где все равны. Соединения только p2p.

2) Отсутствие комиссией.

3) Постепенный консенсус. Наверное это самое сложное, что трудно объяснить. Однако мне здесь видится аналогия с выращиванием и взаимодействием цепочек ДНК.

4) В идеале хочу совместить с месенджером.

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

6) Номиналов нет, есть только один номинал и все.

Однако прежде, чем перейти непосредственно к самой криптовалюте. Я бы хотел пояснить некоторые вещи касающиеся анонимности.



Все мы привыкли к тому, что на разных источниках информации про анонимные сети всплывают такие названия TOR, I2P, BitTorrent, Gnutella и им подобные.
Однако читая разную информацию:

ФБР официально призналась в контроле над анонимной сетью Tor

Действительно ли браузер Tor обеспечивает полную анонимность?

Немного Tor/I2P/Tails/СОРМ-3

Почему Bittorent через Tor — плохая идея

А действительно ли I2P может обеспечить 100% анонимность. Короткий ответ: нет. Несмотря на то, что сама система продумана очень здорово, сдать владельца сервиса могут сами сервисы, которые хостятся в I2P. Простой пример — уязвимость в веб-приложении. Если суметь её проэксплуатировать до возможности выполнения команд, то есть большая вероятность выявить настоящий IP-адрес компьютера. Это не единственная опасность.

И так всё сводиться к тому, что даже самые анонимные сети не обеспечивают полной анонимности. Скажу более, если мы строим сеть, где используются только p2p соединения, то скрыть свой ip-адрес нереально, т.к. для того чтобы пользователи смогли соединиться между собой им нужно знать ip адреса.

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

А потому я честно заявляю, что в такой сети ваш ip-будут знать все. Нет смысла напускать тумана и упиваться ложной анонимностью, лучше об этом знать сразу и принять своевременные меры, если вам нужно скрыть свой ip-адрес.

В данном случае хорошим решением будет openVPN или двойной openVPN.



Сама сеть представляет из себя распределенную структуру с периодически меняющимися случайными связями, имеющий тип соединения p2p, т.е. пользователь с пользователем напрямую.

Вот примерная схема сети:



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

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