Blackbox fee for Cloak

Secret Contracts and Secret Apps
1

I appreciate the Cloak functionality of blackbox.cash, but I must say the the fee is with 1 sSCRT way to high for a broader usage. There should be a cheaper possibility for privacy, because this is the fundamental utility in Secret Network and would be helpful to get people adopting the privacy features of SCRT. Is there an other cheaper way to get Gas fees for a new address with only sSCRT?

2

Likewise I am somewhat disappointed in Cloak as it’s a good idea that solves a real need, but the problem goes much deeper than just their fee model.

My problems with blackbox.cash are, I’ll provide details on each below:

  1. Fees are retained upon deposit
  2. The relayer can steal your funds
  3. The operator/relayer can break/shut down, or they lose interest
  4. The admin keys can break the contract
  5. There is no .onion address
  6. There are no metrics on anonymity set size
  7. There is a real need for anonymous meta transactions

Lets look at the source code, because it’s not linked on their website:

1) Fees are retained upon deposit

Theres more of a fundamental problem here, if their calculations are wrong and because there’s no reimbursement method upon withdrawal if the gas cost of SCRT increases the originally deposited fee might not actually be enough to cover the cost of the on-chain redeem transaction without the operator losing money.

There is no incentive for them to keep the service running and not just run away with the fees if there’s a sudden influx in usage (although, as you’ll see from Point 2, they have an incentive to keep running, and it’s not a good one).

The solution here would be to take a small upfront fee for using the service or make depositing free, and then charge whatever the cost of gas is (plus some markup) to cover their fees for making the withdrawal subtracting it from the note and disbursing the remainder to the recipient. It should be up to the person withdrawing the note to agree to the gas cost & fees so they relayer can’t set an arbitrary fee and steal the money.

This is trivially solvable using just hashes without the need for a full-blown signature scheme like EcDSA. I can specify it if needed, on the condition that they will actually fix all of the other issues I’ve raised at the same time.

Of course, you also have the problem that if gas prices spike your note may not be enough to cover the cost of withdrawing a transaction, but it should be possible to anonymously ‘top-up’ a note in future rather than keeping them at an amount which is fixed at the time of deposit.

2) The relayer can steal your funds

This is not good!!!

While chain observers cannot see the withdrawal secret, you give it to the relayer in plain text along with the recipient address - but there’s no authentication so once the relayer/operator has your secret they could change the recipient address to their own and steal your funds.

See:

FOR THIS REASON YOU SHOULD NOT TRUST THE SERVICE THEY CAN STEAL YOUR FUNDS!

3) The operator/relayer can break/shut down, or they lose interest

Because the only entity who can perform the redeem operation is the ‘operator’ if it stops running then nobody else will be able to setup a service to carry on in their absence.

Restricting the operator is unnecessary, with a correctly designed protocol because it shouldn’t matter if the operator is the one set by the admin or on a competing website.

4) The admin keys can break the contract

If the admin key leaks somebody can permanently break the contract by maliciously changing the operator key to an invalid address, and then changing the admin key to an invalid address. This would make it impossible for anybody to fix the contract and return it to a workable state without a hard-fork to roll-back the entire blockchain to the non-broken state.

Thankfully if the contract is permanently broken then the funds aren’t locked-in forever as there’s an ‘exit_pool’ function which requires you pay for gas.

The admin can also arbitrarily change the fees.

IMO it’s entirely unnecessary for there to be an ‘admin’, there is no need to fix the fees at the contract level, to enable or disable it, all of this can be overcome with correct protocol design.

5) There is no .onion address

Come on guys, we’re trusting that you’re not logging IP addresses to de-anonymise transactions by associating the deposit with the withdrawal.

They don’t highlight this issue on their website.

6) There are no metrics on anonymity set size

deposit_count - withdrawl_count = anonymity_set

This is an important metric as without it it’s entirely plausible that with a lower number of users there’d be a 1:1 correlation between deposits and withdraws (e.g. if everybody deposits and then withdraws soon after, the anonymity set size will never increase beyond 1, fundamentally negating all of their anonymity claims).

This isn’t displayed anywhere on the blackbox.cash website, even though it’s being tracked. Not displaying this metric gives a false sense of security to the users.

7) There is a real need for anonymous meta transactions

But some more thought needs to go into this, it’s on my mind and various solutions are out there, and blackbox.cash is not the right solution.

So many smart contract protocols are being mindlessly adopted when there is an opportunity to overcome all of the problems we’re encountering on Ethereum and other smart-contract chains, sure the ‘permits’ approach works but why doesn’t it support more operations.

One of the major problems is the ecosystem chicken & egg problem - once a protocol gains critical mass of adoption we’re stuck with it and it’s very hard for anything else to gain traction without having layers upon layers of hacks for bad design decisions that were made at the start that don’t allow for composability, delegation etc.

I think that scrt.network is still early enough to actually tackle this elegantly, but it doesn’t seem to be a priority.

2 Likes
3

Hi! I thought I would take some time to respond to some of these. (Also our source code is linked on the website if you click “github” it will bring you to all our repos).

  1. We can change the fees at any time if the gas cost happens to increase. Being node operators we feel like we can very easily stay on top of any fee shifts, and the fee that we send to our operator has a very sizable buffer to it which should never be surpassed.
    I’d like to hear about the EcDSA method however. We want to cut ourselves out as middlemen wherever possible.

  2. Yep. It’s totally possible for us to do that, and because of that we recommend sending very small amounts (20 cents worth is all that’s needed honestly) through this tool. Since it’s designed for the purpose of seeding wallets with SCRT gas, and not sending large amounts from person to person, there is no need to have large fund amounts pass through here. Even if you trust us completely I still recommend not sending large amounts through here.

  3. Also correct. This is why we have the exit_pool() function which will allow you to withdraw all your funds in sSCRT.
    However I do like the idea of allowing multiple operators from third parties websites. If we setup that EcDSA bit you mentioned for fee setting as well there would be no need for whitelisted admins and operators.

  4. ^

  5. Excellent idea.

  6. Yep. We do track it in the contract. We’ll be adding a display for it the next time we update the website.

  7. By this do you mean something like network wide ring signatures to hide the wallet address of the user? I 100% agree. I look forward to the day something like this renders Blackbox obsolete.

1 Like
4

The fees are only applied to new deposits, this does not solve the problem. There are better methods without assumptions.

There is no need to use EcDSA when using scrt.network because the contract has private data, simply having ‘note id’ and ‘note secret’ allows the withdrawer to hash the parameters (recipient, gas fee) so the relayer cannot modify them nor can they steal the funds.

Please add a huge disclaimer to your website:

  • ‘WE CAN STEAL YOUR FUNDS, NOT USE BLACKBOX.CASH, IT IS NOT SAFE AND WE KNOW IT BECAUSE WE MADE IT THAT WAY’

Doesn’t look good does it.

There is no need for ring signatures, and if used they would reduce the privacy of scrt.network.

There are better methods for transaction relaying that solve the gas payer problem, some of them need protocol support, some don’t.

5

You were very close to having an exceedingly useful ‘black wallet’ service where gas & a small fee is subtracted from transactions.

Why fixed sized notes and not accounts with a balance? It could easily be turned into a product which doesn’t require any wallet software installed in the browser to make simple value transfers.

Even then, with a CLI program we wouldn’t even have to trust that your website doesn’t get backdoored and steal our funds.

6

Ah I misread that first point. I’ll have to look more into seeing what we can do there.

And it seemed to be the best way to build something that worked with the knowledge and resources we had at the time. With the intention of updating it as more ideas come to the table, as we’ve already been doing. If we find that an account system can work that negates the need for operators and admins then that will be our next update.

7

I will just write the spec in the meantime and post a grant request because 1) it’s entirely possible, 2) doesn’t require a fixed admin or operator (although it does need a relayer) and 3) is direly needed.

1 Like
8

Sounds good, look forward to seeing it.

9

What are the privacy implications of this?

I thought The operator of the service only received encrypted information or can they simply see what any user is doing. If there is some sort of privacy externality risk like this i think we need to highlight that to previous users.

Need some more info on this and the use of central servers in the process.

@HarryR i am Sure Trivium wants to design the best application possible seeing they already rewrote the entire thing 1 time before. Lets collaborate here and see if you and Lumi can team up to get it working. It is great you provide very constructive feedback but in the end just fixing it the best way possible is what we want, no need to battle over that imo.

2 Likes
10

One thing we can do to prevent the possibility that we could steal funds would be to allow the user to select the destination address when depositing and store it with the token amount. Seems like it may be worthwhile.

2 Likes
11

could you answer above question regarding the privacy implications?

Important to know for us as Support team and edu committee.

2 Likes
12

There’s no way for me to verify that they haven’t de-anonymized all the service users, and almost all of their privacy & security claims have been proven false.

Make of that what you will, but you have zero privacy protection from them if they decided to be malicious, and no way of knowing if they have been or any way of proving that they haven’t.

13

Which privacy and security claims have been proven false?

1 Like
15

+1

Sources for these claims proven false?

What exactly is the privacy risk being spoken of?

(Side note: the service is to send dust, not value transfer)

1 Like