Skip to content
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

Showcase the Bridge behaviour under different scenarios #2633

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

apancorb
Copy link
Contributor

Description

Adds unit tests to analyze a new pegout minimum. This PR is just focused on analisis purposes.

Motivation and Context

How Has This Been Tested?

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • Tests for the changes have been added (for bug fixes / features)
  • Requires Activation Code (Hard Fork)
  • Other information:

@apancorb apancorb self-assigned this Jul 23, 2024
Comment on lines 968 to 975
Coin minSpendableUTXOValue = Coin.SATOSHI;
tx.clearOutputs();
tx.addOutput(minSpendableUTXOValue, fed.getP2SHScript());
while (tx.getOutput(0).isDust()) {
minSpendableUTXOValue = minSpendableUTXOValue.add(Coin.SATOSHI);
tx.clearOutputs();
tx.addOutput(minSpendableUTXOValue, fed.getP2SHScript());
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting enough this value turns out to be 2700 SATS. Which is exactly the lowest value UTXO I was able to find in the Bridge address. Meaning given the current wallet implementation, this is the lowest value that the Bridge will not consider it as dust and will proceed to spend it if so desired by the selector UTXO algorithm.

Here is the tx: https://mempool.space/tx/ab94ce7abfe178025b593ce0f0c7468a984087ae7977800b62cf47b4284d00dd

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is the lowest change output the Bridge will create, right? If a UTXO is used that generates a smaller change, it will remove sats from the user output until it completes 2,700 sats as the change. So we could say that the max it will drain from a user output is 2,700 sats in the case that the change was 0.

And this does not depend on the feePerKb value set in the Bridge, is that right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is the lowest change output the Bridge will create, right? If a UTXO is used that generates a smaller change, it will remove sats from the user output until it completes 2,700 sats as the change. So we could say that the max it will drain from a user output is 2,700 sats in the case that the change was 0.

That is right.

And this does not depend on the feePerKb value set in the Bridge, is that right?

That is right, reason being because it always uses a hardcoded feePerKb value of 15,000 SATS

);

// build batch peg-out transaction
ReleaseTransactionBuilder.BuildResult result = releaseTransactionBuilder.buildBatchedPegouts(entries);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the current feePerKb of 24,000 SATS and my initial proposed minPegoutValue of 28,500 SATS, this batch peg-out transaction will not be built with a Wallet.CouldNotAdjustDownwards exception. Meaning the user output could not be adjusted downwards to pay the tx fees. This makes sense since this scenario I believe is the worst case scenario, since we have N P2SH inputs with the min possible value to be non-dust and only one user output that is going to take all the load. So I think if we can find two values that pass this scenario, then we should be good for any other scenario. Wdyt @marcos-iov ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nevermind, this test scenario will never pass no matter what min peg-out value you choose. Maybe we can just split the min peg-out value by using 10 inputs. Like if min peg-out value is 20 then have 10 inputs of 2 each. Wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I followed the logic here. There is only one pegout request for the min pegout value, right? And how many UTXOs available and for what value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes only one pegout request. And there will be as many UTXOs available to cover the request. Each UTXO will have a value of 2,700 SATS. The problem with this test is that is impossible to pass since it is too much fees that has to be taken from the user. I have written a similar one but that takes the pegout request value and divides it by 10 equal UTXOs.

@apancorb apancorb changed the title Write unit tests to showcase the Bridge behaviour under different scenarios Showcase the Bridge behaviour under different scenarios Jul 29, 2024
@apancorb apancorb marked this pull request as ready for review July 30, 2024 09:40
@apancorb apancorb requested a review from a team as a code owner July 30, 2024 09:40
Copy link
Contributor

@marcos-iov marcos-iov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also consider the size of the transaction after signing?

mock(BridgeStorageProvider.class)
);
// build release transaction builder for current fed
when(activations.isActive(ConsensusRule.RSKIP201)).thenReturn(true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just in case, let's use ActivationConfigForTest class. And get the all object, that includes all RSKIPs active

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would it look in code? If I understand correctly, I should still mock isActive(ConsensusRule.RSKIP201) right?

Comment on lines 968 to 975
Coin minSpendableUTXOValue = Coin.SATOSHI;
tx.clearOutputs();
tx.addOutput(minSpendableUTXOValue, fed.getP2SHScript());
while (tx.getOutput(0).isDust()) {
minSpendableUTXOValue = minSpendableUTXOValue.add(Coin.SATOSHI);
tx.clearOutputs();
tx.addOutput(minSpendableUTXOValue, fed.getP2SHScript());
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is the lowest change output the Bridge will create, right? If a UTXO is used that generates a smaller change, it will remove sats from the user output until it completes 2,700 sats as the change. So we could say that the max it will drain from a user output is 2,700 sats in the case that the change was 0.

And this does not depend on the feePerKb value set in the Bridge, is that right?

);

// build batch peg-out transaction
ReleaseTransactionBuilder.BuildResult result = releaseTransactionBuilder.buildBatchedPegouts(entries);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I followed the logic here. There is only one pegout request for the min pegout value, right? And how many UTXOs available and for what value?

@apancorb apancorb force-pushed the min-pegout-value branch 2 times, most recently from 09c7677 to 0d9b51e Compare August 15, 2024 11:25
Copy link
Contributor

@marcos-iov marcos-iov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall. I think we just need to test for different fee per kb values

Copy link

sonarcloud bot commented Aug 21, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants