Privacy: Don't not collect names & Twitter handles

[vietlq]

It's the best to capture a secret field where people can put whatever they want or pre-generate a 16 digit/char PIN/code

[makoto]

BlockParty is an event management system and majority of the case we do need to collect name for building security purpose.

Twitter handles is collected so that we can notify users.

We are planning to start collecting email, name, and twitter handles as part of the registration system and keep it offline (aka storing on normal dbms). Once that's done, probably we just ask people to sign transaction and turn the digital signature into QR code which admin can scan.

Please let me know if you can think of other alternatives.

[vietlq]

You can collect those data and Merkelize them. The register function needs only Merkle proof to keep the gas cost consistent & predictable. Users should only sign on the Merkle proof, and not on variable sized input data.

[makoto]

How do you collect the data to construct the Merkle proof if register is the first function user interact with BlockParty? Would you mind describing end 2 end flow specifying which part is on chain, and which part is off chain?

[makoto]

Also, it would be a good idea to let event organiser to decide whether they want to collect personal info or not. For some casual dinning event, they don't really need to collect any info as long as they can proof the registration.

[vietlq]

1. User enters name, twitter (off-chain)
2. User clicks Submit (off-chain) 2.1. Name & twiter & random seed are sent to the company (off-chain) 2.2. Name & twitter & random seed are mekelized (off-chain) 2.3. Merkel proof of name & twitter & random seed to be signed with Ethereum browser (on-chain)
3. On the event day they user just presents his/her name/random seed and the company can verify & enroll (off-chain & on-chain)
4. On the refund, the user can claim without seed (on-chain)

The seed can be any random 16 chars/num to avoid collision of users who have the same name but both have no twitter. The seed can be generated by the service when loading the web page and user should not be able to change it. I have done similar thing using UUIDv4 on server:

https://github.com/vietlq/enki-login/blob/master/enki-login-app/controllers/mongodb.ts

[vietlq]

For some casual dinning event, they don't really need to collect any info as long as they can proof the registration.

That's exactly why we need random seed. UUIDv4 is standard and user-friendly. It can be hashed/merkelized without or with empty name/twitter.

Simple way to get hash data that is reproducible from organiser's DB: HASH(version || HASH(name || twitter || UUIDv4)). The same data is hashed, signed & hash is published to the chain by the attendees. Everyone can verify signed hash without revealing private info to 3rd parties! Works well even with name & twitter empty. No encryption required and no more fluctuating gas costs!