Neo: Transactions should contain the height of the latest block

[erikzhang]

Transactions should contain the height of the latest block so that we can clear the old transactions from the memory pool after a certain number of blocks. And users can also know how long their transactions will expire if they are not confirmed.

[igormcoelho]

Very good idea Erik! I guess this also helps solving this https://github.com/neo-project/neo/issues/371, which is being done to protect users, but it's not mandatory. With an official block height, then filters will be able to work better on tx pool.

[jsolman]

I actually think it should be the responsibility of transactions to determine how long they are valid rather than the nodes to impose a max time they are valid. As long as the pool isn’t full and therefore ejecting transactions, if I want my transaction to stay valid for a week or some long amount of time until it is either confirmed by a CN and makes it into a block or gets ejected due to the max pool size and sorting ejecting it, shouldn’t NEO support that use case?

[jsolman]

Why not just make the max pool size smaller and let them naturally drop out due to sort order?

[belane]

where would the block number be added, in the remark or in a new field?
Should the hash of the previous block also be included to guarantee that the transaction has been created at the moment?

[shargon]

This could be used as nonce, and help with https://github.com/neo-project/neo-gui/issues/252

[erikzhang]

where would the block number be added, in the remark or in a new field?

In new filed I think.

[shargon]

What happens if this field is fake, and people send a value higher than they have? you don't know if this block exists

[belane]

@shargon it also must include the hash of that block, or use it in the TX hash computation ~.

[igormcoelho]

What happens if this field is fake, and people send a value higher than they have? you don't know if this block exists

@shargon, I think we should include block height and block hash (or only hash). If P2P gets a message with height superior than existing one, it's dropped automatically.

[igormcoelho]

@jsolman as soon as we have this height, we establish some limits. What is reasonable in practice? 10 blocks ahead? 100 blocks? 1000 blocks? all of them are possible, but without this height we won't be able to put any limit.

[igormcoelho]

Just realized we don't need to change anything on Neo (again!) because it has nearly everything out-of-the-box.
Let's attach the following Script on any transaction, so we can identify it's block height:

PUSHBYTES5 0011223344 (5 bytes for block height)
SYSCALL System.Blockchain.GetBlock (5 bytes with interop hash)
SYSCALL System.Header.GetHash (5 bytes with interop hash)
PUSH0 (start index for substr)
PUSH4  (size for hash verification)
SUBSTR (take substring from block hash)
PUSHBYTES4 aabbccdd (expected bytes from block hash +4 bytes)
EQUALS (verify if that's correct)

This script will take roughly 30 bytes, plus 20 bytes on Script field... it's more than a static field, but we don't need to change a thing! We can just use it for whatever we want... so, what's the idea, priority for older tx? drop tx that live too much? :)

[jsolman]

I think the concept of @igormcoelho script solves the problem if sender wants their transaction to expire. Do we want to keep this open?

[shargon]

i like your proposal igor :)