possible drop of confirmed transactions

[buggzy]

Sometimes one transaction depends on another transaction(s): successive asset transfers, manipulation with smart-account etc. While transaction order is not strictly manageable, some depended transaction may loss its pre-requirements and will be silently dropped from blockchain during micro-fork reordering. Suppose silent drop of transactions is a great pain for any blockchain solutions.

The issue is mainly resolved by InvokeScript method, "return to UTX" feature (0.17.3) and transaction fee manipulation, however, survival of transaction is still not absolutely guaranteed.

I propose to invite optional field "transaction input id" for all transaction types to allow application developers strictly manage transaction order and ensure 100% dependent transaction survival.

Secondary advantage for "input id" field is opportunity to send multiple dependent transaction at one batch without waiting for its confirmations.

[KardanovIR]

@buggzy thank you very much for your proposal, but could you provide more details about your vision of the solution. You can describe how it should work using WEP (Waves Enhancement Proposal), more details on the forum - https://forum.wavesplatform.com/t/waves-enhancement-proposal-wep-0-unified-proposal-system/14781