Wow, that was neat, guess your idea solves this, but I’m a little bit worried that it would make our circuits complicated. Do you have any approximations on how hard would it be for the operator to generate proofs for this? Are those circuits even feasible to construct in SNARKs?
Didn’t understand this part actually.
I guess we can’t use an encoded version of this bitmap here (RSA accumulators/Merkle-trees etc), because it would need a proof and brings back all the data-availability problems we had. So this touched-leaves thing should be completely public, and a bitmap is the most compact way of storing it (In case the number of txs were small, we can send the list of account-ids instead of the entire bitmap)
If all these works I guess roll-backs are not needed anymore. Right?
I think the only special circuits for this would be hashing and signature verification. This is for sure available.
It’s hard to give any approximations, my gut feeling is that it wouldn’t increase the required circuits by a factor of 2x
If a participant signs the proposed transaction bundle for the next block, the participant knows which transaction can be in the next snapp. But still, they don’t know exactly, which ones will be included, as they can not prediction who double signs their transactions. However, in order to calculate the next state, he needs to know exactly, which transaction was included.
The participant would usually get this information from the operator, but if he does not get the information, he can find these transactions by trial and error.
I don’t see the data unavailability problem araising here:
Either your transaction is in a block, but then you have double signed it and know the data, or your transaction is not in the block, but then you can generate the exclusion proof without knowing the actual data from this block. (I have never seen rsa accumulators in a snark, this might not be possible at all and needs further investigation)
The issue with this double signing is that user need to be online, each time their balance sheet is touched(even if they are only receivers). So, if double signing works out, snapp developer could choose whether they prefer roll-backs or double signing. Both options might be cumbersome for the users
Instead of having a 0/1 TouchedLeaves bitmap, each cell of our bitmap can be Null ( N ), Send ( S ), or Receive ( R )
We require only the sender of a payment to double sign hash of all transactions. (The sender only signs this hash if the operator has given him both the merkle-proof for his account and also the receiver account)
A receiver doesn’t accept a transaction if the sender is not giving him the merkle-proof.
Anyone can exit from his latest “send” or the "receive"s after his latest “send”. E.g. if the state of my account is like: NNRNNSNRNSNNNSNNNRNNRNN, I can withdraw my funds from the latest S or two latest Rs.
(Note that I can’t send funds to people if I don’t know the merkle-proof of my latest receive, so I should withdraw my funds from the latest “send”, I don’t re-deposit my money to this network because the operator is also malicious as he is not giving me the corresponding merkle-proofs of my account)
Yeah, I like that. That should work well for usual transactions.
Nostalgia, this feels like sending double signatures to the payment receiver
I think your proposal should work very well for usual payments, although the bitmap (tri-map) might get quite expensive. And this has the advantage over the usual plasma that there is no need to rush with an exit. It has also its appeal compared to plasma cash, as no coin splitting is needed.
However, my hope for plasma snapp was that we can tackle more complex state updates than just transactions. Adapting your concept to general state transitions might not be viable in many situations. Let’s keep on thinking about it.
