Recycling public keys for Bitcoin deposits

Has anyone done multiple deposits for Bitcoin, can anyone confirm if each deposit is to the same or different public keys? Ledger’s desktop wallet generates a new public key every time users make a deposit to increase privacy, for users receiving Bitcoin from third parties who don’t want to expose their total Bitcoin balance this is quite handy. Can anyone confirm if this is the case for Nash? If not is there a plan to implement something similar in the future?

I can confirm that Nash uses the same address for each deposit and does not create new ones like ledger. Also, I was wondering why Nash does not use Native Segwit addresses for cheaper BTC transaction fees?

2 Likes

Thanks for confirming, would be great to hear from the team as to why and what the plan is moving forward. I assume it has something to do with opening and closing state-channels, staking rewards are deposited to the state-channel and state-channel creation is probably tied to a specific public key so Nash may be constrained in that sense.

1 Like

I was wondering the same.

Nash is a regulated exchange. So nash is only allowed to communicate with KYC’d public keys (if trading volume > 1000€/$). If they deposit your BTC to a different public key this one need to be KYC’d as well.

That is also the reason why you only can interact with the matching engine (building the state channel) from your personal account. Otherwise nash won’t be compliant as far as I know.

2 Likes

Seems logical.

Not sure that makes sense, Nash can easily attribute multiple public keys across multiple blockchains to a single KYC’d account, if a user then deposits funds to any of those keys and then creates a channel they can use the same KYC info. As the user has control over the private keys there’s nothing Nash can do about deposits + withdrawals. The only point of control is state-channel creation + matching engine use, presumably through a process of whitelisting public keys associated with an account. So the question here is what constraints are there for whitelisting a public key?

I got the question in the first instance wrong. Don’t know why, but I was kinda locked in the thought of interacting with the matching engine.

Well, beside my reply above it should be possible to have more than one public key to interact with (deposit/withdraw). I think nash has decided against the availability of multiple public keys due to user friendliness. It will add another level of complexity to the system.

And the benefit you have described in relation to privacy will still be lost when the new public key is connected to KYC information.

You mention for deposits, than what @Symiaq said is correct, but I think you meant for transfers to personal wallet. We don’t want to refer to those as deposit here for terminology because this is just a user wallet and has nothing to do with trading.

For transfer from external to personal we currently only present one address, we will look into supporting multiple receiving addresses in the future. Is just another complexity that has lower prio right now.

13 Likes

Thanks for clarifying. :+1: :slightly_smiling_face: :nash_token: :nash_n: :nash: