Given recent 51% attacks, it has become apparent that exchanges are not waiting an appropriate confirmation time before approving deposits. My speculation, is that “lazy” exchanges or users may simply query the reference wallet API to determine when a transaction is considered confirmed, and today that period is fixed to 10 blocks. This period is very short and any exchange that uses only a 10 block period is quite vulnerable to 51% attacks.
I would like to propose changing the default wallet confirmation time to a dynamic confirmation time proportional to the value of a transaction (keeping 10 as the minimum confirmation time). This way, the default behavior will be “slow but secure”. Advanced users may still choose to override this, and use a “faster” confirmation time depending on their need. This will help any non-technical (or “lazy”) user/exchange avoid using unwise confirmation times; thus helping reduce the viability of 51% attacks.
For example: when receiving a small transaction (say 60 Grin), the wallet will still display a confirmation time of only 10 blocks. For a large transaction (say 6,000 Grin), the wallet will display an appropriately larger confirmation time.
This is simply a wallet UX proposal. I am not suggesting any network/protocol change.
I am willing take the time to formalize an RFC and even take on the appropriate development effort (if applicable). Before starting down that road, I would first like to solicit some feedback from the community on the following questions:
Do people agree with the idea of the reference wallet defaulting to dynamic confirmation times?
Is this a waste of time? Maybe its just better to spend effort educating users & exchanges about appropriate confirmation times? Maybe my assumption is wrong, and exchanges don’t even use the reference wallet? Even if these are the case, I still think its a good idea to adjust the default wallet behavior, but I would like to know what the community thinks.
What is an appropriate calculation for confirmation time?
A naive approach would say wait amt/60 blocks (6000 Grin would wait 100 blocks). A 51% attacker may still profit from performing a 100 block reorg (attacker gets 100 blocks reward + double spend their 6000 Grin TX to you + maybe other double spends in the same 100 block period). I don’t think there is an answer for “how long should confirmation take” that applies to all users in all use cases, so it may be a lost cause trying to answer this question perfectly. In that case, what do you think is a “reasonable default” that would be “more secure for the average user”? Maybe the wallet communicate the risk to the user better to the user, so the user can make an informed decision on their own?
How should this be designed?
My original idea is this:
- Default wallet API provides the default dynamic confirmation time.
- Users may override this in their
grin-wallet.tomlto be some other fixed time (or perhaps adjust the calculation)
- Default “send” API will not allow to spend unconfirmed UTXOs, but this can be overridden with a
--forceoption, or something like that.
Any suggestions or constructive criticism is greatly appreciated. Feel free to tell me if you think this idea is a waste of time and should be abandoned