Всъщност положението е много, много по-лошо, отколкото повечето биткоинери си мислят.
Преди няколко седмици попаднах на инервюта, в които говорители на IRS се хвалеха как щели да замразяват и да blacklist-ват bitcoin портфейли. Което много ме озадачи - като програмист, преди години участвал за кратко в разработката на Bitcoin Core, смятах, че това няма как да стане.
Затова си свалих сорса и започнах да го преглеждам файл по файл. Но колкото и да гледах, никъде в сорса не можах да видя основание за оптимизма, показан от американците. Бях готов да махна с ръка, и да отпиша интервютата като поредните глупости на търкалета, само дето данъчните ми звучаха твърде уверено. Затова реших да направя нещо друго - да направя reverse engineer-инг на binary-тата и да ги съспоставя със сорса.
Та свалям си Cutter-а (това е доста широко ползван софтуер за reverse, базиран на radare2), свалям binary-тата, дизасемблирах и започнах да сравнявам дизасемблирания код със C++ кода. И тук нещата взеха да стават интересни - оказа се, че има разминавания във функционалността между сорс-кода, който може да се свали от GitHub-а и exe-тата, разпространявани от Bitcoin фондацията.
Първата разлика е една таблица в повече в exe-тата - само едно поле char[80]; имената на полето и таблицата изглеждаха като случайно избрани низове, но това може и да е артефакт от дизасемблера.
Втората разлика e UDP базиран протокол за OOB message-инг, който не е част от Bitcoin протокола. Съобщенията предавани по този протокол изглежда като да се проверяваха за цифров подпис; сравнението се прави срещу набор от десетина хардкоднати public ключа. Кой държи private ключовете - вашето предположение сигурно ще е също толкова вярно, колкото и моето. Изглежда този протокол се използва за добавяне на записи в допълнителната таблица.
По принцип няма никакви основателни причини за съществуването на тия две добавки, така че се опитах да разбера за какво точно се ползват. Още повече, че липсваха в C++ сорса, от който се предполага да build-нати binary-тата, които всеки си сваля от сайта на Bitcoin Foundation.
Оказа се, че когато се избира транзакция за включване в нов блок, за всеки един адрес, указан като input на транзакцията, се пресмята хеш (на мен ми изглеждаше като HMAC-нат SHA-256), след което се проверява дали някой от така изчислените хешове вече не е записан в допълнителната таблица. Ако да - транзакцията се връща обратно в mempool-а. Без значение каква е transaction таксата. И това се повтаря, докато транзакцията не expire-не по timeout.
От гледна точка на user-а това би изглеждало все едно транзакцията не е минала заради натоварване на мрежата с твърде много транзакции. От гледната точка на един програмист с опит това изглежда като механизъм, с който ефективно могат да се замразят amount-ите по конкретни bitcoin адреси.
Една по-подробна проверка установи, че за първи път тези допълнения са се появили във версия 0.17.1 - а тази версия я качиха на коледа 2018 година, близо два месеца след приключването на закупуването на GitHub Inc. (те притежават github сървъра, където е основния хостинг на Bitcoin Core) от Microsoft. Да, същото онова Microsoft на Бил Гейтс, което ние всички така добре познаваме и обичаме, и което е известно с това, че е склонно да прецака user-ите, ако американското правителство му подсвирне.
