The node will ignore it. In most programming paradigms the Ord code would be considered a bug because it is useless to the functioning of the protocol and just slows it down and takes up space unnecessarily. There are certain things that would be recognized as useful in the witness space like keys, which is what the taproot update intended it to be used for if I understand correctly. Ord in the code is almost like # where everything that comes after it is a comment and not executed. However the Force command is used multiple times to get all the data into the block because in normal circumstances nothing more than 512-bits (I think) is inserted in this place.

Reply to this note

Please Login to reply.

Discussion

I don't so much envision bitcoin core executing the stored code. I envision someone using an external tool to grab the code to run from the blockchain data itself.

The example I've given people is a Happy 21st Bitcoin Birthday NFT airdrop. The backers tell everyone to go download their Umbrel application to manage the airdrop. The Umbrel app is open source and shows no sign of malware. Instead it just looks to execute a future block payload presumably to issue the NFT, or so the creators say. Then after the creators feel confident they have enough nodes with their package they mint a future block that contains the malicious payload.

This attack wouldn't be much different than including an application that just points to a future URL that isn't active yet. It could easily be protected against by anyone auditing the code. That being said I don't think Umbrel users are going to be auditing code. They are just going to install things that seem 'fun' or useful to them. If another cloak with a sufficient story tells them not to worry then I think most just look past it.

I just think it's an interesting attack vector for using the blockchain data as a penetration tool. If every bit of commerce is going to be using Bitcoin in the future then node operators will need to ensure they are using best practices of limiting access to that specific node as much as possible on both sides.