-
Notifications
You must be signed in to change notification settings - Fork 173
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
automatically splitting stakes into multiple UTXOs based on high efficiency sizes #1240
Comments
I had code on this for some time: 75c0605 |
Auto stake split has two functions, the one stated and it also ensures in a fork or low network weight situation that it's much harder for the main chain to 'run dry' of available UTXOs. |
I agree with the comment about smaller UTXO's being beneficial in a low diff situation because of the cooldown effect network wide in a situation like that, which all things being equal will tend to drag the difficulty down even more due to UTXOs being caught on cooldown... Ensuring a varying degree of UTXO sizes is hard to do, and large UTXO's become encumbered by cooldown. Absent cooldown the probability of staking is a linear function of UTXO value, but if an attacker has fixed assets, then Balance = (number of UTXOs) * (UTXO value) is constant, and therefore, ignoring cooldown, total staking probability for the attacker is constant. The cooldown effect only serves to decrease the attackers net ability to stake if staking assets (total balance) is held constant and UTXO count is decreased... See my efficiency equation which includes cooldown effects. The original base form of the equation is ETTS = ((Cooldown time) / (number of UTXOs)) * (Ideal ETTS without cooldown). Essentially the (Cooldown time)/(number of UTXOs) is the "diluted" time penalty for cooldown given the number of UTXO's in someone's wallet. The frequency of staking is the inverse of ETTS, Ideal ETTS (ignoring cooldown) is a function only of wallet balance... |
Im just observing that an attacker might not be interested in staking efficiency and will sacrifice that willingly to create a side chain that destroys higher coin weight than the main chain by having suitably large UTXOs, and by doing so gains higher chain trust? Im not an expert in that area, just raising for consideration. |
@tomasbrod should comment on this. Given that the UTXOs that are held by smaller balance holders are limited to the size of their wallet, while large balance holders are likely to have some very large UTXOs already, in general the UTXO stake splitter will act to reduce the size of UTXOs in large balance holders more aggressively, thereby reducing the inequity between large and small balance holders UTXOs. |
UTXO size does not affect chance to stake, or time to stake of WALLETs with constant balance. Attacker with one large output does have higher chance to stake with that utxo, but only has one of them. So there is no danger. However wallet with one large utxo has lower average stake frequency than same balance wallet with many transaction outputs. This is caused by a required cooldown period (aka maturity) of each output that we haven't figured out how to remove, so we are working around with this splitting. |
It's not so much where a wallet has 1 large UTXO, but perhaps 10 UTXOs several orders of magnitude higher than the 'efficient' staking amount. How will that effect the wallet with large UTXOs potential to stake consecutive blocks? |
This is in Camilla. Closing. |
@jamescowens and I were talking about that.
"The idea is that the staking UTXO would be evaluated by the code against the formula I put out on steem yesterday, and if the UTXO is larger than a network wide efficiency setting would indicate is optimal, the stake UTXO output would automatically be split into 2 or more pieces to reduce the UTXO size below the value required for the given efficiency. Essentially, over time, this would achieve automatic UTXO optimization for staking. ... Normally UTXOs from stakes go back to the same address from whence they came. What @quezacoatl is getting at is some people might have significant UTXO value stuck in change addresses, and those will stake. Under normal circumstances, the stake output will go back to the change address if it came from a change address, which might be less desirable than a non-change address..."
must have: opt-in flag in .conf
nice to have: setting the minimum value of UTXO size
"So... conf file entries (or command line arguments) of EnableStakeUTXOOptimization=0 or 1
MinimumStakeUTXOValueForSplit=x and if someone puts less than 800, code uses 800.
We could probably also create a checkbox in the UI to set EnableStakeUTXOOptimization"
800 is the rounded value that gives a stake efficiency of 95% at a difficulty of 1.0.
The text was updated successfully, but these errors were encountered: