Thoughts on transfer commands

This post is to stimulate thoughts on what can be done to improve current limitations of transfer commands (safe wallet transfer and safe keys transfer):

  • I know that they allow transferring from a wallet to a key or vice-versa, but I think more complex scenarios are needed with severals keys and/or wallets.

  • The kind of object (wallet or key) is only checked for the --from argument and not the --to argument.

  • The amount argument should be integrated with the destination keys/wallets to allow splitting the source amount into several keys/wallets.

  • The amount could also be optionally integrated with the source keys/wallets:

    • for verification purpose (check that sum of source amounts equals sum of destination amounts)
    • when user wants to control usage of each source key/wallet (i.e. don’t simply take everything in order from the first to the last source keys/wallet until destination amount is reached)
  • json parameters are needed for all this.

Maybe we can keep safe wallet transfer and safe keys transfer commands for elementary transfers and create a new command for more complex transactions (safe transaction).

Examples:

  • An equivalent of current command safe keys transfer 0.1 --from "safe://key" --to "safe://wallet" would be the new command safe transaction --from '[{"key": "safe://key"}]' --to '[{"wallet": "safe://wallet", "amount": 0.1}]' (the advantage of the new command is that the command handler can check that the url in the --to argument is a wallet)

  • A more complex transaction that transfers 0.1 coins from wallet1 and key1 to wallet2 and key2 (0.05 coins into each):

    • taking everything from wallet1 and the rest from key1: safe transaction --from '[{"wallet": "safe://wallet1"}, {"key": "safe://key1"}]' --to '[{"wallet": "safe://wallet2", "amount": 0.05}, {"key": "safe://key2", "amount": 0.05}]'
    • taking 0.07 coins from wallet1 and 0.03 coins from key1: safe transaction --from '[{"wallet": "safe://wallet1" , "amount": 0.07}, {"key": "safe://key1" , "amount": 0.03}]' --to '[{"wallet": "safe://wallet2", "amount": 0.05}, {"key": "safe://key2", "amount": 0.05}]'

Later on, safe transaction could be improved to allow multisig transactions in several steps, if each signatory issues the same command with the same arguments. The transaction would be valid only when all signatures have been gathered (signed by the private keys corresponding to the addresses in the --from arguments).

To be explored…

26 Likes

This is all great to see and what the guys were really hoping for. People using the CLI to get us the very best API we can for devs to then build on. Thanks @tfa for all of this man. It makes doing the work feel really good and I know the team are really motivated and excited these days. This only helps and it shows the direction the guys have taken here is paying off already.

24 Likes

Yes, very good idea here.

And I’d like the option that the receiver does not see any of the source IDs – or is that the case now.

Can I add if not already tere

  • the option to have a message sent to the ID receiving the coin via secure message but validated by the core to show that the message is from the transfer and not spam or other source trying to trick. EG scammer just sends secure messages saying they bought an item hoping the merchant gets confused and sends the scammer’s ID the item rather than the legit person or whatever reason, don’t get hung up on my silly example. This is because sender ID is not sent with the transfer.

So maybe add a message field to the IDs receiving the coin allowing paying two separate merchants (or for whatever reason for doing so) with the one transaction.
[{"wallet": "safe://wallet1" , "amount": 0.07}, {"key": "safe://key1" , "amount": 0.03}]' --to '[{"wallet": "safe://wallet2", "amount": 0.05, "message": "For the key ring"}, {"key": "safe://key2", "amount": 0.05, "message": "For the coffee mug"}]'

8 Likes

That’s a good idea. Another way to achieve a similar thing, but maybe in a more flexible way, would be to have a ‘metadata’ JSON object field. It could contain a message as you say, or other application specific data related to the transaction.

3 Likes

There is a problem with that though as I aluded to. The reason is that a scammer could make messages without the transaction happening and hope to confuse the receiver who is receiving many transactions for the same e-item and the scammer hopes to receive the e-item in place of another legit ID

The message has to be crypto associated with the received coin and that association created by the network and can be verified.

EDIT: or did you mean something like a order number/receipt number?
If so then the message portion is optional so the option is to use it or other method.

3 Likes

I meant something like:

[{“wallet”: “safe://wallet1” , “amount”: 0.07}, {“key”: “safe://key1” , “amount”: 0.03}]’ --to '[{“wallet”: “safe://wallet2”, “amount”: 0.05, “metadata”:{“message”: “For the key ring”,“additionalData”:“tx1 data”}}, {“key”: “safe://key2”, “amount”: 0.05, “metadata”:{“txData”:“more data for tx2”}}]

4 Likes

Ah I see. Good idea. One of my big issues is to allow anonymity as much as possible so to allow the sending of coin without the source ID being revealed to the receiver is necessary and to replace that lack of sender ID an optional message (or metadata) is needed in some cases.

2 Likes

Of course it does. Anonymity would dictate the least amount of information being sent and the new method allows this if implemented.

Also if one is pulled up in front of a court then they may be required to log into their account and allow the authorities to peruse their transactions. So in fact a receiver then could reveal my transactions to them.

So yes it is best if the sender ID can be hidden. If sender/receiver is known to both then throwaway IDs are of no use since the transaction to your throwaway ID is revealed too and able to be traced back is you have to reveal your account to the authorities or hacker.

2 Likes

I don’t think this is the case. The receiver will just see his wallet/key balance increase magically without any link with the sender. This is good for anonymity.

But sometimes we need a proof of the transaction, so an optional message sent to the receiver(s) would be useful in these cases like proposed by @neo. Another possibility would be to just add a flag to the command to send automatically the transition details to the receiver(s).

4 Likes

If you read fully my post then you would see I addressed this. The link is in the senders account and is visible if the account is investigated. So not anonymous. The idea is like @tfa said do not have the sender ID at all in the transaction, problem solved.

3 Likes

Yes. As long as the information exists in any form, account… there is a possible scenario where it will be uncovered.

2 Likes

But for future exchanges, other services and such that connects to the SAFE-network, being able to send with user ID might be good/necessary?

I feel like this is a discussion about the core values/mission of the project. As I see it the core mission of the project is to stop mass surveillance possibilities by corporation/goverments, but not create total anarchy, to show senders ID might not be so bad.

I can only guess that when SAFE is released in the future the methods by govements and such might go more agressive with hacking/put monitoring hardware/software on individuals computers. Kind of a similar problem with bitcoin, if people move more of their savings from banks to Bitcoin then robbers will target people more instead of hacking banks.

1 Like

Thus the message/metadata field. It will be able to do a lot more then any ID info could.

2 Likes

This post addresses multiple topics, mostly about hardware wallets but the overall best fit seems to be this topic I think. So apologies for maybe putting a second idea in this topic; mods feel free to move it if you want.

The wallet / transaction api needs (yes, needs) to have an option to generate unsigned transactions, and to sign unsigned transactions. Much will be lost without this functionality. To clarify, currently there’s only the option to transfer, ie do both the transaction creation and signature all in one operation. This is a handy shortcut but the lower level create+sign operations still need to be available.

Trezor and any hardware wallet depends on it. Offline signing depends on it. Multisig depends on it. Threshold signing depends on it.

And in a similar line of thought, it would be great to standardise the distribution of partially signed transactions. This is an extremely important aspect of transacting and nobody has provided a decent solution yet. BIP 174 Partially Signed Transaction Format is a good place to start in the history of this topic.

Worth looking at Trezor developers guide too, especially the Message Workflows section.

The specifics of crafting unsigned transactions (eg coin selection) is pretty niche but is important for power users.


I like the idea in general.

But message must be constained in size. See OP_RETURN for reasons. But free txs sorta makes constraining the size pointless, just repeat until done. Maybe charge a fee for tx if it has a message, otherwise free?

9 Likes

Does a transfer now also send a secure message to the receiver ID informing them of the transfer? That was one of the real early ideas when coins were data objects.

So my thought was the message field would be included in the secure message.

If not then are secure messages being charged? If they are then yes the message/metadata field should involve a payment i guess

2 Likes

Ah right I see so this is separate to the transaction itself. In that case it will need to be paid for as per normal message data. Thanks for clarifying.

BIP70 Payment Protocol is also handy to see what considerations might be useful in the transaction process. I’d have to say bip70 has been a failure so far and hasn’t been adopted to the degree it maybe should have, but it’s still got some useful consideration behind it that’s worth being aware of.

2 Likes

But still sent as part of the transaction process performed by the network software.

1 Like

Exactly, this was my idea at the end of the OP: add subcommands to the safe transaction command to manage signatures by several participants.

But this means that the transaction must be stored in the network with parts of and then all the signatures.

It is the same for mono signature transaction when the user wants a proof (either the sender or the receiver): a transaction must exist that stores the signature.

In both cases this is not a zero-cost transaction and would probably need a fee to avoid spamming.

In the case of a simple mono signature transaction without proof, a transaction doesn’t to need to be stored in the network. If I understand correctly, the client managers check the sender’s signature (like any other request) which validates the transaction.

So, the user has a choice to make between proof or anonymity. In summary:

Transaction type Transaction stored in the network Complete anonymity
One sender without transaction proof No Yes
One sender with transaction proof Yes No
Several senders Yes No

There is also multi-sig with a BLS key, which I think falls in the case of one sender. But this doesn’t mean that transactions with several senders are redundant with BLS keys, because this is not the same feature:

  • multi-sig address: the quorum of owners of this address must sign the transaction

  • multi-sig transactions: all the private keys associated with the addresses present in the transaction must the sign the transaction (and for a BLS key a unique signature represents a set of users for one address).

For example, bitcoin network has both.

2 Likes

Can you explain why the transaction has to be stored. I don’t see the requirement.

2 Likes

The transaction needs to be stored in the network to prove that it took place because you could just sign it without broadcasting it.

As sender this is called false invoice. As receiver this is called money laundering. In the latter case you need the collision of the sender to sign it, but this is possible.