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}]'
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).
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.
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"}]'
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.
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.
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.
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.
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).
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.
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.
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.
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?
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
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.
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).
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.