Rename the "Decentralization" score to "Validation" score

[saivann]

Live preview: (merged)

Based on discussions #601, this pull request renames decentralization scores to avoid confusion, since this score is about payment validation, and centralization / decentralization is broader and depends on other factors.

I used a mix of the propositions that have been made and especially like this being an opportunity to use seperate titles for SPV and Electrum (thanks @harding).

I don't know if there was already enough agreements on that, so I'm leaving some time for comments.

Relevant changes are in _translations/en.yml and README.md, the rest is just reorganization noise.

[harding]

@saivann thanks! This is definitely an improvement. With the exception of the note below, this LGTM.

@gurnec mentioned in #601 that the text for SPV vs decentralized may be somewhat unclear about the relative strength of those two different methods. Here's the text with bolding added:

checkpassvalidationspvtxt: "This wallet uses SPV and the Bitcoin network. This means very little trust in third parties is required when verifying payments. [...]

and

checkpassvalidationserverstxt: "This wallet connects to a random server from a list. This means little trust in third parties is required when verifying payments. [...]

@gurnec suggested leaving the SPV text unchanged and s/little trust/less trust/ on the decentralized text. I think that would be an improvement, although maybe a bit more clear would be changing the decentralized text to s/little trust/some trust/.

[saivann]

@harding @gurnec Including your suggestions, may I suggest the following:
(branch and live preview updated)

checkpassvalidationspvp2p (P2P SPV wallets)
checkpassvalidationspvservers (Electrum with SPV)
checkpassvalidationservers (GreenAddress without SPV)

(While Electrum relies on random servers, it only has a few servers in its list compared to thousand nodes when using the P2P network, as previously outlined by @schildbach)

[gurnec]

FWIW, I prefer the description wording suggested by @harding.

[saivann]

@gurnec Are you sure you reviewed the latest commit? I actually use @harding wording, and the change I made in fact only prevents saying "connects to the Bitcoin network" for Electrum, because that isn't accurate. This change also applies the "SPV" score to Electrum as you suggested at the same time.

[gurnec]

@saivann (sorry for the wall of text, but...) I'm not sure if I prefer your 3-tier checkpass proposal or your original 2-tier one. Even though the 3-tier proposal has the potential to be more technically accurate, I'm not sure it's the better choice for this page.

One issue I have with the 3-tier proposal is how to word the descriptions.

One option would be to "squeeze" a new description into the existing 2-tier proposal that's weaker than one but stronger than the other. At this point, the descriptions become so close to one another that I don't think they will convey useful differentiating information, and they might even cause more confusion than help.

Another option would be to create a more accurate technical description, however this would seem to go against the spirit of the page (which I presume is to be as accessible as possible).

I'm not saying that it's impossible (and I'll bet you could prove me wrong), only that I don't know how to do it.

Another issue I have is that I'm unclear on whether a P2P SPV solution is strictly superior to an Electrum-style model. Electrum servers can support SSL, however I'm not sure if they are required to do so, or if their SSL implementations are otherwise vulnerable to downgrade attacks. If SSL were required (though I don't think it is...), an Electrum-style model would resist a coffee-shop-wifi attack (where an evil ISP can easily fake 0-conf transactions or inhibit transactions/blocks from being seen) much better than the P2P network could.

Conveying all this information in a short description might not be possible...

[gurnec]

Are you sure you reviewed the latest commit?

@saivann I hadn't reviewed the latest commit before my most recent "wall of text"...

Unless it's shown that Electrum does require SSL, I think the current commit looks very good. If at some point Electrum does require SSL, and would therefore provide better protection against certain attacks than P2P SPV can, it might be worthwhile revisiting this.

Thanks again for your all your work!

Does anyone (including @greenaddress) have any comment on what I mentioned at the end of #601?

Re the GreenAddress desktop wallet: I believe this should be checkPassValidationServers (and the web version should remain as checkFail), but it would be good to check with @greenaddress first.

[saivann]

Unless it's shown that Electrum does require SSL, I think the current commit looks very good. If at some point Electrum does require SSL, and would therefore provide better protection against certain attacks than P2P SPV can, it might be worthwhile revisiting this.

Thanks and agreed. In any case the only part that slightly suggests P2P SPV wallets are superior is the "little trust VS very little trust" part. IIRC, it was only kept that way because previous discussions seemed to provide good arguments for it. But should there be more reasons to consider both security model mostly equal, we could maybe just use "little trust" everywhere...

Diff between P2P SPV and Electrum SPV:
Simplified validation - This wallet uses SPV and the Bitcoin network. This means very little trust...
Simplified validation - This wallet uses SPV and random servers from a list. This means little trust...

[harding]

The descriptions in the updated commit (cd49dcf) look good to me. Thanks!

[saivann]

Thanks for the feedback. In the absence of critical feedback, this pull request will be merged tomorrow, October 13th. (I will take care to update translations on Transifex too).