[Loopring3.6] nonce issue in transfers used by red envelope (RE) and an alternative implementation

[kongliangzhong]

在现在的红包设计中，如果某个账号发红包，会批量的预先将一个范围内的nonce分配给这批红包的transfer：
如发送一个红包，包含10笔转账，nonce为： N+1， N+2, ... N+10。
会导致的问题是：
1）阻塞用户的其他和转账相关的操作：这一批转账没有处理完之前，该用户无法做其他操作（因为Nonce需要自增1）
2）红包中一个人没有接收红包，会导致已经接收了红包的转账也没法处理。如nonce = N+2的转账没有人认领，N+3有人认领了，
但N+3这笔转账也没法处理。

[dong77]

的确是个问题啊

[dong77]

@Brechtpd Kongliang believes there is an issue with the red-envelope use case.

For a RE of 10 recipients, there will be 10 signed transfers, each with a nonce. But when the user authorize another transfer for other purposes and submit the 11th transfer, all 10 transfers in the RE will become invalid, as we require the nonce must be bigger than the last one.

[dong77]

One solution I can think of is to use 0 as nonce in the 10 RE transfers, with a validUntil field. If the once is 0, we skip checking/updating the nonce. Not perfect.

[dong77]

There is another solution, each balance leaf can have more than one nonce, for example, 10 of them:
0......00000
1.......00000
...
9.......00000

then we have 10 paralleled queue...

[dong77]

I talked to Wangyue, seems his idea of using spot-trade to implement RE and vendor-scan-customer-for-payment is much easier than using L2 transfers. #1252

We just need to make sure:

• the user who want to send RE can specify a 0-price order (the RE order), amountS > 0 and amountB = 0；
• the recipients of RE can create a taker to take part of the RE order with amountS = 0 and amountB >0;

I like this idea, maybe can greatly simply transfers and drop dual authoring :)

[yueawang]

I think dual authoring is still useful here as it somehow(depends on impl) prevents the operator from stealing RE, though the operator would not likely to do so. Maybe this new order with dual authoring supports RE better.

[Brechtpd]

For a RE of 10 recipients, there will be 10 signed transfers, each with a nonce. But when the user authorize another transfer for other purposes and submit the 11th transfer, all 10 transfers in the RE will become invalid, as we require the nonce must be bigger than the last one.

This scenario is not really possible, because the circuits enforce the nonce can only increase by 1 so they will always be executed in the same order and no transactions can be skipped. I know this has been the subject of change for quite a few times, but as far as I know this was the consensus recently. #1238

So the only downside here is that they need to processed in the correct order. I guess this could be a problem when the user wants to do multiple red envelopes at once and for some reason one of the red envelopes isn't immediately used so it holds up all transactions behind it? Could be solved in a couple of ways, though admittedly not ideal:

• The payer can sign the same transfers with multiple nonces so they can be executed in any order (just pick the one with the correct nonce at the certain time).
• The account owner can sign a dummy transaction for the red envelope that doesn't have any taker so the nonce is increased and all other transactions after it can go through. He could even be the recipient of his own RE and just create a new one if it's still needed.

There is another solution, each balance leaf can have more than one nonce, for example, 10 of them:
0......00000
1.......00000
...
9.......00000
then we have 10 paralleled queue...

We already have 2D nonces in the form of the orderIDs :). I think the main reason we would want to use orders here is because they already allow parallel nonces in the form of the orderID. So... if we really think this is important for transfers than we may as well just use orderIDs for transfers? It doesn't seem like we want to use any order specific logic here, just the flexibility of submitting transactions in any order. And orders have some limitations as well (pay a protocol fee on the amount transferred, fee can only be paid in % of tokens bought, currently cannot transfer to non-account addresses, ...). It's a transfer, so makes more sense to me to just make the transfers like we want instead of trying to user order matching for this. And if it's not a normal transfer, than let's create a transaction type specifically made to do what it needs to do. There's no need any more to force logic into some other transaction type if it's not a good fit.

I like this idea, maybe can greatly simply transfers and drop dual authoring :)
I think dual authoring is still useful here as it somehow(depends on impl) prevents the operator from stealing RE, though the operator would not likely to do so

Isn't this super important? Otherwise why not just let users use a centralized custodial service if they are not worried about this. :) If the operator can receive all payments done like this it seems to greatly limit the usefulness of this feature.

Another way to do red envelopes would be to use the account system:

• Payer transfers some funds to a new account
• Payer shares the keys for this new account
• Anyone with the keys for the account can transfer the funds to their own address (can be a new address)

This doesn't depend on any strict ordering of multiple txs at different times and is super simple, but it's less efficient and uses up (still precious?) account slots (though I guess they could be reused somehow). :) Not really a problem to increase the account tree capacity though at this point...