Added Send All #313
Added Send All #313
Conversation
This method should allow users to send all owned omni assets with 1 transaction
| @@ -404,6 +405,23 @@ Say you want to transfer 1 Mastercoin to another address. Only 16 bytes are need | |||
| |Currency identifier| [Currency identifier](#field-currency-identifier) |1 (Mastercoin)| | |||
| |Amount to transfer|[Number of Coins](#field-number-of-coins)|100,000,000 (1.0 coins) | | |||
|
|
|||
| ### Transfer All Coins (Send All) | |||
|
|
|||
| Description: Transaction type 4 transfers all coins from the sending address to the reference address, defined in [Appendix A](#appendix-a-storing-omni-protocol-data-in-the-blockchain). This transaction can not be used to transfer bitcoins. | |||
There was a problem hiding this comment.
... transfers all coins in the available balances of all smart properties owned by the sending address ...
Items that need consideration:
- is this an all or nothing transaction - transfers of all available balances succeed or none of them succeed if at least 1 fails?
- certain sends may be blocked in the future, e.g. a non-transferable SP (maybe that's just not in the available balance), address can reject receipt of specified SPs
- for instance, an address may want to divest itself of one or more SPs and prevent any future ownership of those SPs
- how are failure details reported?
- certain sends may be blocked in the future, e.g. a non-transferable SP (maybe that's just not in the available balance), address can reject receipt of specified SPs
- side effects of transfers, e.g. if the reference address has an open crowdsale for a transferred currency, the sending address would be credited with newly issued coins. This can be handled by the fact that this is not a txtype 0 Send, so the protocol can specify that Send All does not invoke the side effects of txtype 0 Send. That needs a decision.
There was a problem hiding this comment.
WRT side effects, Send To Owners doesn't invoke crowdsale participation (as far as I know) so there's a precedent. The spec doesn't state that, so that's another clarification to be made.
Current behavior of OmniLayer/omnicore#155 is that the transaction is only valid, if at least one token is transferred. This is in line with send to owners transactions, which require at least one receiver to be valid.
I think we'd most likely create a new "tally" type, such as "reserved for sell offers", which is not part of the "available" balance. I don't really see the need for a refinement, but it should be explicitly stated, that only "available" balances are transferred.
The dilemma started with the "grant tokens" implementation (see mastercoin-MSC/mastercore#227), which simply calls the simple send logic. I'm not sure, if the passive effect (i.e. crowdsale participation) was intended, but now we have to live with it, I guess. It would be great, if this would be specified (of course not part of this PR). I'd be fine, if the send all transaction does not trigger crowdsale participations, and thanks for pointing out that send to owners is without passiv effect. This serves as great justification, why send all may not trigger the participation either. |
|
In this context: if the transaction has no receiver, then we assume the sender is the receiver, and the transaction may be a valid "send all to self" transaction. This mirrors the behavior of "simple send". |
|
Send to owners is a great example, thanks! In this context then it seems feasible to make crowdsale participation I'll take a look at whether any grants have ever triggered crowdsale
|
|
I've run through a full parse with some extra code to look for crowdsale participation from a grant and I can't see any, so I'm fairly confident no grants have ever triggered crowdsale participation to date. |
|
In the context of an unrelated discussion about the mutability of transactions with test properties on mainnet: The "send all" transaction currently violates that the main and test ecosystem should be strictly seperated. This has no direct effect on the global state, and the resulting main ecosystem balances [...] are exactly the same in any case, even if we assume the test ecosystem history may not be immutable. However, if we assume the test ecosystem history is mutable, then it may have an impact on transaction validity. Right now a "send all" transaction is considered as valid, if at least one token was transferred, which may be in the test or main ecosystem. To get to the point: I was wondering, if the "send all" transaction should come with an ecosystem parameter, to specify, whether test or main properties should be transferred. |
@dexX7 Yes, all transactions should specify the ecosystem. Also,
In this case, it's not necessarily one whole divisible token, but any fractional amount qualifies. |
Alright, so the new transaction format would be: [version: 0] [type: 4] [ecosystem]
Yup, sure. I was referring to base units. |
|
What about MetaDEx cancels? Is that not the same kind of scenario? Where we allow either ecosystem, or both? Q - why invalidate a 'send all' transaction that does not transfer any tokens. Other "no-ops" are not invalidated:
|
It would probably best to allow only valid ecosystem values, i.e. no wildcard for both. It was initially done this way (with wildcard) due to the transaction message format (with property/property desired).
Hmm.. I think we should get rid of those no-ops altogether. Send-to-self should be allowed, if the receiver is explicitly specified as such, but the current fallback to send-to-self, if no receiver was provided, just seems unnecessary. I'd argue against no-ops with a counter question: do you think we should remove all checks, whether amounts to be transferred/created/... are not zero, and allow sends with zero tokens? |
|
A few words to my motivation in this context: the no-op question could become more relevant in the future. Let's assume we extend the methology of consensus hashes, and not only include balances [...], but also hash a list of valid transactions. To ensure (historical) consensus hashes/checkpoints don't change, this requires that the validity of historical transactions is immutable. Based on your earlier statement, that test property transactions may not be immutable, it follows that the validity of historical transactions may not be immutable either, if transactions without strict main/test ecosystem seperation are involved, thus introducing the chance of changing (historical) consensus hashes. |
I agree here - I think we should have explicit separation of test and main ecosystems. If MetaDEx is the only place we allow a single payload to impact both test and main, then let's close that behaviour now before live.
Nope. But there is a big difference here that needs to be considered, explicit versus implicit actions. Explicit actions, eg "Send X from A to B" should be invalidated if that explicit action cannot be performed, either because X doesn't exist or is insufficient value. But implicit actions, eg "Send {any} from A to B" should not be invalidated if {any} does not have any matches, because no matches is not the same as an invalid value. Just the same as "Cancel {any} trades from A" is not invalid if {any} does not have any matches. In both cases A and B are explicit values and should invalidate if they are not acceptable values. I hope I've explained that right hehe :)
I agree here 100%, which is why I think there should be a "ban" if you will on any transactions that can cross ecosystems (ie single payload = single ecosystem only). EDIT: more accurately single transaction = single ecosystem only, in the context that we may think about multi-payload transactions in the future. |
This sounds reasonable. How about the other MetaDEx cancel operations then? The cancel operations are currently only considered as valid, if trades are really cancelled. |
|
Oh, my mistake - MetaDEx cancels shouldn't be invalid if they don't match
|
I know this is not directly related to Send All, but I think both Send All and MetaDEx cancels should not be invalidated if they do not have any matches. Since MetaDEx isn't live yet I feel we have room to make that change without affecting consensus. Thoughts? |
Supported. |
What do you think to an approach like zathras-crypto/omnicore@a751bef |
|
It's about a month and a 1/2 since the last comment. Where do we stand on this PR? |
|
The "send-all" command is part of Omni Core 0.0.10. The transaction format is as follows: All available (i.e. not reserved) tokens in the given ecosystem are transferred from the sender to the receiver. The transaction is considered as invalid, if no tokens were actually moved, i.e. the sender must have tokens in the given ecosystem. See also the RPC documentation for "omni_sendall". |
|
The transaction "send all" is part of the current consensus rules, so we should build upon this pull request and eventually integrate it. |
This method should allow users to send all owned omni assets in 1 transaction.
More detailed description here
OmniLayer/omnicore#153