The GreenAddress has two-factor authentification

[Perlover]

How with two-factor of third party it can be decentralized?
It's centralized wallet for Android!

[Perlover]

And the GreenAddress at Android doesn't allow to create wallet without setting up of two factor authentification. So there i should enter or my email, or create account with security seed for Google Authentificator or to add phone number.
And after this the GreenAddress has all green points included Decentralized!

S**t application...

[harding]

@Perlover Thanks for your pull request. I think the text that appears when you hover over each of the scores explains that score well. For example, here's what it says about being decentralized:

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

For comparison, here's the text from an app (BlockChain.Info) scored as centralized:

This wallet relies on a centralized service by default. This means a third party must be trusted to not hide or simulate payments.

As you can see, we're using centralized and decentralized to describe whether or not the balance shown by the app can be easily manipulated by a service provider. This is important: if they can simulate payments, they can trick you into giving them something for fake bitcoins. If they can hide payments, they can possibly steal your bitcoins by tricking your software into paying very large transaction fees.

I hope that makes the score more clear. Since Green Address seems to have the correct score, I think we're probably going to close this issue. Would you like to close it yourself? Thanks again for the pull.

[gurnec]

All listed versions of the GreenAddress wallet software use an Electrum server (randomly chosen from a prepopulated list) to help verify that about-to-be-signed-and-sent transactions are what you expect. This is why the mobile version has the same checkpassdecentralizeservers as Electrum.

However, AFAICT all of them use a centralized GreenAddress service to learn about received transactions and about the confirmation state of sent transactions, and could still theoretically lie about these (until such time that you try to spend them, that is).

I'm not sure which is more appropriate here, checkpassdecentralizeservers or checkfaildecentralizecentralized, although I'm leaning towards the former latter (edited: I got them backwards...). Whichever the case, I think that all three of the GreenAddress apps should be the same (currently the web and desktop apps differ from the mobile app).

[harding]

@greenaddress care to comment on @gurnec's note above?

Given the text we use, I agree with @gurnec's (edited) statement: wallets with checkPassDecentralizedServers should be using SPV for all confirmed transactions. That means before the wallet shows a UTXO as confirmed, it should download the containing transaction's merkle block and then calculate the confirmation score using block headers that have been locally validated as having the correct difficulty and no detectable problems.

@gurnec I think the reason the web and "desktop" apps differ is because we assume GA.it can change their code at any time on the web version to centralize the payment verification.

[gurnec]

I think the reason the web and "desktop" apps differ is because we assume GA.it can change their code at any time on the web version to centralize the payment verification.

I thought that might be the case, although I don't agree with the reasoning. I think being listed as checkFailTransparencyRemote is sufficient, and they shouldn't have to "pay the price" (as it were) for being a remote app more than once. Of course, this is moot if it turns out they should be checkFailDecentralizeCentralized for other reasons.

[greenaddress]

@harding and @gurnec I agree we should move the checks when the app receives transactions as opposed to when you spend, this should also make for a smoother/faster user experience when spending.

I think the reason the desktop app gets the same rating as web is because the chrome store allows to update apps silently and doesn't seem to allow developers to sign apps like on Android. I may be wrong.

To this extend we are writing a fully native app that shall not have auto update (but it shall have update notifications)

[greenaddress]

@Perlover I don't believe you need to use scurrile language to get your point across.

[saivann]

I think the reason the web and "desktop" apps differ is because we assume GA.it can change their code at any time on the web version to centralize the payment verification.

No the reason was actually that most people likely aren't using the browser extension and use the web version instead, which can't provide this feature only with javascript (AFAIK).

[Perlover]

Sorry for abusive language
But i really even could not test this application (GreenAddress @ Android) because i could not create wallet because this application wants from me to send to them my phone (SMS auth) or send there email or create account for Google Authentithication. If you don't do it - you cannot create wallet. Nice way to collect bitcoin data about me from application.

So i don't think that this application should have "Decentralized" status.

[greenaddress]

create account for Google Authentithication

Google Authenticator does not require creating any account. It works offline and is anonymous.

[harding]

@saivann Oh, that's a XSS thing isn't it? I saw the electrum JS code in the GA.it repo, but it didn't occur to me that it couldn't be run on the web version. Anyway, the lack of Electrum server support in the web version means the different scores make sense. Thanks!

[Perlover]

 Google Authenticator does not require creating any account. It works offline and is anonymous.

I don't understand
If my phone has Google Authentificator and in this phone i installed GreenAddress - where security?
GA keeps security key, and in this phone will be GreenAddress which will keep key security too inside?
As rule GA auth used with pair with remote service where second key to be keeped.

[greenaddress]

As you know you should use a separate device for your second factor
authentication, I believed your concern though was in tracking users so
which is it? I'm glad you are using a more appropriate language now, thanks
for that.
On 6 Oct 2014 10:36, "Perlover" notifications@github.com wrote:

Google Authenticator does not require creating any account. It works
offline and is anonymous.
I don't understand
If my phone has Google Authentificator and in this phone i installed
GreenAddress - where security?
GA keeps security key, and in this phone will be GreenAddress which will
keep key security too inside?
As rule GA auth used with pair with remote service where second key to be
keeped.

—
Reply to this email directly or view it on GitHub
bitcoin#601 (comment).

[Perlover]

Ok, i did some experiments.

1. I installed your application
2. I did offline mode ("fly mode") for my phone
3. I clicked "Create new wallet", i saw after there 24 words (as i understand is it seed?), i checked option "I confirm that ...", after i clicked "Continue" and ... i see page "Don't compromise on security ... Please wait, logging in ...". And it's finish!

If i turn on "online mode" i see in second stage "Set up two factor authentication" where i see second method as "GA"

I do not believe you that GA works without your servers...

[greenaddress]

GA is multisig with the service, it does not work offline no.

Google auth on a separate offline device works well.
On 6 Oct 2014 10:48, "Perlover" notifications@github.com wrote:

Ok, i did some experiments.

1. I installed your application
2. I did offline mode ("fly mode") for my phone
3. I clicked "Create new wallet", i saw after there 24 words (as i
   understand is it seed?), i checked option "I confirm that ...", after i
   clicked "Continue" and ... i see page "Don't compromise on security ...
   Please wait, logging in ...".

If i turn on "online mode" i see in second stage "Set up two factor
authentication" where i see second method as "GA"

I do not believe you that GA works without your servers...

—
Reply to this email directly or view it on GitHub
bitcoin#601 (comment).

[Perlover]

I didn't understand your last message.

Google Auth - it's only generator of temporaly codes based on time from time and secret 'seed'. Standard model is when server keeps secret code and same code is kept in phone inside GA. As i understood from your previous messages you claim that your application keeps secret code inside in phone and is not needed for your servers and works in offline. If it's true why i cannot use a creation of wallet in offline mode? Please describe your scheme for Google Authentication in your application. Your wrote above as "...It works offline and is anonymous..."

What means "GA is multisig with the service, it does not work offline no" and "Google auth on a separate offline device works well."???

[greenaddress]

I should have said GreenAddress not GA, there's an acronym collision ;)

GreenAddress is multisig and does not work offline. The device on which you
run Google Auth can be offline and there is no personal information with
Google Auth (as opposed to email or SMS, your first complaint).

If you need support I believe our help desk email is more appropriate:
info@greenaddress.it

[Perlover]

The device on which you run Google Auth can be offline and there is no personal information with Google Auth (as opposed to email or SMS, your first complaint).

I know about Google Authenticator. Thanks for info.

I called the GA as Google Authenticator, not Green Address. So your words confirm that your wallet centralized and it cannot work without your sites/servers. My pull request was about that the Green Address is not decentilized, it's centrilized software of bitcoin.

[Perlover]

Maybe I understand the term differently "Decentrilized", unlike how it is understood by the bitcoin.org. But i think this software should be marked as centrilized, because i cannot use it without servers of the Green Address. And my security will be bad if i will use this wallet. I think it more non-secure (user data can be leaked - emails, phones from GreenAddress servers) wallet from all Android's application but only this application has all green points. I don't understand it.

[greenaddress]

It can't be fully decentralised (see multisig and shared control) but the
app verifies with the electrum network (random server) that the server is
telling the truth when spending.

Other than that, we are moving the checks earlier on as suggested in a
previous comment as it is a good idea (we already had that planned as a
performance improvement but it's better for security too)

[saivann]

Actually to my understanding, this issue is about the decentralization scores being confusing, and isn't specific to @greenaddress . It may be indeed a bit too broad to just display "Centralized/Decentralized" to say "payment validation is centralized/decentralized". Maybe "Decentralized/Centralized validation" would be better? (Nothing longer as much as possible, otherwise it won't work with translations).

@greenaddress Can you comment there as soon as the checks are moved? Given that it's being fixed soon and the current state is "semi-trustless", maybe we can avoid downgrading the score only for a very short period of time.

@Perlover The additional security from 2FA probably isn't much when used on the same device (which people shouldn't do), however mobile phones are generally more secure than PCs due to app isolation and would still get a good environment score without 2FA.

@harding Yes, unless @greenaddress says otherwise, no "web wallet" (as in no extension or mobile app) was able to provide decentralized payment validation (either SPV or Electrum random list) only by using javascript.

[schildbach]

If I were to come up with a scope of "decentralized", I'd say the core usecases of a wallet should not depend on central points and still be safe. As a minimum, that is creating the wallet, authenticating (if necessary), as well as sending and receiving coins.

I wouldn't restrict the definition on validation, because what good is validated coins if you cannot spend them any more?

[saivann]

@schildbach But the decentralization score has always been about payment validation, while the "control" score (the first one) is about creating the wallet, sending and receiving coins without relying on a third party; https://github.com/bitcoin/bitcoin.org#score

[harding]

@saivann re: naming---Bitcoin Core says "Full Node". Maybe we can can use corresponding names for "Decentralized" and "Centralized":

• "Simplified Payment Verification" (or "Simplified Verification")
• "Centralized Verification"

It might even be nice to mention SPV in the hover text for users who understand that term and what security guarantees it currently offers, as the current text seems to indicate that it's the random servers that matter most. (In my opinion, most of the security advantage comes from the SPV. Using random servers enhances that security a bit, but a service provider with enough resources to forge honest-looking block headers could probably afford to DOS any servers in a small random list that they didn't control, ensuring that you use one of the servers they do control.)

Edit: if we have space, instead of "Centralized Verification", use "Third-Party Verification".

More Edit: maybe less technical terms could be "Full Validation", "Partial Validation", and "Third-Party Validation"

[schildbach]

@saivann Hmm, I read "How secure and « zero trust » is payment processing?". My understanding of payment processing is also sending, not only receiving and not only validation.

Control is about who has the private keys. I think this is orthogonal.

[saivann]

@schildbach Sure, agreed on "sending and receiving", but I think "creating the wallet" is basically about who controls the private keys.

[saivann]

@harding I like what you suggests! Although I would have a preference for "Decentralized Verification", so we could use it for Electrum too, and not translate "Simplified Payment Verification", instead only use abbreviation "SPV" in the description.

[saivann]

@harding Nevermind, I like Simplified payment verification (and perhaps Decentralized verification for Electrum), I only wonder if it will be too long for some translations, but there's good chances it might work.

[gurnec]

I just wanted to point out that using an Electrum server does not necessarily imply SPV... I believe GreenAddress for example just asks an Electrum server for a transaction based on its txid, and takes it for granted that the transaction it receives is authentic.

[schildbach]

@saivann Ok I agree there would be some overlap so I'm fine if the "centralized" definition doesn't include creation of the wallet.

[saivann]

I just opened #608 about fixing the confusing titles.

Back on the actual changes in the pull request, @gurnec has raised useful points, in my views;

On "@greenaddress possibly is not doing SPV", I tend to think it's fine as long as random Electrum servers are used only to block mismatching data from GreenAddress servers (please let me know if you think I'm wrong).

On "@greenaddress doesn't use Electrum servers when receiving payments", I think this either needs to be fixed or the score should be downgraded, otherwise what is currently displayed on bitcoin.org isn't accurate. (@greenaddress, any idea of when the feature will be implemented, can you notify us here?)

[gurnec]

@saivann I have two comments on the PR, and one minor nitpick.

Re Electrum: even though it obviously does use the Electrum servers, it also does SPV which makes some attacks, e.g. the insertion of non-existent fake confirmed transactions, much more difficult. I think it should have a checkPassValidationSPV score.

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.

Re the (very) minor nitpick: the SPV text uses "very little trust" in its description, and the ValidationServers uses "little trust" -- I have a very slight preference to weaken the latter, perhaps to something like "less trust".

Everything else looks great to me. Any thoughts on the above?

[saivann]

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.

The reason why greenaddress doesn't get a passing score on desktop is in my previous comment: bitcoin#601 (comment) . All scores represent the "default" (what the vast majority of users will end up using).

To be fair, if greenaddress was getting a good validation score, all hybrid/multisig wallets providing browser extensions (including greenaddress) would also deserve a good transparency score. But this would poorly reflect the reality given that a fairly good chunk of users don't use Chrome or FF, or won't take the extra step of installing the extension (or even understand that it has security benefits).

[gurnec]

@saivann Thanks for taking the time to explain.

I somewhat disagree with some of your reasoning, but not your conclusion. Even if GreenAddress had checkPassValidationServers, I don't think it follows that it and other hybrid wallets w/browser extensions also deserve a good transparency score -- they are still unsigned and auto-updating (at least for Chrome, not sure about FF), making them more similar to web apps than to desktop apps. Regardless, I'm convinced that checkFailTransparencyRemote is the more conservative option. Thanks.

[saivann]

they are still unsigned and auto-updating (at least for Chrome, not sure about FF)

That's interesting, I am no expert on that, but are you sure?

When you package an extension, the extension is assigned a unique key pair.
The extension's ID is based on a hash of the public key. The private key is used
to sign each version of the extension and must be secured from public access.

https://developer.chrome.com/extensions/packaging

[gurnec]

I'm definitely not sure, but I think the page you pointed to is for developers who choose to host their extensions on their own web servers, which is no longer supported in recent versions of Chrome. To further confuse things, Chrome distinguishes between "extensions", "packaged apps" (where the entire app is installed locally), "chrome apps" (which seem to replace packaged apps), and "hosted apps" (which look like chrome apps, but can have some content hosted online).

I was basing my statement from a lack of signing instructions on the how-to-publish page for chrome apps, and under the assumption that apps are only signed by Google these days, but I certainly could be wrong.

[saivann]

@gurnec Thanks! I will need to read more on that. I must admit I probably made some premature assumptions.

[harding]

Closing for multiple reasons:

1. The original intent of this PR was to remove the decentralized score from GreenAddress because the PR author believed they required two-factor authentication for spending. But 2FA isn't required (you can use your backup instead, once the time lock expires).
2. The discussion expanded to other aspects of decentralization. Some of those aspects have been addressed (e.g. in PR #608).
3. There has been no discussion on this issue for more than six months.

If, after all this time, anyone still has a policy recommendation based on this discussion, please open a new issue or pull request.

[gurnec]

I think there's still some question over whether the GreenAddress mobile app should keep its score of
checkPassDecentralizeServers or should be changed to checkFailDecentralizeCentralized. I'm unclear if anything has changed on the @greenaddress side since Saivann's comment above.

Should a separate issue be opened for this?

[saivann]

@gurnec Right. I think that @greenaddress response has been the longer but better option of going fully SPV with their latest app GreenBits.