Open abitmore opened 7 years ago
I guess it won't happen, since I haven't found an instance from the chain. Perhaps it's avoided by some other code that I've overlooked.
So theoretically if a transaction's expiration field is later than last block's timestamp, but earlier than the new block's timestamp, it can still be included in the new block and pass the check?
I think you're right. Probably hasn't happened in practice because it requires tight timing to create the issue, and why should anyone want to do that?
Not a big issue though, IMO. Modifying apply_block to set the new head_block_time before applying txs is likely to interfere with HF dates, so there is a risk associated with fixing that. Perhaps add a check in _generate_block?
Won't fix.
The
expiration
field of transactions is checked in_apply_transaction()
indb_block.cpp
(code):head_block_time()
is implemented indb_getter.cpp
(code):The
time
field is updated inupdate_global_dynamic_data()
indb_update.cpp
(code):But
_apply_transaction()
is called beforeupdate_global_dynamic_data(next_block)
in_apply_block()
(code):So theoretically if a transaction's
expiration
field is later than last block's timestamp, but earlier than the new block's timestamp, it can still be included in the new block and pass the check? Please let me know if I'm wrong.