Should there be a setting that defines how stale a transaction may be? And should the staleness be used for mempool sorting?

Right now, my intention is just to include the height on tx, as Erik proposed. After that, we can see what we can do with that... a lot of good things I hope :)

Perhaps this is too expensive (extra 32B), so if community disagrees with the idea we can simply ignore this PR :)

We could include the block number as well as the first 8 bytes of the hash. That would be less bytes but still sufficient for the purpose this is needed. The number can be verified then by the first 8 bytes of the hash needing to match the block specified.

We need to know.. why we need this field, because the people could fake it, and say, my tx is waiting for 2 hours, should be dropped? should be prioritized? both cases are wrong for me, i preffer tonuse the reception time like now does

@shargon you can’t fake it if you have to put part of the blockhash and the block number in an attribute or something like that when signing the transaction.

We could include the block number as well as the first 8 bytes of the hash.

What does the blockheight add for information? The hash is already indexed and has all the information about the block that you would want (including the height). If you add the blockhash of a recently created block, then you have proof that the transaction is also recently created. Eventually NEO can start discarding stale transactions.

I don't think it's worth while to truncate the hash to the first 8 bytes. It's probably more efficient to just include and compare the whole hash.

@ThomasLobker it is not more efficient to compare the whole hash, and it is less expensive to compare the hash if you know the block number.

The block number is needed to support using less bytes of the hash.

@jsolman if create a TX with the hash of the current height minus 100, what should be the procedure?
A- is waiting 100 blocks, so it should be prioritized because is more spread around the network
B- should be dropped because is waiting to much

If you prioritize new TX instead of old transactions, the spread should be slowly and could be problematic, i don't like this proposal to much

@jsolman I like your solution, 4 bytes on block + 8 bytes on hash (or perhaps less? 4 + 4 bytes is enough? 1/ billion chance).

@shargon I see your point my friend, and I agree that priority should not be given to newest, but to the oldest. This is exactly like an optimization problem with an unbounded variable... if unbounded goes in optimization direction, there's no solution. But if it goes otherwise.. no problem :)
Meaning that, we want to maximize block height, so incentive must go in this direction. How? We can cut the transactions older than an specific value. So, we don't use for sorting, but just to ensure that no transaction will live forever. How much will it live, we can discuss.. 1 day? 1 week? We can calculate.
Thing is, from user perspective, I don't see an advantage to let transactions live more than 1 minute. Independently of this PR, we already have this script done, to attach on transactions and let its live be short (users will also be able to configure expiration time on wallet):

• neon-js: Support block due limit on transactions CityOfZion/neon-js#311
• neon-wallet: Allow configurable block due limit to expire pending transactions CityOfZion/neon-wallet#1417

The problem is, even with these scripts, I cannot guarantee that nodes will actually drop the transactions after time has passed (I only know they won't pass verify anymore), so mempool can become filled with non-executing transactions (as recently discussed with @snowypowers). Adding block height is one of the fewest things that can actually guarantee that no transaction will live forever, on any relay node.

@shargon It seems better to weight old transactions more heavily as they get older.

They are accepted if their weight gets large enough to be accepted before they become so old they drop off. This might mean that a free transaction waiting for quite some time may eventually have more weight than a new transaction that had a very small fee applied, but the one with the fee applied would also have its weight increased as it waits.

We can do that without add this hashes, and is fakeable, if you weight old transactions, i ever can send mine TX with Height-200
Now we attach the receptionDate to the TX, this value is confiable, and we should use this for any propuse

@shargon that is a good point about faking being older. Adding reception date could probably still have problems actually, because a node can’t only rely on its own reception date; it could have just restarted and still needs to accept transactions that were first sent a while in the past.

I think it is better to just make the code be able to handle the full mempool situation better and not try to expire by age. If a transaction wants to ensure it expires by age adding a script to make it invalid is enough.

I think this will be unnecessary after the mempool changes.

Well done.