Revert "Reduce the RangeProof by 5 bits"

[lontivero]

This reverts commit 751483d (PR #7646). Reverts the range proof limitation

The limit is relaxed back from 1343750000000 to 4300000000000. Previously this value was restricted because
we suspected the increasing delay time observed during credential reissuance requests was due to high cpu usage, however that was not proven but assumed to be true.

Note that this doesn't solve the problem but kick it down the road because now someone could ask "what if I have more than 43000 bitcoins in one single utxo?" and the only way to solve now and forever would be to increase it another 12 bits. The problem with that is that we would be imposing a big cost to everybody just in case Satoshi one day decides to consolidate all his coins in one single utxo and start mixing with Wasabi.

[turbolay]

Why this change? You are also changing ProtocolConstants.MaxAmountPerAlice in the PR so why not keep using it?

[lontivero]

Because this is a revert, i mean, the result of doing git revert <commit> . If I get the ACK then i will continue with it, otherwise not.

[turbolay]

Is there a way to effectively measure the impact of this?

[lontivero]

Yes, there is a WalketWasabi.Benchmark project somewhere. I will find it and share it.

[yahiheb]

Yes, there is a WalketWasabi.Benchmark project somewhere. I will find it and share it.

#2439

https://github.com/zkSNACKs/WasabiBenchmark

[lontivero]

It seems there is not real difference in processing time:

// * Summary *

BenchmarkDotNet=v0.13.2, OS=nixos 22.05
AMD Ryzen 7 5800H with Radeon Graphics, 1 CPU, 16 logical and 8 physical cores
.NET SDK=6.0.300
  [Host]     : .NET 6.0.5 (6.0.522.21309), X64 RyuJIT AVX2
  .NET 6.0   : .NET 6.0.5 (6.0.522.21309), X64 RyuJIT AVX2

Runtime=.NET 6.0

|  Method |        Job | Toolchain |    upperBound |     Mean |   Error |  StdDev | Rank |
|-------- |----------- |---------- |-------------- |---------:|--------:|--------:|-----:|
| Process |   .NET 6.0 |   Default | 1343750000000 | 501.0 ms | 1.21 ms | 1.07 ms |    1 |
| Process |   .NET 6.0 |   Default | 2150000000000 | 505.2 ms | 3.53 ms | 3.31 ms |    1 |
| Process |   .NET 6.0 |   Default | 4300000000000 | 512.7 ms | 1.55 ms | 1.29 ms |    2 |

code: https://github.com/zkSNACKs/WasabiBenchmark

[lontivero]

There was an extra zero in the upper bound limit so, it was wrong.

|  Method |        Job | Toolchain |    upperBound |     Mean |   Error |  StdDev | Rank |
|-------- |----------- |---------- |-------------- |---------:|--------:|--------:|-----:|
| Process |   .NET 6.0 |   Default |  134375000000 | 452.7 ms | 1.27 ms | 1.12 ms |    1 |
| Process |   .NET 6.0 |   Default | 2150000000000 | 501.6 ms | 1.75 ms | 1.46 ms |    2 |
| Process |   .NET 6.0 |   Default | 4300000000000 | 519.9 ms | 1.91 ms | 1.59 ms |    3 |

[lontivero]

Note: Even when this is a server-side change only, those who don't update will not be able to participate with more than 1343.75btc because the DependencyGraph uses the ProtocolConstants.MaxAmountPerAlice instead of using the value specified by the RoundParameters .

[lontivero]

Btw reviewers, the benchmark project is updated and you can run it and verify the numbers are correct.

[molnard]

Deployed to TestNet

[adamPetho]

Successful CJs on client side, nothing suspicious in the server side logs.

[molnard]

Next Monday we can deploy this to the master. Before that, I will merge this PR.

[molnard]

Tested.

[molnard]

Deployed to MainNet