Topic: Анонимная криптовалюта. Часть 2. (Read 1793 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-адреса (что возможно это Ваш компьютер) никаких идентифицирующих Вас или меня данных в сеть не передается (те, кто озадачен анонимностью, знают как решить проблему засвечивания айпишников). Анонимность абсолютная (пусть в ущерб прозрачности, но я так понял, этот проект совсем не про повышение прозрачности )


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

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