Neo: Adding Block Lock Time

[kevaundray]

Problem

• With the change in gas prices, one solution for cheaper and faster transactions are channels. A pre-requisite for having channels on a blockchain is to have time locked contracts. If time locked contracts are not employed, then a party could decide to not co-operate in the channel and the channel will be open indefinitely, unless a centralised service administrates.

• Currently for ICOs that activate after block X, users must constantly watch the block height and or rely on a third party service to ensure that their transaction is included in a closest block after block X.

Solution

Adding a new Field to the transaction structure: "BlockLockTime".

• If set to zero, then this means that the transaction can be included in the next block.
• If set to Block X, then the transaction should be kept in the mempool until block X.

Additional

If wallets automatically set the BlockLockTime to the current block, then an attacker or faulty node will not be able to re-arrange transactions into an earlier block, if a fork occurs.

[wy]

+1 from me.

[erikzhang]

https://github.com/neo-project/neo/blob/35ff9a68010bdddc160840f222df13c3c46290f6/neo/Core/TransactionAttributeUsage.cs#L22-L25

Can this be used as an alternative?

[f27d]

Can the smart contract access that information through a call?

[erikzhang]

You can get the current height of blockchain at runtime.

https://github.com/neo-project/neo/blob/35ff9a68010bdddc160840f222df13c3c46290f6/neo/SmartContract/StateReader.cs#L84

[kevaundray]

@erikzhang Yep, the nodes can check the script attribute instead of a fixed transaction field.

In terms of performance, I am not sure which is faster. Nodes could either keep a cache of the blocklocktimes for each transaction that has it, or they could check upon each consensus round.

Additional characters may need to be prepended to the blocklocktime so that the node, so that it can easily know whether the Script attribute contains an address or the blocklocktime.

[toghrulmaharramov]

I think a better solution would be to add a new transaction types for the lock time transactions. Adding lock time to old transactions types would mean that the majority of transactions are going waste 8 bytes. If we assume that we will hit a stable 1000 tps at some point in the future, roughly 8x1000x60x60x24x365=252,288,000,000 bytes are going to be wasted every year if you don't count the transactions which actually use the lock time feature.

[vncoelho]

You two little devils around here, @decentralisedkev and @toghrulmaharramov. aheuaheauhuea

[vncoelho]

@erikzhang and @igormcoelho, maybe the current SC capabilities can already handled this.

I think that this issue can be closed, right?

[igormcoelho]

This is already possible on Neo 2.0 using Script field, like Erik said... and just for the record, on Neo 3.0 transaction will (probably) include a special field for transaction expiration, which is very good for accounting.