Roll Up Meeting 1 Agenda

[barryWhiteHat]

Meeting Time/Date: Thursday 20 Sept 2018 at 12:00 UTC
https://meet.jit.si/SlyMushroomsCommunicateFlatly

1. Introductions

2. Updates from last meeting

3. Data avilibiilty inside the EVM possible approaches

4. Two options for data availability guarrentees outside the EVM;
   4.1 SNasma + priority que which means that in the happy case users don't have to watch the chain. So that seems like a candidate for POC approach. data availaiblity guarrentees outside EVM  #15 (comment)
   4.2. Another IMO would be the most burned chain approach which removes the needs for exits even in the unhappy case we just have to wait for the attacker to run out of money. Tho that will work best in bigger chains with many tps. Consensus Mechanisim #7 (comment)

5. Data availability inside the EVM V data availability outside the EVM. Which is better for MVP ?

6. Finalize leaf format for zksnark. Are there any undecided decisions which are likely to fundamentally change the circuit and in-circuit leaf format?

6.1 Should we change the signature format. We may be able to add transaction abstraction here.

7. Should we add Replay protection at this layer. If so how?

8. Open requests
   8.1 someone to coord the meetings , take notes organize the issue.
   8.2 someone to record to meetings and put them online.

9. Any other things to talk about ?

[HarryR]

A topic I think is worth considering is:

• Is the leaf format decided and unlikely to change - e.g. UXTO vs account-balance model
• Are there any undecided decisions which are likely to fundamentally change the circuit and in-circuit leaf format?

If so - at what point can we fully specify the leaf format and circuit, and 'stabilise' it, where any further work or changes are unlikely to significantly change the circuit?

Whichever circuit is decided on, we need a short document and Python implementation which specifies it exactly, then the C++ implementation can be made to match after it's been reviewed?

The worst case answer would be 'not sure yet, we have to decide on other things first'. The best case answer is 'no changes to circuit necessary', but likely it'll be somewhere in between?

[barryWhiteHat]

e.g. is there still the question of UXTO or account-balance model for the circuit (as that would change the leaf format)

So i prefer UTXO because if its account an attacker can send you a mystery amount of Wei and then your funds are unwithdrawl. Also Snasma requires one output per leaf.

if not, then we can consider that mostly finalised?

For the circuit i envision mostly proving time optimizations where like hash function change. Tho this may not be possible. Other than that there is replay protection which may live at the circuit level.

[HarryR]

I have described replay protection in: #12 - but that's for leafs which will be updated in-place (e.g. ownership is transferred).

If that's still the model, then that still applies, otherwise I will need to specify replay protection in UXTO model - which could be as simple as using a per-leaf one-time key derived from the owners public key - this can happen in-circuit, or he owner can simply use one-time keys they derive themselves. There is no need for a nonce. However, if you publish signatures for two actions, you don't know which one the operator will include, and the snark circuit can't verify a nonce or sequence etc.

[barryWhiteHat]

If that's still the model, then that still applies

That is still the model. But it is also UTXO model. leaves are transferred but their denomination does not change.

[gluk64]

what's the meeting room for the call?

[barryWhiteHat]

what's the meeting room for the call?

Lets try https://meet.jit.si/SlyMushroomsCommunicateFlatly

[barryWhiteHat]

Close note #20

[maxisacoder]

any online record of this meeting ？ @barryWhiteHat

[barryWhiteHat]

I don't think so. This discussion is probably VERY out of date now. What are you intersted in learning about ?