Sajolida:
“If I understand correctly, the main issue here is about the *change*
(and not about the behavior itself), then this should be mentioned most
of all in the release notes. If you think that the behavior itself might
be confusing, then I guess that this should be solved upstream (in their
documentation or the software directly).”
S7r and I disagree. Simply noting the change of default base unit could
have a big impact in avoiding confusion.
“If they have to perform a specific action, then this should be
documented. If they don't have to perform a specific action, then maybe
we need to adapt the current warning about 'Do not blindly trust the
bitcoin balance'.”
Yes, they do have to perform a specific action to select the onion
Electrum server at the moment.
s7r:
The mistake that you are making is being too specific with your
documentation proposal. Please see the Tails documentation contributors
page:
https://tails.boum.org/contribute/how/documentation/ . I also
proposed specific documentation like yours here:
https://mailman.boum.org/pipermail/tails-dev/2015-March/008302.html and
found out that it belonged in the Electrum wiki instead of Tails.
The main debate is over the DoS documentation. This is a good summary by
anonym of a worst case scenario:
“Thanks to SPV, the server can spoof the wallet balance. Hence the
server operator can scam Tails users, e.g. s/he can buy stuff from a
Tails user, and then bump their balance with that exact amount so it
looks like they've received payment.”
The DoS problem is difficult to solve. The best solution would be for
Tails to sponsor its own onion Electrum server.
Please see my inline replies that follow.
> Hello Sajolida, Michael,
>
> See inline.
>
> On 11/22/2015 2:00 PM, sajolida wrote:
>> Michael English:
>>> Sajolida, please forward this message to s7r.
>
>> Done.
>
>
> Thanks!
>
>>> s7r,
>>>
>>> If you do not have any specific ideas for updating the Electrum
>>> documentation, I volunteer to take the lead. Otherwise, you can
>>> draft an updated version of the documentation and I can update
>>> where necessary. The goal is to document Electrum specifically
>>> for Tails and not duplicate the existing Electrum wiki.
>
>> Thanks for the offer.
>
>>> Most of the updates like wallet format happen automatically in
>>> the background, so they do not need to be documented. I only
>>> recommend making two additions.
>>>
>>> The most obvious change to the user when updating Electrum
>>> versions is that the default base unit changes which can be
>>> confusing. No, I do not think that we should manually change the
>>> default base unit with a config file. That decision should be
>>> made upstream. However, users should be aware that the appearance
>>> of their Bitcoin balances changes especially when sending
>>> Bitcoins.
>
>
> Right, the current page is pretty good:
> https://tails.boum.org/doc/anonymous_internet/electrum/index.en.html
>
> I will include few more additions, especially to highlight how
> important the seed is and that is also important to have it backed up
> even in case you use a persistent Tails install (since that particular
> install can break or etc.).
You should link to existing documentation if it is general knowledge
that is not specific to the Tails configuration.
>
> mBTC as default unit should of course be explained. I also want to
> include some answered questions about what an Electrum server is, what
> it can do and what it cannot do.
Documenting what an Electrum server is is completely off topic for the
Tails documentation.
>
>>> DoS refers to the SPV vulnerability of servers withholding
>>> information from their clients leading to an incorrect balance.
>>> Connecting to a trusted .onion server protects against DoS. Yes,
>>> it is not a bug, but it is a well-known limitation of SPV that is
>>> specifically relevant for Tor users. Pleas read “Bitcoin over Tor
>>> is not a good idea” http://arxiv.org/pdf/1410.6079.pdf .
>
>
> This is unrelated to electrum. It applies to Bitcoin Core (the
> software implementing bitcoin protocol - full nodes). Bitcoin core has
> a peer-ban-score, where the ban score of a peer (remote server that
> you are connected to) increases if that peers feeds you trash data or
> tries to DoS you.
>
> The attack described in that paper takes advantage of the scarce exit
> power in the Tor network (~1000 IP addresses) and speaks from the
> point of view where an attacker runs few Tor exit nodes that allow
> bitcoin exit traffic, and then uses the other exits to feed enormous
> amount of trash data to the bitcoin network, hoping the majority of
> bitcoin nodes will ban the other exits which are not under the control
> of the attacker. Then, you can only connect to a bitcoin peer via Tor
> using one of attacker's exit nodes. Hope this explains - it's just a
> summary.
>
> Electrum servers don't have such banning mechanism, they only have
> limits of requests per wallet and per address (100/10000).
The point that you are missing is that SPV wallets and Tor are
incompatible. This is just an example of traffic manipulation to display
and incorrect balance. It could could be adapted for the Electrum client
and Electrum servers obviously run Bitcoin Core.
>
> So, I think it's not worth it to confuse the users and make reference
> to this anywhere.
I strongly disagree. DoS should be mentioned as it has a possibility
(although unlikely) to have a devastating effect on Tails users.
>
>>>> - How would people "manually select a trusted .onion server"?
> We shouldn't recommend a particular .onion server. I host some and we
> could make it the initial default one, but then the user should be
> free to select any server (.onion or not). Also, to ensure a high
> quality service and total reliability for Tails users, I would be
> happier if I could provide a SSD server for this purpose.
It is available in the GUI in the new version of Electrum which is great
new for Tails/Tor users. We no longer have to use the command line to
connect to an onion server.
>
>>>> - Where can people find "a trusted .onion server"?
> Exactly. People should only trust the server list in Preferences ->
> Network because those are servers which are advertised and their utxo
> set hash is checked. If one of them has a broken database or database
> not matching the other servers it'll get banned.
Tails could sponsor one or the user could select one from the list.
>
>>>> - How should our current warning about SPV be adapted?
This is open to debate between me and s7r. My personal opinion is that
it should be adapted, but not removed entirely.
>
> See below.
>
>
>> - Would it be possible to configure Electrum in Tails to use the
>> existing onion servers on top of the usual servers? instead of the
>> usual servers?
> There's no current setting for this, but I made a note for this. Some
> option like prefernet=tor.
Good idea. You should propose this feature to Github
https://github.com/spesmilo/electrum so that it can be included in Tails
in the future.
>
>> - In that case, do we need to trust them all? - What happens if
>> some of them go down?
>
> I am not sure I understand the q. We can provide one .onion server for
> when connecting for the first time. After that the user can change if
> they want.
>
> It would be nice if we could attract some funding for this and have a
> SSD server for this (normal hard disks are slower for leveldb).
>
> My server is: 3ffk7iumtx3cegbi.onion but it's not SSD :( from time to
> time lags for 2-3 seconds, but reliable (99% uptime).
I absolutely agree. This is the best long-term solution although it
requires cost in hosting and maintenance. Your server should not be
trusted unless merged into Tails developers' exclusive control.
> ==============================================
>
> Here are my proposed additions to the doc. page. Feel free to
> add/remove/rephrase where you think it's needed:
>
> 1. Define 'seed', after first line: "- Your wallet can be recovered
> [...]". Add these lines:
>
> - The seed is the string of words generated by Electrum when creating
> a wallet (startup). The exact order of the words matters - if just one
> word switches place, electrum will generate an entire new different
> wallet (bitcoins from old wallet will be lost forever).
This should be included in the client itself and not the documentation.
>
> - Make sure you backup your seed. Don't save it somewhere online in
> plain text. Write it on a piece of paper and keep it in your wallet
> for example. Keep backups in multiple places. Remember: bitcoin is
> like cash - once lost, you don't have a place to go to and complain.
> Forgetting the seed is equal to total and permanent loss of the
> bitcoins in that wallet. NEVER EVER SHARE YOUR SEED WITH ANYONE.
This is already mentioned in the Electrum client.
>
> - For additional protection, you can also enable a password for your
> wallet, so while your system is running private keys are encrypted
> with that password.
This is obvious.
> ==============================================
>
> 2. Add to "Bitcoin is not anonymous" highlighted section:
>
> Electrum tries hard not to reuse addresses. Once an address is used,
> it will be marked as so and a new one will be generated. Addresses are
> generated deterministically so all of them can be recovered in case
> you restore your wallet from seed.
>
> For every transaction, Electrum will send the change (if any) to a new
> address, listed under 'Addresses'/'Change' section. This makes it hard
> for observers to analyze the transaction and determine which is the
> payment, which is the change, and where it was sent.
This is way too specific. No user action is required. It is automatic.
>
> If you want to send the bitcoins from a particular address, go to
> 'Addresses' tab, right-click on the desired address and select 'Send
> from'. Please note this will logically allow you to spend only as much
> as you have available in that particular address, minus miner's fee.
> You can select multiple addresses to send from in a single transaction.
This is already mentioned in the Electrum wiki.
> ==============================================
>
> 3. Add to "If you loose your seed, then you loose your entire wallet
> [...] highlighted section:
>
> Even when persistence is activated, it's still very important to
> backup the seed of the wallet, so you can restore it in case something
> happens to that particular Tails persistent install.
This is obvious and unnecessary.
> ==============================================
>
> 4. Add to "Do not blindly trust the bitcoin balance that Electrum
> displays [...]" highlighted section:
>
> SPV is vulnerable when it comes to unconfirmed transactions
> (zeroconf). It's desired to wait for at least 1 confirmation before
> trusting the balance. This is the reason why Electrum will show the
> unconfirmed balance separately, for example: Balance: 3 mBTC [+ 12.2
> mBTC unconfirmed].
Zeroconf is not widely used terminology, so I would remove that.
Otherwise, I agree with this suggestion.
> ==============================================
>
> 5. Add new highlighted (!) section:
>
> The unit in Electrum by default is mBTC. You can change this in Tools
> -> Preferences -> Appearance -> Base unit.
> mBTC is the 1000 part of BTC (considerably less):
> 1 BTC = 1000 mBTC
> 1 mBTC = 0.001 BTC
I agree completely although I would like to rephrase it later.
> ==============================================
>
> 6. Add a section with information about Electrum servers and their role:
>
> Because it doesn't download the entire bitcoin blockchain so it can
> start and sync instantly, Electrum relies on special servers called
> Electrum servers. These are run by volunteers. You can select any
> server from the list (Tools -> Network), but since everything goes
> through Tor it's desired to pick an .onion Electrum server.
This is obvious and unnecessary again.
>
> Here's a summary about what an Electrum server can do or cannot do:
Overall, this is good for Sajolida and other Tails Developers to know,
but it is unnecessary to warn the user in the documentation.
>
> - An Electrum server cannot steal your bitcoins;
> - An Electrum server cannot lie about your CONFIRMED balance;
> - An Electrum server cannot generate / sign transactions on your behalf;
This is a duplicate of your first point.
> - An Electrum server could hide an incoming (unconfirmed) transaction
> from you, but it won't be able to hide it once the transaction gets
> confirmed;
> - An Electrum server could not broadcast an outgoing transaction
> (payment) sent by you;
I'm not sure what you mean by this.
> - An Electrum server can see the addresses in your wallet, but it
> still cannot tie them to a real IP address, because the connection
> goes through Tor.
This is mentioned in other Tails documentation.
>
