You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful to transfer blocks between systems for eg. backups:
tr1pctl send @.. | ssh foo tr1pctl recv - would transfer the blocks of the current session to the remote system. This might need to be extended to avoid uploading blocks that are already known by the receiving system.
sftp - blocks are uploaded to a remote server. For sandboxing reasons, this should be done in a separate process and probably needs tr1pctl tail -f #8.
broadcast - tr1pd could be used as a system that announces events to multiple other systems in a secure way.
There's also the usecase to have "merger" nodes that receive multiple inputs and write them to their own ledger. It's important that the information where a block is coming from isn't lost, and that adding this data doesn't exceed a size limit. It might be useful to have a separate field for this. An open question is how blocks should be handled when merged twice, so it would have two "from" fields.
The text was updated successfully, but these errors were encountered:
It would be useful to transfer blocks between systems for eg. backups:
tr1pctl send @.. | ssh foo tr1pctl recv
- would transfer the blocks of the current session to the remote system. This might need to be extended to avoid uploading blocks that are already known by the receiving system.There's also the usecase to have "merger" nodes that receive multiple inputs and write them to their own ledger. It's important that the information where a block is coming from isn't lost, and that adding this data doesn't exceed a size limit. It might be useful to have a separate field for this. An open question is how blocks should be handled when merged twice, so it would have two "from" fields.
The text was updated successfully, but these errors were encountered: