Giao dịch trùng lặp trong Bitcoin: một lỗi thú vị với rủi ro tối thiểu

Tiêu đề gốc: "Các giao dịch trùng lặp của Bitcoin"

Nguồn gốc: BitMEX Research

Có hai tập hợp giao dịch giống hệt nhau trong chuỗi khối Bitcoin, một tập hợp giao dịch "kẹp" tập hợp giao dịch kia và cả hai đều xảy ra vào giữa tháng 11 năm 2010. Các giao dịch trùng lặp có thể dẫn đến nhầm lẫn và các nhà phát triển bitcoin đã đấu tranh với vấn đề này theo nhiều cách khác nhau trong nhiều năm qua. Vấn đề này vẫn chưa được giải quyết 100% và giao dịch trùng lặp tiềm ẩn tiếp theo có thể xảy ra vào năm 2046. Mặc dù rủi ro liên quan đến giao dịch trùng lặp hiện nay là rất nhỏ, nhưng đây vẫn là một điều kỳ lạ thú vị đáng để suy nghĩ.

Tổng quan

Một giao dịch Bitcoin thông thường sử dụng ít nhất một đầu ra của giao dịch trước đó bằng cách tham chiếu đến ID giao dịch (TXID) của giao dịch trước đó. Những đầu ra chưa sử dụng này chỉ có thể được sử dụng một lần, nếu chúng có thể được sử dụng hai lần, bạn sẽ chi tiêu gấp đôi số Bitcoin của mình, khiến nó trở nên vô giá trị. Tuy nhiên, thực tế có đúng hai tập hợp giao dịch giống hệt nhau trong Bitcoin. Điều này có thể thực hiện được vì giao dịch coinbase không có bất kỳ dữ liệu đầu vào giao dịch nào, mà thay vào đó là các đồng tiền mới được tạo ra. Do đó, hai giao dịch coinbase khác nhau có thể gửi cùng một số tiền đến cùng một địa chỉ và được xây dựng theo cùng một cách chính xác, khiến chúng trở nên giống hệt nhau. Vì các giao dịch này giống hệt nhau nên TXID cũng khớp nhau vì TXID là bản tóm tắt băm của dữ liệu giao dịch. Cách duy nhất khác để sao chép TXID là thông qua xung đột băm, điều này được coi là không có khả năng xảy ra và không thể thực hiện được đối với các hàm băm an toàn về mặt mật mã. Va chạm băm như SHA256 chưa bao giờ xảy ra trong Bitcoin hay bất kỳ nơi nào khác.

Cả hai bộ giao dịch trùng lặp đều xảy ra vào cùng thời điểm, giữa 08:37 UTC ngày 14 tháng 11 năm 2010 và 00:38 UTC ngày 15 tháng 11 năm 2010, trong khoảng thời gian khoảng 16 giờ. Bộ giao dịch trùng lặp đầu tiên được kẹp giữa bộ giao dịch thứ hai. Chúng tôi phân loại d5d2….8599 là giao dịch trùng lặp đầu tiên vì nó là giao dịch đầu tiên trở thành giao dịch trùng lặp, mặc dù, thật kỳ lạ, nó xuất hiện lần đầu trên chuỗi khối sau một giao dịch trùng lặp khác, e3bf….b468.

Chi tiết giao dịch trùng lặp

Trong các hình ảnh bên dưới, bạn có thể thấy hai ảnh chụp màn hình từ trình khám phá khối mempool.space, hiển thị giao dịch trùng lặp đầu tiên được lặp lại trong hai khối khác nhau.

Điều thú vị là khi các URL có liên quan được nhập vào trình duyệt web, trình khám phá khối mempool.space mặc định sẽ hiển thị khối trước đó trong trường hợp d5d2….8599 và khối sau đó trong trường hợp e3bf….b468. Blockstream.info và Btcscan.org có cùng hành vi như mempool.space. Mặt khác, theo thử nghiệm cơ bản của chúng tôi, Blockchain.com và Blockchair.com hoạt động khác nhau và luôn hiển thị phiên bản mới nhất của giao dịch trùng lặp khi nhập URL vào trình duyệt.

Trong số bốn khối được đề cập, chỉ có một khối (khối 91.812) chứa các giao dịch bổ sung. Giao dịch này kết hợp đầu ra 1 BTC và 19 BTC thành một đầu ra 20 BTC duy nhất.

Những đầu ra này có thể được chi tiêu không?

Vì có hai bộ TXID giống hệt nhau nên điều này tạo ra vấn đề tham chiếu cho các giao dịch tiếp theo. Mỗi giao dịch định kỳ có giá trị 50 BTC. Do đó, các giao dịch lặp lại này bao gồm tổng cộng 4 x 50 BTC = 200 BTC hoặc tùy theo cách bạn hiểu, 2 x 50 BTC = 100 BTC. Theo một cách nào đó, có 100 BTC thực sự không tồn tại.

Tính đến hôm nay, toàn bộ 200 BTC vẫn chưa được chi tiêu. Theo như chúng tôi biết (và chúng tôi có thể sai ở đây), nếu ai đó có khóa riêng được liên kết với các đầu ra này, họ có thể chi tiêu số bitcoin đó. Tuy nhiên, sau khi chi tiêu, UTXO sẽ bị xóa khỏi cơ sở dữ liệu và do đó 50 BTC trùng lặp sẽ không thể chi tiêu được và bị mất, do đó chỉ có thể khôi phục được 100 BTC. Về việc những đồng tiền đó sẽ đến từ khối nào nếu chúng được chi tiêu, sớm hơn hay gần đây hơn, điều này có thể không xác định hoặc không thể xác định được.

Người này có thể đã chi hết số bitcoin trước khi tạo giao dịch trùng lặp, sau đó sẽ tạo ra các đầu ra trùng lặp, tạo ra các mục mới trong cơ sở dữ liệu về các đầu ra chưa được chi. Điều này không chỉ có nghĩa là các giao dịch trùng lặp mà còn có thể là các giao dịch trùng lặp có thể có kết quả đầu ra đã chi trùng lặp. Nếu điều này xảy ra, khi các đầu ra này được sử dụng, nhiều khả năng sẽ có nhiều giao dịch trùng lặp được tạo ra, hình thành nên một loại chuỗi trùng lặp. Người ta phải cẩn thận với thứ tự các sự kiện và luôn chi tiêu trước khi tạo bản sao, nếu không số bitcoin có thể bị mất mãi mãi. Những giao dịch trùng lặp mới này sẽ không phải là giao dịch coinbase mà là giao dịch "bình thường". May mắn thay, điều này chưa bao giờ xảy ra.

Vấn đề về giao dịch trùng lặp

Giao dịch trùng lặp rõ ràng là không tốt. Chúng gây nhầm lẫn cho các ví và trình khám phá khối, đồng thời che giấu nguồn gốc của bitcoin. Nó cũng mở ra nhiều cuộc tấn công và lỗ hổng. Ví dụ, bạn có thể trả tiền cho ai đó hai lần với hai giao dịch trùng lặp. Sau đó, khi các bên giao dịch quyết định thử tiếp cận số tiền này, họ có thể thấy rằng chỉ có một nửa số tiền có thể thu hồi được. Ví dụ, đây có thể là một cuộc tấn công vào một nền tảng giao dịch nhằm mục đích phá sản nền tảng đó mà kẻ tấn công không phải mất gì cả vì chúng có thể rút tiền ngay sau khi gửi tiền.

Cấm giao dịch sử dụng TXID trùng lặp

Để giảm thiểu vấn đề giao dịch trùng lặp, vào tháng 2 năm 2012, nhà phát triển Bitcoin Pieter Wuille đã đề xuất giải pháp soft fork BIP30, cấm sử dụng TXID trùng lặp cho các giao dịch trừ khi TXID trước đó đã được chi tiêu. Bản phân nhánh mềm này áp dụng cho tất cả các khối sau ngày 15 tháng 3 năm 2012.

Vào tháng 9 năm 2012, nhà phát triển Bitcoin Greg Maxwell đã sửa đổi quy tắc này để kiểm tra BIP30 áp dụng cho tất cả các khối, không chỉ những khối sau ngày 15 tháng 3 năm 2012. Ngoại lệ là hai giao dịch trùng lặp được đề cập trước đó trong bài viết này. Điều này khắc phục một số lỗi của DOS. Về mặt kỹ thuật, đây là một soft fork khác, mặc dù thay đổi quy tắc chỉ áp dụng cho các khối cũ hơn 6 tháng, do đó, nó không đi kèm bất kỳ rủi ro nào liên quan đến thay đổi quy tắc giao thức thông thường.

Kiểm tra BIP30 này tốn nhiều tài nguyên tính toán. Nút cần kiểm tra tất cả đầu ra giao dịch trong khối mới và kiểm tra xem các điểm cuối đầu ra này đã tồn tại trong UTXO hay chưa. Đây có lẽ là lý do tại sao Wuille chỉ kiểm tra các đầu ra chưa sử dụng; việc kiểm tra tất cả các đầu ra sẽ tốn kém hơn về mặt tính toán và không cho phép cắt bớt.

BIP34

Vào tháng 7 năm 2012, nhà phát triển Bitcoin Gavin Andresen đã đề xuất kế hoạch phân nhánh mềm BIP34, được kích hoạt vào tháng 3 năm 2013. Thay đổi giao thức này yêu cầu các giao dịch trên Coinbase phải bao gồm chiều cao khối, điều này cũng giúp có thể quản lý phiên bản khối. Chiều cao khối được thêm vào làm mục đầu tiên của tập lệnh giao dịch coinbase Sig. Byte đầu tiên trong coinbase scriptSig là số byte được sử dụng bởi số chiều cao khối và các byte tiếp theo là chính số chiều cao khối. Trong khoảng 160 năm đầu tiên (223 / (144 khối mỗi ngày * 365 ngày mỗi năm)), byte đầu tiên phải là 0x03. Đó là lý do tại sao ScriptSig (HEX) của coinbase ngày nay luôn bắt đầu bằng 03. Bản soft fork này dường như đã giải quyết hoàn toàn vấn đề giao dịch trùng lặp và bây giờ tất cả các giao dịch đều phải là duy nhất.

Vì BIP34 đã được áp dụng nên vào tháng 11 năm 2015, nhà phát triển Bitcoin Alex Morcos đã thêm một yêu cầu kéo vào kho lưu trữ phần mềm Bitcoin Core, một thay đổi có nghĩa là các nút sẽ ngừng thực hiện kiểm tra BIP30. Rốt cuộc, giờ đây BIP34 đã khắc phục được vấn đề này nên việc kiểm tra tốn kém này không còn cần thiết nữa. Mặc dù vào thời điểm đó không ai biết, nhưng về mặt kỹ thuật đây là một hard fork cho một số khối rất hiếm trong tương lai. Hiện tại, khả năng hard fork có vẻ không quan trọng vì hầu như không ai chạy phần mềm node có từ trước tháng 11 năm 2015. Tại forkmonitor.info, chúng tôi đang chạy Bitcoin Core 0.10.3, phát hành vào tháng 10 năm 2015. Vì vậy, đây là quy tắc trước hard fork và khách hàng vẫn đang thực hiện kiểm tra BIP30 tốn kém.

Vấn đề Block,983,702

Hóa ra là có một số giao dịch coinbase trong các khối trước khi BIP34 được kích hoạt và byte đầu tiên của scriptSigs được sử dụng tại thời điểm đó trùng khớp với chiều cao khối hợp lệ trong tương lai. Vì vậy, mặc dù BIP34 khắc phục được sự cố này trong hầu hết các trường hợp, nhưng không thể khắc phục hoàn toàn 100%. Vào năm 2018, nhà phát triển Bitcoin John Newbery đã in ra danh sách đầy đủ các bản sao tiềm ẩn này, như được hiển thị trong bảng dưới đây.

*Lưu ý: Các khối này đã tạo ra các giao dịch Coinbase vào năm 2012 và 2017 và không phải là các khối trùng lặp. 209.921 khối (chỉ cách lần chia đôi đầu tiên 79 khối) không thể là khối trùng lặp vì BIP30 đã được triển khai trong thời gian đó. Nguồn: https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd Số lượng giao dịch Coinbase có khả năng trùng lặp theo năm Nguồn: https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd

Do đó, khối tiếp theo có thể xuất hiện các giao dịch trùng lặp là khối 1.983.702, sẽ được tạo vào khoảng tháng 1 năm 2046. Giao dịch Coinbase ở khối 164.384 vào tháng 1 năm 2012 đã gửi 170 BTC đến bảy địa chỉ đầu ra khác nhau. Do đó, nếu thợ đào vào năm 2046 muốn thực hiện cuộc tấn công này, họ không chỉ cần đủ may mắn để tìm thấy khối này mà còn phải đốt gần 170 BTC tiền phí, với tổng chi phí chỉ hơn 170 BTC, bao gồm cả chi phí cơ hội của khoản trợ cấp khối 0,09765625 BTC.

Với giá bitcoin hiện tại là 88.500 đô la, số tiền đó sẽ tốn hơn 15 triệu đô la. Về việc ai là người sở hữu bảy địa chỉ giao dịch thư viện tiền xu vào năm 2012, vẫn chưa rõ và có khả năng các khóa giao dịch đã bị mất. Hiện tại, cả bảy địa chỉ đầu ra của giao dịch Coinbase này đều đã được sử dụng, trong đó có ba địa chỉ được sử dụng trong cùng một giao dịch. Chúng tôi tin rằng số tiền này có thể liên quan đến chương trình Ponzi Pirate40, nhưng đây chỉ là suy đoán của chúng tôi. Kết quả là, cuộc tấn công dường như không chỉ tốn kém mà còn hầu như vô dụng đối với kẻ tấn công. Sẽ là một khoản chi phí đáng kể để loại bỏ nút tháng 11 năm 2015 khỏi mạng lưới cách đây 31 năm trong một đợt hard fork.

Khối dễ bị tấn công tiếp theo có thể bị sao chép là 169985 vào tháng 3 năm 2012. Coinbase này chỉ có giá hơn 50 BTC một chút, thấp hơn nhiều so với 170 BTC. Tất nhiên, 50 BTC là khoản trợ cấp tại thời điểm đó và khi giao dịch Coinbase này có thể dễ dàng lặp lại vào năm 2078, khoản trợ cấp sẽ thấp hơn nhiều. Vì vậy, để tận dụng lợi thế này, thợ đào sẽ cần phải đốt khoảng 50 BTC tiền phí, mà họ không thể lấy lại được vì phải gửi đến đầu ra cũ từ năm 2012. Không ai biết giá Bitcoin sẽ là bao nhiêu vào năm 2078, nhưng chi phí cho một cuộc tấn công như vậy cũng có thể sẽ cao ngất ngưởng. Do đó, vấn đề này có thể không phải là rủi ro lớn đối với Bitcoin, nhưng vẫn đáng lo ngại.

Kể từ bản nâng cấp SegWit năm 2017, các giao dịch Coinbase cũng có thể bao gồm các cam kết đối với tất cả các giao dịch trong một khối. Các khối trước BIP34 này không chứa cam kết làm chứng. Do đó, để tạo ra một giao dịch coinbase trùng lặp, thợ đào sẽ cần loại trừ mọi giao dịch đổi đầu ra SegWit khỏi khối, làm tăng thêm chi phí cơ hội của cuộc tấn công vì khối có thể không bao gồm nhiều giao dịch khác trả phí.

Kết luận

Do tính khó khăn và chi phí của giao dịch sao chép, cũng như cơ hội khai thác nó rất hiếm, nên lỗ hổng giao dịch sao chép này dường như không phải là vấn đề bảo mật lớn đối với Bitcoin. Tuy nhiên, vẫn rất thú vị khi nghĩ về điều này, xét đến mốc thời gian liên quan và tính mới lạ của các giao dịch lặp lại. Tuy nhiên, các nhà phát triển đã dành rất nhiều thời gian cho vấn đề này trong nhiều năm qua và thời hạn năm 2046 có thể là hạn chót để khắc phục vấn đề này trong tâm trí một số nhà phát triển. Có nhiều cách để khắc phục lỗi này và có thể cần phải thực hiện soft fork. Một giải pháp khả thi là thực thi cam kết SegWit.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia