Topic: Синхронизация цепочки транзакций (Read 204 times)
Всем спасибо за ответы!
Сеть постоянно мониторят боты любителей халявы. Даже этот форум мониторят: парсят все сообщения на предмет наличия приватных ключей в них...
То есть транзакция B -> C и транзакция B -> amaclin попадут в сеть практически одновреенно, ну может вторая с задержкой в пару секунд. При том, что B -> amaclin полетит одновременно почти ко всем известным онлайн нодам, а ваша B -> C скорее всего полетит лишь к 10 или 20 нодам с которыми ваш клиент держит связь по умолчанию.
То есть транзакция B -> C и транзакция B -> amaclin попадут в сеть практически одновреенно, ну может вторая с задержкой в пару секунд. При том, что B -> amaclin полетит одновременно почти ко всем известным онлайн нодам, а ваша B -> C скорее всего полетит лишь к 10 или 20 нодам с которыми ваш клиент держит связь по умолчанию.
Разве транзакции попадая в мемпул сразу включаются в UTXO и можно отправлять транзакцию B-C не дожидаясь включения в блок транзакции A-B?
Я делал эти две транзакции в Электруме в тестнете (у меня Электрум подключен к своей ноде через EPS) в офлайне, баланс адекватно менялся и в электруме, и на морде bitcoin-qt. Куда там они включались, я не знаю, честно говоря.
Разве транзакции попадая в мемпул сразу включаются в UTXO и можно отправлять транзакцию B-C не дожидаясь включения в блок транзакции A-B? Если так, то какой лимит на глубину очереди и есть ли он вообще? Если лимита нет, то мемпул можно положить.
Перехват транзакции B->C возможен, если замещающая транзакция содержит бОльшую комиссию (даже без флага RBF).
Возможен, но не гарантирован.
Конечно, если транзакцию без RBF-флага можно легко перебить (не майнеру), то все теряет смысл. Просто у меня не получилось в мейннете даблспенднуть транзакции без RBF (с RBF легко), и я решил, что в наше время большинство нод (по умолчанию, по крайней мере) такие транзакции отвергают. Значит я ошибался, так? Возможен, но не гарантирован.
2. Они идут по отдельности, и поэтому возможен вариант, что на часть нод придет сначала первая, а только, скажем, через минуту вторая.
Это теоретически возможно, но маловероятно. Транзакции, отправленные одна за одной попадут в мемпулы практически одновременно.
Перехват транзакции B->C возможен, если замещающая транзакция содержит бОльшую комиссию (даже без флага RBF).
Возможен, но не гарантирован.
Если в мемпул попадет транзакция для которой известен приватник, то с вероятностью около 100% с эти монеты перехватят. Получится цепочка A -> B -> amaclin ))
Так уж и 100% )). Можем поэкспериментировать - я дам адрес с приватником и даже примерное время транзакции скажу - попробуйте перехватить.Я так понимаю, Вы имеете в виду, что в оффлайне сначала создадите и подпишете Bitcoin-транзакцию A-B, которая будет тратить выход с адреса A, а затем создадите и подпишете транзакцию B-C, которая будет тратить выход с адреса B. Хотя транзакции B-C пока нет в блокчейне, её можно создать заранее, так как известен SHA256-хеш транзакции A-B и порядковый номер выхода. После этого Вы одновременно броадкастингом распространите обе эти транзакции в сети.
Ну как одновременно... Я сделаю первую транзакцию и вслед за ней вторую. Это все в офлайне. Можно, конечно, и заранее заготовить, не важно. То есть на моей ноде обе транзакции уже в мемпуле и ждут подтверждения. После этого врубаю интернет, моя нода синхронизируется с другими. Я хотел бы понять, как эта синхронизация проходит? Мне представляется два варианта: 1. По нодам распространяются обе транзакции вместе.
2. Они идут по отдельности, и поэтому возможен вариант, что на часть нод придет сначала первая, а только, скажем, через минуту вторая.
Quote
В этом случае да, возможность перехватить монеты будет абсолютно реальная. Дело в том, что транзакция B-C, попав в пул, изначально будет считаться невалидной, так как ссылается на пока ещё не записанный в блокчейн SHA256-хеш транзакции. Но, когда майнер включит транзакцию A-B в Bitcoin-блок, транзакция B-C станет действительной.
Атакующий, зная приватный ключ к адресу B, может оперативно создать и подписать транзакцию B-C по переводу монет на его собственный адрес, задав больший размер комиссии, и в итоге Ваша транзакция B-C, скорее всего, не попадёт в блокчейн.
Как я понимаю, для этого надо, чтобы моя вторая транзакция пришла на половину нод позже, чем транзакция атакующего, так? И это возможно (при том, что она начала распространяться одновременно с первой)? Атакующий, зная приватный ключ к адресу B, может оперативно создать и подписать транзакцию B-C по переводу монет на его собственный адрес, задав больший размер комиссии, и в итоге Ваша транзакция B-C, скорее всего, не попадёт в блокчейн.
Если я на локальной ноде отключусь от сети, выполню эти две транзакции (A-B и B-C без RBF) и подключусь снова, будет ли теоретическая возможность у кого-то перехватить монеты на адресе В? Просто я не понимаю, как будет происходить синхронизация этих транзакций, по отдельности или цепочки в целом?
Я так понимаю, Вы имеете в виду, что в оффлайне сначала создадите и подпишете Bitcoin-транзакцию A-B, которая будет тратить выход с адреса A, а затем создадите и подпишете транзакцию B-C, которая будет тратить выход с адреса B. Хотя транзакции B-C пока нет в блокчейне, её можно создать заранее, так как известен SHA256-хеш транзакции A-B и порядковый номер выхода. После этого Вы одновременно броадкастингом распространите обе эти транзакции в сети.
В этом случае да, возможность перехватить монеты будет абсолютно реальная. Дело в том, что транзакция B-C, попав в пул, изначально будет считаться невалидной, так как ссылается на пока ещё не записанный в блокчейн SHA256-хеш транзакции. Но, когда майнер включит транзакцию A-B в Bitcoin-блок, транзакция B-C станет действительной.
Атакующий, зная приватный ключ к адресу B, может оперативно создать и подписать транзакцию B-C по переводу монет на его собственный адрес, задав больший размер комиссии, и в итоге Ваша транзакция B-C, скорее всего, не попадёт в блокчейн.
Если в мемпул попадет транзакция для которой известен приватник, то с вероятностью около 100% с эти монеты перехватят. Получится цепочка A -> B -> amaclin ))
Все просто на самом деле если усвоить, что любая транзакция это контракт.
Контракт A -> B в переводе на человеческий звучит так: "я знаю приватник А, битки из А разрешается потратить любому, кто знает приватник В"
Контракт B -> C в переводе на человеческий звучит так: "я знаю приватник В, битки из В разрешается потратить любому, кто знает приватник С"
Все просто на самом деле если усвоить, что любая транзакция это контракт.
Контракт A -> B в переводе на человеческий звучит так: "я знаю приватник А, битки из А разрешается потратить любому, кто знает приватник В"
Контракт B -> C в переводе на человеческий звучит так: "я знаю приватник В, битки из В разрешается потратить любому, кто знает приватник С"
Теоретический вопросик.
Допустим, нужно передать битки с адреса А на адрес С через адрес В, то есть A -> B -> C, но приватник адреса В известен не только мне, но и всему миру.
Если я на локальной ноде отключусь от сети, выполню эти две транзакции (A-B и B-C без RBF) и подключусь снова, будет ли теоретическая возможность у кого-то перехватить монеты на адресе В? Просто я не понимаю, как будет происходить синхронизация этих транзакций, по отдельности или цепочки в целом?
И по RBF, я правильно понимаю, что без этого флага двойная трата сейчас практически невозможна?
Допустим, нужно передать битки с адреса А на адрес С через адрес В, то есть A -> B -> C, но приватник адреса В известен не только мне, но и всему миру.
Если я на локальной ноде отключусь от сети, выполню эти две транзакции (A-B и B-C без RBF) и подключусь снова, будет ли теоретическая возможность у кого-то перехватить монеты на адресе В? Просто я не понимаю, как будет происходить синхронизация этих транзакций, по отдельности или цепочки в целом?
И по RBF, я правильно понимаю, что без этого флага двойная трата сейчас практически невозможна?
Jump to: