Tổng quan
Một giao dịch Bitcoin bình thường sử dụng ít nhất một đầu ra từ 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 có thể được sử dụng lần, bạn sẽ Chi tiêu hai lần số Bitcoin của mình, khiến Bitcoin 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 cho rằng là không có khả năng xảy ra và không thể thực hiện được bằng các hàm băm an toàn crypto . 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ó trở thành giao dịch trùng lặp đầu tiên, mặc dù kỳ lạ là nó xuất hiện lần đầu trên blockchain sau một giao dịch trùng lặp khác là e3bf….b468 .
Lặp lại chi tiết giao dịch
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ừ Block Explorer 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 nhập các URL có liên quan vào trình duyệt web, Block Explorermempool.space mặc định 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 các giao dịch trùng lặp khi nhập URL vào trình duyệt.
Trong bốn khối đang được đề cập, chỉ có một khối (khối 91.812) chứa bất kỳ giao dịch bổ sung nào. 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?
Điều này tạo ra vấn đề tham chiếu cho các giao dịch tiếp theo vì có hai bộ TXID giống nhau. 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ó private key được liên kết với các đầu ra này, họ có thể chi tiêu 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 toàn bộ 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 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 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 đề giao dịch trùng lặp
Rõ ràng là giao dịch trùng lặp 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 đó 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 sàn giao dịch nhằm mục đích phá sản sàn đó mà kẻ tấn công không phải mất gì vì chúng có thể rút tiền ngay sau khi gửi tiền.
Không cho phép giao dịch với 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 soft fork 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 được á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 mang lại bất kỳ rủi ro nào liên quan đến việc 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 giải pháp soft forkBIP34 , đượ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 coinbase phải bao gồm Block Height, điều này cũng cho phép quản lý phiên bản khối. Block Height đượ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ố Block Height và các byte tiếp theo là chính số Block Height . 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. Soft fork lần 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à 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à 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 nút 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à máy trạm vẫn đang thực hiện kiểm tra BIP30 tốn kém.
Khối ,983,702 Câu hỏi
Hóa ra có một số giao dịch coinbase trong các khối trước khi BIP34 được kích hoạt, trong đó byte đầu tiên của scriptSigs được sử dụng tình cờ khớp với Block Height 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à bản sao. 209.921 khối (chỉ cách giảm nửa lầ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 lần, họ không chỉ cần đủ may mắn để tìm thấy khối này mà còn phải đốt ít hơn 170 BTC tiền phí, với tổng chi phí chỉ hơn 170 BTC một chút, trong đó 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, tất cả bảy địa chỉ đầu ra của giao dịch Coinbase này đã được sử dụng, trong đó ba địa chỉ được sử dụng trong cùng một giao dịch . Chúng tôi cho 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à, lần 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 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ừ nâng cấp SegWit năm 2017, các giao dịch trên 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 lượng lớn 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 phương pháp để khắc phục lỗi này và có thể cần phải thực hiện soft fork. Một phương pháp khả thi là thực thi cam kết SegWit.
