timbeiko.eth
@tim
One of the coolest privacy proposals which _could_ potentialy/eventually be used on L1 (and pretty likely on L2s) was presented on ACD today, and they even had nice ELI5 slides 😄 https://docs.google.com/presentation/d/1omnj-y2L59wERsOBQRKjoIKHm5VQ1A6Sdmc2_Oa75IM/edit?pli=1#slide=id.p
5 replies
7 recasts
30 reactions
Harper
@harpcaster
this seems cool! I think I understand. It would "unlock" all of the Eth that had otherwise been burnt/lost by "re-minting" it. And this helps with scalability because it decreases the number of transactions the chain needs to store?
1 reply
0 recast
0 reaction
timbeiko.eth
@tim
Not quite, @harpcaster (A+ handle btw!!). The way it would work is that as a user you send your ETH to an address _you_ know is a burn address but no one can tell from just looking at it. You keep a proof of that. Then, you can make a separate txn, from a diff address which would re-mint the funds from the prev txn.
2 replies
0 recast
1 reaction
timbeiko.eth
@tim
So you can’t tell if ETH in an address is burnt or just sitting there, but to create a valid mint txn, you need a (private) proof that you have previously burnt ETH
1 reply
0 recast
1 reaction
timbeiko.eth
@tim
The intuition for why this works is neat: you use a different hash function to generate the burn address, and the same way it’s impossible to get x if you only know hash(x), you can’t know if an address was created using hashFunctionA(x) or hashFunctionB(x) by looking at the address, but a user can keep the proof
1 reply
0 recast
1 reaction
timbeiko.eth
@tim
So the proposal is that we introduce a new zk friendly hash function to create those burn addresses, but the concern is we don’t have sufficient guarantees they are as safe as keccak, and if they aren’t, you risk having a (potentially infinite) inflation bug.
1 reply
0 recast
2 reactions
