Повторні транзакції в Біткойні: цікава, але дуже низькоризикова проблема
Біткойн-транзакції зазвичай здійснюються шляхом посилання на ID попередньої транзакції для використання непотрачених виходів. Ці виходи можуть бути використані лише один раз, інакше це призведе до подвійних витрат. Однак в історії Біткойна дійсно були випадки двох повністю однакових транзакцій. Це стало можливим, оскільки транзакції coinbase не мають входів, а безпосередньо створюють нові монети. Тому дві різні транзакції coinbase можуть надіслати однакову кількість Біткойнів на одну й ту ж адресу і бути побудованими абсолютно однаково, що призводить до їх повної ідентичності. Оскільки ці транзакції однакові, їхні ID транзакцій також співпадають, оскільки ID транзакції є хеш-значенням даних транзакції.
Ці дві групи повторних угод сталися між 14 та 15 листопада 2010 року, тривалість становила близько 16 годин. Перша група повторних угод знаходиться між другою групою. Ми класифікуємо угоди з ID, що починаються на d5d2, як першу повторну угоду, хоча вона вперше з'явилася в блокчейні після іншої повторної угоди.
Ці повторні транзакції мають вартість 50 Біткойн кожна. Загалом задіяно 200 Біткойн, або, залежно від різних розумінь, це може бути 100 Біткойн. В певному сенсі, 100 Біткойн насправді не існують. На сьогодні всі 200 Біткойн не були використані. Якщо хтось має приватний ключ, пов'язаний з цими виходами, вони можуть використати ці монети. Але як тільки їх використають, повторні 50 Біткойн не можна буде використати знову і вони будуть втрачені, тому лише 100 Біткойн можуть бути повернуті.
Повторні транзакції явно є проблемними. Вони можуть ввести в оману гаманці та блокчейн-браузери, а також зробити неясним походження Біткойну. Це також може призвести до деяких атак і вразливостей. Наприклад, хтось може здійснити дві повторні транзакції, щоб заплатити комусь двічі. Коли отримувач намагатиметься використати ці кошти, він може виявити, що лише половина коштів доступна для повернення.
Щоб вирішити проблему повторних транзакцій, у березні 2012 року було впроваджено м'який хардфорк, що забороняє використання повторних ідентифікаторів транзакцій, якщо попередній ідентифікатор транзакції вже не був використаний. У вересні 2012 року це правило було змінено, щоб застосовуватися до всіх блоків, окрім двох згаданих раніше повторних транзакцій.
У березні 2013 року було реалізовано ще один м'який форк, який вимагав, щоб транзакції coinbase містили висоту блоку. Це, здається, повністю вирішило проблему повторних транзакцій, тепер усі транзакції мають бути унікальними.
Однак у деяких блоках, що були створені до активації BIP34, перший байт scriptSig деяких coinbase-транзакцій точно співпадав з висотою блоку, яка стане дійсною в майбутньому. Тому, хоча BIP34 виправив цю проблему в більшості випадків, він не є на 100% ідеальним.
Наступний блок, у якому можуть виникнути повторні транзакції, це 1,983,702, який, за прогнозами, буде згенеровано приблизно у січні 2046 року. Якщо майнери хочуть здійснити цю атаку, їм потрібно не лише достатньо пощастити, щоб знайти цей блок, але й понести величезні витрати, які за поточною ціною Біткойна можуть перевищити 15 мільйонів доларів. Враховуючи складність і витрати на повторення транзакцій, а також те, що можливість їх використання є дуже рідкісною, ця вразливість не виглядає як основна проблема безпеки Біткойна.
Попри це, розробники протягом багатьох років витратили багато часу на цю проблему. Дата 2046 року може бути для деяких розробників останнім терміном для виправлення цієї проблеми. Існує багато способів виправити цю помилку, можливо, знадобиться м'яке розгалуження. Один із можливих способів виправлення полягає в примусовому виконанні зобов'язання SegWit.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
13 лайків
Нагородити
13
7
Поділіться
Прокоментувати
0/400
LiquidityHunter
· 07-25 04:03
Глибокої ночі знову виявлено аномальні дані交易... ризикові точки з指数式 зростання
Переглянути оригіналвідповісти на0
digital_archaeologist
· 07-23 20:32
Взагалі це буде наша справа у 2046 році.
Переглянути оригіналвідповісти на0
PanicSeller69
· 07-22 22:15
У 2046 році це вже занадто абсурдно.
Переглянути оригіналвідповісти на0
SelfCustodyIssues
· 07-22 22:07
2046 трохи далеко, хто ще пам'ятає?
Переглянути оригіналвідповісти на0
PerpetualLonger
· 07-22 21:56
Повна позиція купувати просадку Все зростання - це вказівка небес.
Повторні транзакції в історії Біткойна: причини, вплив та майбутні виклики
Повторні транзакції в Біткойні: цікава, але дуже низькоризикова проблема
Біткойн-транзакції зазвичай здійснюються шляхом посилання на ID попередньої транзакції для використання непотрачених виходів. Ці виходи можуть бути використані лише один раз, інакше це призведе до подвійних витрат. Однак в історії Біткойна дійсно були випадки двох повністю однакових транзакцій. Це стало можливим, оскільки транзакції coinbase не мають входів, а безпосередньо створюють нові монети. Тому дві різні транзакції coinbase можуть надіслати однакову кількість Біткойнів на одну й ту ж адресу і бути побудованими абсолютно однаково, що призводить до їх повної ідентичності. Оскільки ці транзакції однакові, їхні ID транзакцій також співпадають, оскільки ID транзакції є хеш-значенням даних транзакції.
Ці дві групи повторних угод сталися між 14 та 15 листопада 2010 року, тривалість становила близько 16 годин. Перша група повторних угод знаходиться між другою групою. Ми класифікуємо угоди з ID, що починаються на d5d2, як першу повторну угоду, хоча вона вперше з'явилася в блокчейні після іншої повторної угоди.
Ці повторні транзакції мають вартість 50 Біткойн кожна. Загалом задіяно 200 Біткойн, або, залежно від різних розумінь, це може бути 100 Біткойн. В певному сенсі, 100 Біткойн насправді не існують. На сьогодні всі 200 Біткойн не були використані. Якщо хтось має приватний ключ, пов'язаний з цими виходами, вони можуть використати ці монети. Але як тільки їх використають, повторні 50 Біткойн не можна буде використати знову і вони будуть втрачені, тому лише 100 Біткойн можуть бути повернуті.
Повторні транзакції явно є проблемними. Вони можуть ввести в оману гаманці та блокчейн-браузери, а також зробити неясним походження Біткойну. Це також може призвести до деяких атак і вразливостей. Наприклад, хтось може здійснити дві повторні транзакції, щоб заплатити комусь двічі. Коли отримувач намагатиметься використати ці кошти, він може виявити, що лише половина коштів доступна для повернення.
Щоб вирішити проблему повторних транзакцій, у березні 2012 року було впроваджено м'який хардфорк, що забороняє використання повторних ідентифікаторів транзакцій, якщо попередній ідентифікатор транзакції вже не був використаний. У вересні 2012 року це правило було змінено, щоб застосовуватися до всіх блоків, окрім двох згаданих раніше повторних транзакцій.
У березні 2013 року було реалізовано ще один м'який форк, який вимагав, щоб транзакції coinbase містили висоту блоку. Це, здається, повністю вирішило проблему повторних транзакцій, тепер усі транзакції мають бути унікальними.
Однак у деяких блоках, що були створені до активації BIP34, перший байт scriptSig деяких coinbase-транзакцій точно співпадав з висотою блоку, яка стане дійсною в майбутньому. Тому, хоча BIP34 виправив цю проблему в більшості випадків, він не є на 100% ідеальним.
Наступний блок, у якому можуть виникнути повторні транзакції, це 1,983,702, який, за прогнозами, буде згенеровано приблизно у січні 2046 року. Якщо майнери хочуть здійснити цю атаку, їм потрібно не лише достатньо пощастити, щоб знайти цей блок, але й понести величезні витрати, які за поточною ціною Біткойна можуть перевищити 15 мільйонів доларів. Враховуючи складність і витрати на повторення транзакцій, а також те, що можливість їх використання є дуже рідкісною, ця вразливість не виглядає як основна проблема безпеки Біткойна.
Попри це, розробники протягом багатьох років витратили багато часу на цю проблему. Дата 2046 року може бути для деяких розробників останнім терміном для виправлення цієї проблеми. Існує багато способів виправити цю помилку, можливо, знадобиться м'яке розгалуження. Один із можливих способів виправлення полягає в примусовому виконанні зобов'язання SegWit.