Make some transaction headers (TaPOS) an optional requirement

[sunburntcat]

Background

Block ref number and block prefix are currently required for every eosio transaction. This was done to improve fork handling and prevent double-spend of a transaction as it moves around the p2p network. However, this means end users need to query a network RPC node to get this data before they submit a transaction.... usually to the very same RPC node.

In nearly any real-world use case, and end user doesn't care what chain fork they are on, and if they do, it might be best if the RPC node appended that information for them.

Suggestion

Allow RPC node to append and sign TaPOS variables on behalf of an incoming transaction. This could be implemented using the --peer-key and --peer-private-key options present in the Net Plugin. The peer's own signature could be verified at a later stage when transactions are processed to the chain.

Implementing the proposed changes would allow me and another group to continue our work of getting eosio digital signatures from IoT sensors and devices with poor internet connection.

The outcome would also mean client libraries like eosjs could be made more efficient with less back-and-forth "chatter" before transaction POST.

[spoonincode]

Can you quantify a little more just how poor the connection is, and the messaging rate & availability you have available?

You can tapos to the last 2¹⁶ blocks, that's ~9 hours. But a transaction can be submitted to a node with an expiration up to only max_transaction_lifetime seconds in the future from the current time; that's configured for "just" 1 hour on EOS mainnet.

With unique requirements you may have better success with a unique solution crafted to the communication technology and budget you are aiming for.

Consider an example of one option: notify your device every 8 hours (via a unidirectional message) of the block ref and current time -- just three times a day. And then at any time the device can create a transaction and sign it (again unidirectional), but it needs to get that transaction in to the network within an hour of signing it. This would work fine for even a sat based remote sensor provided you don't need to send a high number of transactions a day.

[sunburntcat]

We are using a low-power long-range network (LoRaWAN) that receives packets successfully between 20 and 99% of time, depending mostly on distance and obstacles in the way.

You suggestion is close to our current workaround, although 8-hour notifications are not frequent enough for us. We have opted for 3-hourly notifications for redundancy due to high packet loss. If we increase it much more, there is a legal FCC issue when trying to increase the number of notifications to the nodes, as it's considered "clogging" the airwaves.

The intent of the Github Issue was just to propose the idea of making TaPOS optional, since TaPOS was likely considered necessary at a time where cross-chain communication was given high priority.

Also because client libraries like eosjs could use less overhead, when pushing transactions to a distant node.

[stephenpdeos]

Requiring clients to update their TaPOS fields in the transactions they create periodically is an important part of the design of Antelope and we will not prioritize a change at this time.