Topic: Что такое Taproot ? (Read 284 times)

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

Тема подрыва репутации у как можно большего количества адресов актуальна для держателей грязных биткоинов и среди них есть кодеры, способные испортить жизнь большому количеству пользователей и создать дополнительные трудности для следователей. Считается, что присутствие в адресе транзакций из миксеров тоже добавляют грязи. Американская контора Сiphertrace, которая специализируется на софте для блокчейн-расследований, в прошлом году писала на эту тему https://ciphertrace.com/crypto-dusting/

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

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

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

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

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

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

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

I Как мультисиг работает сейчас (вкрации):

1. Алиса, Боб и Вася договорились отправить биток в блокчейн таким образом, чтобы забрать этот биток мог только Вася но с разрешения Алисы или Боба.
2. В блокчейн прилетает транзакция:


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

ХэшВаси+ХэшАлисы+ХэшБоба+ОстальнойКодТранзакции

II Как мультисиг будет работать в Taproot:

1. ---Все то же самое---
2. ---Все то же самое---

3. Из трех публичных и приватных ключей, по специальному алгоритму формируется один ключ, назовем его "ключ Мастера". Этот ключ имеет хитрое свойство: Алиса, Боб и Вася могут подписать и проверить этим ключем сообщение, но при этом исходные приватные ключи остаются изветсны только их обладателям.
4. Дальше транзакция для запирания битков абсолютно такая же:


5. НО на диске эта транзакция будет выглядеть по другому:
ХэшМастера+ОстальнойКодТранзакции

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


На диске:
ПодписьВаси+ПодписьАлисы+ВсеОстальное

ИЛИ


На диске:
ПодписьВаси+ПодписьБоба+ВсеОстальное

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

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

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

В общем, впереди нас ждут интересные времена и противостояния.

Т.е. по сути можно будет внедрять кольцевые подписи, как у Монеро?

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

Мне кажется ты неправильно понял. Там отсылка не к лайтнингу, скорее бы было paying channels, а к coinjoin.

КоинДжоин (который не любит Фазз ) это как раз и есть "кооперативные траты", эдакая личинка кольцевых подписей Монеро.

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

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

Теперь по теме.
Буквально недавно, на днях, в код биткоина был сделан интересный pull request. Он добавляет в код функциональность которая описана в ставших теперь официальными бипах: BIP340, BIP341, BIP342.

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

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

Вот что пишут те кто все это придумал:

Оригинал

Перевод:
* Taproot делает все выходы и общие траты неотлечимыми друг от друга.

Комментарий:
Что они черт возьми имеют в виду
Я понимаю, что речь идет об выходах транзакции, а "общие траты" это наверное что-то про лайтинг нетворк. Про лайтинг я мало что знаю, но на примере обычных транзакций - что именно они собираются сделать?

Идем дальше.
Оригинал:

Перевод:
Использовать дерево меркла чтобы скрыть неиспозьзованные части скриптов.

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

Оригинал:

Перевод:
Использование в мультисиг транзакциях для подписи вместо ECDSA другого алгоритма: подпись Шнора.

Комментарий:
Это видимо как раз для первого пункта. Я так понимаю, что эта вундервафля позволяет в тратящем скрипте мультисиг транзакции использовать всего одну общую подпись вместо кучи подписей от всех контрагентов.
То есть например есть транзакция с условием "потратить битки можно только если тратящий скрипт подпишет Алиса и Боб"... То есть чтобы потратить такой выход сейчас, в транзакцию по любому надо записывать две подписи. А новый подход позволяет эти две подписи объединить в одну. Вот тут более или менее нормально объясняют https://bitcoin.stackexchange.com/questions/77234/schnorr-vs-ecdsa

Оригинал:

Перевод:
Улучшение алгоритма хэширования подписи (добавление возможности подписать все входы)

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

Оригинал:

Перевод:
Замена одного опкода OP_CHECKMULTISIG(VERIFY) на другой OP_CHECKSIGADD чтобы обеспечить возможность групповой проверки.

Комментарий:
Сейчас OP_CHECKMULTISIG работает для проверки всех подписей. я так понимаю, что если сделают подпись Шнора, то OP_CHECKSIGADD будет уметь проверять ее.

Оригинал:

Перевод:
Использование тэгов в разделении доменов при хэшировании (чтобы избежать инцидентов подобных CVE-2012-2459 для дерева Меркла)

Комментарий:
Тут ничего не могу сказать. Это что-то про безопасность алгоритмов хэширования при формировании дерева Меркла. Думаю не профессиональным криптоаналитикам это не особо интересно.

Оригинал:

Перевод:
Добавление новых возможностей таких как новый опкод OP_SUCCESS и обновляемые типы публичных ключей.

Комментарий:
Тут надо читать бипы, что они там добавляют. Я пока по диагонали прочитал и понял, что там хотят объединить p2sh и segwit адреса чтобы они не отличались друг от друга.