2) В матчасти из разных источников, описывается пример с двойной тратой.
Т.е А пересылает битки B, и пока блок не добавлен в цепочку А пересылает те же битки самому себе. Насколько я понял в примере показано Что создавая транзакции можно указать тот же самый input со ссылкой ну туже транзакцию что в Input-e транзакции перевода А->B
Далее как я понял если Блок с транзакцией A->A будет добавлен в цепочку раньше то Блок с транзакций A->B будет считаться недействительным так как ссылается на израсходованную транзакцию...
И собственно для этого добавлена задача которая решается 10 минут...
Собсно чего я не понял... В примере указано что А->A должен самостоятельно решать задачу для того что бы блок был добавлен в сеть. Когда A->B решается вычислительной мощностью комьюнити. Сфига? Почему комьюнити не может решить A->A раньше чем A->B даже если он позже отправлен.
И как это защищает от того что если транзакция самому себе идет по времени столько же что и транзакцию другому участнику что мешает. Перед самой сделкой сначало отправить Транзакцию себе а Потом уже с участником сделки? Понятно что надо проверять какой блок был добавлен цепь но все же.
В общем я поплыл чутка, прошу подсказать.
В трех соснах заблудился. Рассмотрим различные варианты.
1. В принимает тразы с "нулевым подтверждением". Это имеет смысл только если В продавец кофе (типа никто не будет ради чашки кофе страдать такой фигней, да и в битками за кофе никто не платит, только когда Лайтнинг запилят, но это уже совсем другая история). Так же принимать 0-conf транзы можно если продавец каким либо другим образом защищен - например KYC, или если это тупо интернет-магазин и от момента оплаты до физической отправки товара проходит достаточно времени чтобы транза подтвердилась.
2. Итак остались B которые ждут 3 и больше подтверждений оплаты.
2.1 Я бы на это даже не останавливался но раз уж ты описал данный случай - то сразу его отбросим как бесполезный - это когда А публикует в сеть сразу обе конфликтующие транзы (т.е B еще не дождался своих подтверждений). Это не имеет смысла просто потому что во-первых B легко может увидеть в сети появление конфликтующей транзы; и во-вторых если майнеры смайнят жульничекескую транзакцию раньше чем B дождется своих подтверждений, то он не выполнит свою часть сделки и попытка А опять же станет бесполезной.
2.2. А - не майнер, он дождался когда после трех подтверждений В выполнил свою часть сделки и публикует в сеть свою жучью транзу ... ?? А - дибил. Майнеры не за что не станут вдруг перезаписывать блокчейн выкинув три последних блока просто так от нефига делать.
2.3.1 А - майнер с 51% мощностей. Что-ж А можно поздравить, он успешно атаковал сеть биткоина чтобы дважды потратить свои средства. Но ... Первое - очевидно что если сделка на весьма кругленькую сумму В может тупо увеличить количество подтверждений например до 2000 (подумай что будет с сетью битка если атакующий попытается переписать 2000 блоков - это неделя майнинга на 100% хешрейта). Второй момент - после подобных выкрутасов есть огромный шанс что пользователям это не понравится и они сменят PoW, и обладатель 51% мощностей скорее всего останется в итоге с огромной горой бесполезных асиков.
2.3.2. А - майнер с менее 51% мощностей - тут в принципе мотивы с прошлого примера так же применимы и сама атака тут уже не имеет 100% вероятности успеха. и на каждую такую неудачную атаку А будет терять бабло ( электричество + упущенная награда за блоки). Если интересно есть конкретные исследования и конкретные цифры по данной теме:
https://arxiv.org/pdf/1402.2009.pdf и, например посложнее где показано как майнеры могут уменьшить стоимость атаки
https://www.cs.umd.edu/~gasarch/reupapers/katzbitcoin16.pdf Собственно вывод - чтобы юзать биток майнерам доверять не обязательно, увеличиваешь количество подтверждений и спишь спокойно.