Interactive mode for transactions command

[b00f]

zarb tx command is a good solution for sending a raw transaction to the network offline.
User can make a raw transaction first, then using zarb key command sign it and later broadcast it to the network manually.

However to make it easier, we can have an interactive mode for sending transaction. For example for transfer amount we can have something like this:

zarb tx interactive send --sender=<sender_address> --receiver=<receiver_address> --amount=<amount> --memo=<memo> --endpoint=<grpc_endpoint> --key=<path_to_key> --auth=<key_password>

Using gRPC endpoint we can retrieve latest block hash for the transaction stamp and sender sequence number. Fee also can be calculated from amount. Transaction information can be shown to user like this:

You are going to sign and broadcast this transaction:
{
    "Version": 1,
    "Stamp": <stamp>,
    "Sequence": <sequence>,
    "Fee": <fee>,
    "Type": 1,
    "Payload": {
      "sender": <sender_address>,
      "receiver": <receiver_address>
      "amount": <amount>
    },
    "Memo": <memo>,
  }

Do you want to sign it? [Y/n]

If user agreed with the given information, transaction can be signed:

your transaction successfully signed:
0x<raw_signed_transaction_data>

Are you sure you want to broadcast it to network? [Y/n]

Then we can broadcast the signed transaction and show the transaction id:

Your transaction id:
0x<transaction_is>

[khaninejad]

What if we make the first transaction without the network itself and give ranking to validators but in meantime, allowing sender and receiver to validate themselves(pending transactions until approved by the network with some limitations)
For example, I am giving money to my friend, this deal is valid between them so there is no one to verify the transaction at the time and there is no access to verifiers to broadcast it to the network.
That transaction only valid between these two people. Afterward, the sender or receiver meets another node or finds a way to network and broadcast it to the network. If they don't have access as well, then just increase the transaction rank and hold the transaction to pass to others, and give them some credit for this participant.
When a single node finds a way then broadcast the pending transactions to the whole network and the receiver gets the authority over the amount he/she received until that time, he/she only has the permission to cancel it and return it to the sender without any transaction fees but, after validator verification, it is committed and there is no way to cancel the pending transaction.
So in this way, I think we can guarantee the decentralization using these peers. But if a node gets direct access to the network, then there is no need for the above procedure.
It is a just raw idea or maybe its already implemented

[d4rk5h0t]

I'm learning about blockchains as well and I believe you're trying to describe some kind of lightning network operating off-chain.
but unfortunately we dealing with trust-less network nodes within blockchains and I don't believe your approach is feasible.
imagine this, you sign your transaction and pass it off to your opponent with valid seq number and signature there is no guarantee that you won't publish another transaction to main chain and obsolete the one given your opponent with same seq number and so.
at lightning network we escrow some amount on main chain for this process first so even though it's off-chain but still is trust-worthy so at the end of day you need a node running network publish your transactions
@b00f feel free to correct or improve

[d4rk5h0t]

@b00f
I suggest we separate CLI from main code base and let it be totally interactive,
I'd suggest that ship out CLI like a wallet tool with it's own config files indicating key files locations and so on.
when user tries to send transaction we can enter an interactive mode selecting type of transaction and the the payload inputs step by step rather than forgettable flags .
we can even query RPC servers from bootstrap or let user save preferred servers in config.

[b00f]

This is a bit nosiy. We right now have a config for running the node. Having another config for CLI is hard to explain and document.

[khaninejad]

What do you mean by interactive?

[b00f]

@khaninejad

Your idea sounds like lightening network for bitcoin. You are thinking out of box. Good! Your point is keeping a valid transaction off chain and if there is any dispute, using blockchain to resolve it. Keep it open and later we might have similar solution for scaling the Zarb. I highly motivate you to read and study more in this topic.

About interactive, maybe this is bad of me choosing a confusing word. Interactive mode here means, try to query a node in the network to make a transaction.

For example, sequence number is important for creating a transaction, we can query this number from a node (any node that has open gRPC endpoint) to make a transaction. Then users don't need to enter it manually. Also it helps user to broadcast the transaction trough gRPC after signing the transaction.

Hope this helps.

[b00f]

Using GUI users can send transactions easier. Also wallet helps user to create and sign transactions by just providing the required information. We can close this discussion now