Я оказался не в состоянии ответить, что произойдет в этом случае, так что вот оно:
Хакер ( Mr Hacker) тратит UTXO_1и UTXO_2в TX_1, внося денежную стоимость всех TX_1выходов в Service(например, платежный процессор).
Законный пользователь ( Mr Legit) тратит UTXO_3в TX_2. Опять же, TX_2выходы 's нацелены на одно и то жеService
Оба TX_1и TX_2сделать это в одном блоке и получить одно подтверждение от сети.
ServiceСразу тратит UTXO_1и UTXO_3в TX_3платить Mr Legitи UTXO_2в TX_4платить Mr Smith.
Mr Hackerзатем решает удвоить расходы TX_1и по этой причине создает TX_5, который «перенаправляет» все выходы на себя. Mr Hackerявляется майнером, поэтому он может выполнять всю работу по хешированию, чтобы сделать двойную трату успешной. Ему также повезло, и двойная трата увенчалась успехом.
Итак, вопрос:
Были ли все TX ранее TX_5(TX: 1,2,3,4) признаны недействительными или только TX_1, TX_3и TX_4( TX_3и TX_4потрачены выходные данные, ранее контролируемые, TX_1которые были дважды потрачены)?
Mr Legitмог видеть 1 подтверждение за TX_2до двойной траты. Что он видит сейчас? Что Mr Smithвидит в своем кошельке до и после двойной траты?
Он Service понимает, что произошла двойная трата , и ему необходимо восстановиться из этого нарушенного состояния. Что нужно сделать, чтобы вернуться к нормальной работе? Нужно ли повторно отправлять все TX? Есть ли у него все еще депозиты, сделанные TX_2после двойного расходования, или ему нужно что-то сделать, чтобы вернуть эти результаты?
Как может Serviceпомешать Mr Hacker, у которого также есть много денег, повторять один и тот же процесс вечно только для того, чтобы разрушить Serviceбесперебойную работу, а не Serviceждать дополнительных подтверждений перед отправкой платежей?
Мне пришлось изобразить это на схеме, так как транзакции и цепочка блоков могут появиться на самом деле:
Inputs/Prev Outpoints Outpoints
TX1 A:0 TX1:0, TX1:1
TX2 B:0 TX2:0
TX3 TX1:0, TX2:0 ?
TX4 TX1:1 ?
TX5 A:0 TX5:0
(TX5)
Block A ------> Block C ----> Block D
\
----> Block B
(TX1, TX2)
Чтобы ответить на ваши вопросы:
TX3 и TX4 недействительны в любой цепочке блоков, которая ранее не включала TX1. TX1 не может быть включен, если TX5 уже является частью этой цепочки, потому что TX1 и TX5 оба тратят аутпойнт A:0.
TX2 никогда не бывает недействительным, поэтому, если бы кошелек, отправляющий TX2, загрузил устаревший блок, он показал бы 1 подтверждение. После того, как кошелек переключился на новую лучшую цепочку блоков, он снова покажет 0 подтверждений, потому что ни блок C, ни блок D не включают его. После того, как другой блок в лучшей цепочке блоков включает его, он вернется к 1 подтверждению и увеличится оттуда.
Если служба по-прежнему хочет производить те же платежи, она должна создать новые транзакции (TX6, TX7), используя входные данные, которые все еще действительны (например, TX2:0). Если он попытается повторно отправить TX3 или TX4, другие узлы могут заблокировать его за попытку ретрансляции недействительных транзакций.
Чтобы предотвратить будущие атаки двойного расходования на основе форка, сервис должен либо дождаться дополнительных подтверждений, либо найти какой-то не биткойн-способ сбора денег с двойных трат, например, требуя регистрации с выданным государством удостоверением личности. Я знаю, что запрос большего количества подтверждений требует большего времени ожидания, что неудобно, но это единственный децентрализованный метод, который у нас есть для снижения риска мошенничества.
TX_1 недействителен, так как конфликтует с недавно подтвержденным TX_5. TX_3 и TX_4 также недействительны, поскольку зависят от TX_1.
TX_2 остается действительной транзакцией. Однако, если атака г-на Хакера с двойной тратой включала осиротение одного блока, в котором содержались TX_1 и TX_2, то TX_2 больше не появляется в цепочке блоков и теперь имеет 0 подтверждений. Но ничто не мешает включить его в будущий блок, и, предполагая, что к нему прилагается плата, у каждого майнера в сети есть стимул включить его в свои блоки. Так что, скорее всего, это будет подтверждено быстро. (В принципе, здесь у г-на Легита может быть возможность дважды потратить и аннулировать TX_2, если он того пожелает, но для этого, вероятно, потребуется попустительство одного или нескольких могущественных майнеров.)
То, что кошелек мистера Смита покажет ему о теперь недействительном TX_4, зависит от этого программного обеспечения. Некоторые могут просто показать, что он застрял на 0 подтверждений. Другие могут отображать более конкретный метод, который был признан недействительным. В любом случае они, надеюсь, дадут понять, что в настоящее время он не может потратить эти монеты.
Предполагая, что Сервис по-прежнему должен деньги г-ну Легиту и г-ну Смиту, им нужно будет создать новые транзакции, чтобы заплатить им. Очевидно, что они больше не могут тратить выходы TX_1, а также не могут тратить TX_2, пока это не будет подтверждено повторно. Вместо этого им может потребоваться потратить другие UTXO, которые они контролируют, или, если у них их нет, им придется где-то приобрести еще несколько монет.
Я не думаю, что Служба может каким-либо образом избежать повторной атаки, кроме как просто ждать дополнительных подтверждений. Если у них есть какой-то способ отличить г-на Хакера от других своих клиентов, они могут предъявить более высокие требования к подтверждению только для него одного. Входящие транзакции от других клиентов могут по-прежнему тратиться немедленно, в то время как транзакции от г-на Хакера удерживаются для дополнительных подтверждений перед тем, как быть потрачены. Это уменьшит вероятность того, что атаки г-на Хакера помешают другим исходящим транзакциям Сервиса.
Марч