search

RavenProject / Ravencoin

Ravencoin Core integration/staging tree
https://www.ravencoin.org
MIT License
1.08k stars 675 forks source link

Default recommended confirmations is too low #619

Open sphericale opened 5 years ago

sphericale commented 5 years ago

Currently the Qt wallet shows a transaction as 'Confirmed' after 6 confirmations (as Bitcoin).

But 6 confs in RVN currently have nowhere near the same level of security as BTC.

By the metrics of https://howmanyconfs.com/ we need ~4000 confirmations to match the security of 6 in Bitcoin.

That may be slight overkill but it would be better to at least match the 1 hour timespan of BTC (i.e. 60 confs).

ravenlandpush commented 5 years ago

Most exchanges use somewhere between 30 and 120, so it stands to reason that this might be a good idea.

Best wishes, push

lsji07 commented 5 years ago

That website is not a good indicator of security by simply comparing btc's hash and confirmation time and then showing the "lower coins" as a simple multiplier lower than bitcoin. To much of a simplification imho. Proper discussion on that is a separate issue.

I agree though that the change for 6 block to circa 60 confirms does make sense.

This would make the wallets as secure as per the recommendations to exchanges.

59 blocks are coded as the max reorg +1 block for safety margin for exchanges. Same 60 block confirmation limit to the wallet makes sense as a best practice as initial wallet configuration.

We could make the wallet confirmations a user decision between the range of 6 confirms and 60 confirms.

Hard payoff between security and speed that imho should be the node runners decision but initial config should be using the best practice security with the option to configure for faster (albeit "less secure") confirmations.

Little red sirens and stuff should go off in the wallet if people choose to make it less secure. Red skins for angry dangerous speed mode and green for secure?

ravenlandpush commented 5 years ago

Well, the wallet supports max_confirmations for some of the RPC functions already. It would be nice to see a universal way for RVN and Assets to set the max_confirms when retrieving an address balance I guess. ( I think this exists in listreceived by address as an option but double check me on that)

It is a nice idea to have a color code for transactions which are under a confirm the user or standard threshold in raven-qt.

I'd say anything between 30 and 60 confirms is OK. Also that website is a pretty good indicator for hash comparison, in the sense of how difficult it would be compared to ravencoin to cause a block rearrangement. Whilst that said, it is not possible to do block reorg on ravencoin so after, I think it is 60 or 120 blocks or so. So I agree with what your saying that it is 'not a simple comparison', and likely a slightly unfair one perhaps.

TLDR My understanding is if the limit to block reorg is 60 or 120 blocks, then, this 4000 confirms is not so much the case at all to provide complete protection, just 120 confirms ought to do it if your paranoid. Not the 4000. It's nice idea to have color coding for transactions amber for pending still, red for failed, and green for > confirm_threshold.

Best wishes, Adam