Thoughts on transfer commands

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.

But once the transaction is complete then there is no reason to require the transaction be kept. It would be optional wouldn’t it

The transaction is stored perpetually only if a proof is requested. To be defined: is it a flag of the command or an attribute of the receiver key or both or something else.

Something I forgot to mention: the transaction object can only be created by a transaction request and not by a regular PUT request. Otherwise the same kind of forgery I mentioned could be done.

This part I don’t get yet. If the funds are not transferred yet then how can you forge the sending?

Because the proof cannot be simply a piece of text data, even with a signature.

Exhibiting the transaction details together with its signature by the private key of the sender isn’t a proof that the transaction took place because the sender could have signed the transaction offline without broadcasting it to the network.

The only way to prove it, is that the nodes validating the transaction and transferring the amount, also store the proof in the network at the same time they execute these operations.

Another condition is to not allow creation of such proof objects with regular put operations. This is done simply by controlling the type tag of proof objects (same principle to prevent creation from scratch of keys with a non-empty balance).

1 Like

Just a bit of context here. What happens in the background is the section sign the transaction. So the senders section with their section key (that is a provable key as it is held in a chain/linked list of valid section BLS public keys). That is sent back to the sender. So he has a provable record of payment to the receiver from the network that is validatable.

Hope that helps, we have not made that clear.

8 Likes

Very clever. The sender can only get the signature by the section if he has signed and broadcast the transaction.

This way the transaction can be proved without storing its details in the network.

7 Likes

Yes, so initially we had a get_transaction call that the section looked up in a list of recent transactions, but it is a pain and better that we just return the receipt to the sender. If the sender disconnects before getting a receipt then initally it would be lost, but we do have to cater for offline nodes and inboxes along that way so this won’t be so bad as long as they have some safecoin to pay for that storage of their inbox and so on (a rabbit hole we can sort beta/post launch)

7 Likes