Closed aeyakovenko closed 4 years ago
It would be nice to do this after #3693 to avoid having to duplicate the Transaction format changes in the JS SDK
Note that making the recent blockhash optional using Option<>
would result in an increase in the transaction wire size, so instead we could define a recent blockhash of all zeros to mean "no blockhash"
Hmm, perhaps all we really need to do here is always accept Transactions with a recent blockhash of zero. The creator of such a transaction is responsible for fully spending the from account(s) in such a transaction, the runtime doesn't really need to enforce that constraint.
Too large of a footgun? Perhaps instead of all zeros, we should define that magic recent blockhash to be something like "a1waysgood11111111111111111111" to reduce the risk of accidentally constructing an "always valid" transaction
TODO: Figure out what fee this kind of transaction should incur. Possibly the max cluster fee
@mvines i think the serialize for blockhash has a length, we can set it to 0.
Nope it's fixed length, 32. bincode is smart about that.
Problem
The blockhash in transactions makes cross-chain atomic swaps unreliable. The Solana half of the swap is valid for a short time. While the external chain transaction is replayable until it’s committed.
Proposed Solution
Make the blockhash optional in transactions. These transactions would fully spend an account since they are replayable.