-
Notifications
You must be signed in to change notification settings - Fork 267
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
base: master
Are you sure you want to change the base?
Conversation
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()); | ||
} |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
rskj-core/src/test/java/co/rsk/peg/ReleaseTransactionBuilderTest.java
Outdated
Show resolved
Hide resolved
); | ||
|
||
// build batch peg-out transaction | ||
ReleaseTransactionBuilder.BuildResult result = releaseTransactionBuilder.buildBatchedPegouts(entries); |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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?
rskj-core/src/test/java/co/rsk/peg/ReleaseTransactionBuilderTest.java
Outdated
Show resolved
Hide resolved
mock(BridgeStorageProvider.class) | ||
); | ||
// build release transaction builder for current fed | ||
when(activations.isActive(ConsensusRule.RSKIP201)).thenReturn(true); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
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()); | ||
} |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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?
rskj-core/src/test/java/co/rsk/peg/ReleaseTransactionBuilderTest.java
Outdated
Show resolved
Hide resolved
09c7677
to
0d9b51e
Compare
0d9b51e
to
e47fa7f
Compare
There was a problem hiding this 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
Quality Gate passedIssues Measures |
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
Checklist: