В настоящее время обдумывая данную идею, я пришел к выводу, что мы в базе данных должны использовать только 2 столбца: это номер купюры и её номинал. Раньше использовался постоянный столбец id. В дальнейшем он бы нам мешал и снижал анонимность, а также мог привести к дискриминации монет, когда остальные пользователи не захотели бы принимать монеты определенных id. Если получиться убрать id и оставить только 2 значения, то это увеличит анонимность и не позволит дискриминировать монеты.
В беседе с уважаемым bighobbit я согласился, что у Zcash выше анонимность именно из за шифрования отправителя, получателя и суммы платежа.
Однако, как я говорил, а насколько надежен именно такой алгоритм шифрования. В нашем случае мы имеем структурную анонимность, Вам не нужно доверять алгоритму шифрования, что он Вас сделает анонимным. Именно поняв структуру Вы увидите за счет чего достигается ваша анонимность, а именно за счет того, что нет счетов и каждая монета практически несвязанная с другой. Только ваш кошелек позволяет Вам связывать эти монеты и знать какой суммой Вы владеете, без анализа кошелка со стороны будет только видно, как все или некоторая их часть из всего множества просто меняют свои номера.
Теперь же я хочу перейти к анализу Zcash. К некоторым выводам я пришел благодаря данной статье
https://bits.media/chto-investoram-sleduet-znat-o-zcash/В первую очередь Zcash использует метод доказательства с нулевым разглашением (zero-knowledge proof), который называется zk-SNARK. Вот хороший пример позволяющий понять, нам простым смертным, что это такое.
В данном случае Пегги выступает в качестве Доказывающего утверждение, и Виктор — в качестве Проверяющего. Пегги знает магическое слово («ключ»), ввод которого позволяет открыть ей дверь между C и D. Виктор хочет узнать, действительно ли Пегги знает пароль, при этом Пегги не хочет выдавать сам пароль. Пещера имеет круглую форму, как представлено на рисунке. Для того чтобы решить проблему, они поступают следующим способом. Пока Виктор находится в точке А, Пегги идёт к двери, и после того, как она исчезает из виду, Виктор идёт к разветвлению, то есть в точку B, и кричит откуда: «Пегги нужно выйти справа» или «Пегги нужно выйти слева». Получаем каждый раз вероятность того, что Пегги не знает пароль, равна 50 %. При 20 же повторениях эта вероятность будет порядка 10-6, что является достаточным для справедливости предположения о том, что Пегги знает ключ.
Если Виктор запишет все происходящее на камеру, то полученная видеозапись не будет являться доказательством для какой-либо другой стороны. Ведь они могли заранее сговориться, откуда будет выходить Пегги. Соответственно, она сможет найти выход, не зная при этом самого ключа. Существует ещё один способ: Виктор просто вырезает все неудачные попытки Пегги.
Последнее очень важное, вот что говорит по этому поводу разработчик Bitcoin Core Питер Тодд (Peter Todd):
Если метод zk-SNARK окажется неработоспособным, что весьма вероятно, в отличие от других более распространенных методов, это будет не удивительно… Главная угроза в этом методе кроется в том, что взломщики могут создать фальшивое доказательство zk-SNARK, взломав шифрование напрямую, даже не имея доступа к программной закладке
Т.е. как видите здесь Вы должны полностью доверять алгоритму шифрования, даже плохо понимая каким угрозам он может подвергаться. Однако это не главное, а главное то, что если произведется такой взлом или произойдет подмена доказательства, то вся подчеркиваю вся эта система перестает быть анонимной. Кроме того в Zcash существует возможность неограниченной инфляции (неограниченной эмиссии электронных монет), которую невозможно будет обнаружить, т.к. происходит шифрование суммы платежа.
В моей же системе при взломе у Вас украдут только одну эту банкноту, которую взломали и это никаким образом не повлияет на вашу безопасность и анонимность.
И в качестве вишенки на торте про Zcash, вот комментарий одного пользователя:
Yorik • 8 месяцев назад
Намекну, ключевой уязвимостью проекта является необходимость генерации стартовых параметров (сотни мегабайт данных, которые должны быть созданы перед запуском сети), фактически это публичные ключи от сгенерированных пар публичного и приватного ключей. Уязвимость - приватные ключи должны быть уничтожены и не должны попасть злоумышленнику, иначе бонусы от гомоморфного шифрования для сокрытия владельца монет - нивелируются или просто уровень защиты ослабляется (подробнее нужно изучать из публикации, а там математика не '2+2').
Так вот, разработчики опубликовали утилиты, позволяющие нескольким людям подключиться к процессу генерации этих пар (там какой то алгоритм, с помощью которого, разработчики уверяют, можно исключить утечку приватных ключей).
Теперь проблема - для релиза ключи были сгенерированы в тихушку, я к примеру хотел поучаствовать в этом процессе, но перед релизом за 4 суток готовые файлы просто выложили а в блоге просто написали что все ок.
Если я не прав, ткните меня носом где сообщалось о генерации ключей и кто участвовал в этом процессе.
Думаю умные люди поняли намек.