[SPIKE] Hot wallet vs multisig

[0xean]

• determine most efficient way to send RUNE. Currently two options for rFOX,
  • the script uses a burner hot wallet that is funded, sends out rune, and is never used again.
  • the script is able to generate some reasonably small number of TXs that combine the sends and can be executed by the rune msig. reasonable < 5 for 1000 addresses.
  • document findings here and then create a follow up ticket to add the functionality to the accounting CLI tools

[kaladinlight]

First test of batched sends working: https://api.thorchain.shapeshift.com/api/v1/tx/2DA6C93CE6FDB33E95ECD2D4BB9488D3F50B78ADB977F3568A4550D64547D756

Balance of 1 rune can be seen on both accounts: https://api.thorchain.shapeshift.com/api/v1/account/thor1r0658zpnp3ua3lmtsuhueh96phyfjf3675gqn6 https://api.thorchain.shapeshift.com/api/v1/account/thor1f0wgdh457zqmut9yy4ujmvqzmwrh2wgjke3c88

Next step is to validate transaction size limits to determine how many sends can be batched per transaction to ensure low number of transactions required to execute by MS.

[kaladinlight]

Upon further inspection I am running into two blockers for multi message sends that would be handled by the multisig: 1) Attempts to sign and broadcast a transaction with hundreds or thousands of messages fail simulation with insufficient balance errors. I would have to look into this one further as there is certainly enough balance on my wallet to send. Feels like something that could be solved, but can't say for sure. 2) Assuming the multisig signers would not be importing their wallet seeds into some cmd we would create, they would need to interact with their hardware wallet using the thornode cli or something leveraging thornode which is using an old version of cosmos-sdk that only supports SIGN_MODE_LEGACY_AMINO_JSON. This signing function does not appear to support chunked signing of a transaction which results in a APDU_CODE_OUTPUT_BUFFER_TOO_SMALL error due to memory constraints on hardware wallets. SIGN_MODE_TEXTUAL has since been added to alleviate this situation, but upgrading cosmos-sdk would be a huge undertaking and not feasible. There would be the possibility of potentially porting just the SIGN_MODE_TEXTUAL logic into a locally forked version of cosmos-sdk within thornode, but it would take time and require running a forked thornode cmd that the signers would have to use.

In summary, the multisig route would take quite a bit of custom extra work and would still need to be proven out fully. The main concern with the hot wallet route is the obvious security concerns of ownership of the hot wallet for payout and centralized control of it, but if that is the route we need to take, we can start thinking about different ways to make that as safe as possible, or just define the process and known ownership control setup that can be shared with the DAO. There may be a lot of money potentially funneling through the hot wallet and while I trust us, I would imagine there would be some concern around that. Could be wrong...