-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Internal transfers without revealing the recipient #23
Comments
Love it. |
So this is just my initial reply. I will try and talk about what i was thinking when i considered this and ask you some questions ;-) Firstly a clarification I think its a good idea to move to receiver address outside of the nullifier. I put it there to prevent withdrawal malleability where the transaction broadcaster was able to change the recipient of the coin. This is important for transaction abstraction. However Its better done by passing a public parameter to the zksnark which I think is not mailable tho i am less confident about this. Doing internal transaction is difficult for two reasons
But how does this idea improve the anonymity properties? How is this different than withdrawing and in the next transaction depositing again? In fact if we remove the receiver from the nullifier we could abstract we could make a contract that would do this automatically. I think that internal transactions make the most sense when you can merge transactions together. |
According to increase of public transactions over time people aren't using zcash for what makes it worth using. Maybe because they allow public transfers and all of the wallets use public transfers, people who don't know better think it's private when it's not... If you don't allow your users to do dumb things, then they won't make mistakes.
No need, once the nullifier has been used that coin cannot be spent again. This is like a ring signature unique tag in Monero - where to prevent double spends you need to keep the tag of each coin (in this case the nullifier). This is implemented at: Line 41 in dd37259
The merkle tree remains append-only, and any Withdraw can choose any merkle root as long as it can prove the path.
I think a dictionary of all used nullifiers works well for now.
As @AntoineRondelet posted, the Transfer logic is the same as a Withdraw then a Deposit, however it happens in one step.
In the case of withdrawing then depositing again:
Yup, using a one-time-key for the nullifier, and proof of ownership of the address used in the nullifier via
|
You don't need to bind the input by signature, You can use a public variable in the zksnark to define where it should go. I am still unsure if this adds anything to the privacy set. Because you leave the tree and then directly rejoin it. So to an observer its clear that this is just round X of the mixing. But this is the same as depositing and withdrawing again. Oh is your point that to this is manually is quite difficult you have withdraw and redeposit and you cant withdraw multiple times to the same address AND you have to get gas to pay for all these transactions which is non trivial. So we should make it as easy as possible and allow this remix option so that people cannot mess it up in these ways? In that case i would argue that they still need to get gas to pay for the remix transaction. And that if we want to have a decently sized anonymity set we would need to never have public transactions and just keep everything private as long as possible. I mean providing internal private transactions that are cheap and easy. With variable amounts possible. |
It would be good to be able to perform an anonymous transfer between two recipients without the ether leaving the contract. As per discussion on AntoineRondelet/snark-mixer#2
This can be achieved by introducing a
WithdrawThenDeposit
function which does theWithdraw
thenDeposit
logic without the ether leaving the contract. e.g. spend 1 coin, then create another coin with a new owner, with the same value.However, there are problems: the
address
that ether is sent to is specified as part of the nullifier, in addition to thesalt
. If the long-term address of the coin owners is included as part of the nullifier then any coin they own will be revealed, this will link their account to the on-chain actions even if the transactions are submitted by a third party.One way to get around this is to construct the nullifier using
ecrecover
, the person submits the(v,r,s)
components of the ECDSA signature of all the functions parameters, then the recovered address is combined with thesalt
to create thenullifier
.Source code refs:
miximus/contracts/Verifier.sol
Line 111 in 7ef365f
miximus/contracts/Miximus.sol
Line 32 in 7ef365f
So, the contract functions can be expanded as the recipient no longer needs to be specified in the
nullifier
- and we can now rely on a signature of the one-time-key for the nullifier to prove ownership of the coin.msg.sender
)However, this raises other questions - how do you find out which coins you have if they haven't been shared with you? One solution to that is to store an encrypted blob along with every
Deposit
orTransfer
which, if you scan all the encrypted blobs using your long-term-key you'll find out which coins you own.The text was updated successfully, but these errors were encountered: