< gmaxwell>
luke-jr: in the meantime, if reuse is really a concern for you lets work on improving the UI flow to politely discourage it.
< gmaxwell>
I think there is a lot we can do to shift the norms.
< gmaxwell>
and also make things safer even from the perspective of someone that thinks reuse is totally fine.
< gmaxwell>
(in particular, I've seen quite a few users accidentally pay someone twice... e.g. going down a spreadsheet to make payments and just processing the same line twice)
< luke-jr>
gmaxwell: is there? I would like to hope so, but it really does seem like most people use other wallets now. :/
< luke-jr>
I mean, we can certainly improve it anyway, but I'm not sure how effective it would be in shifting norms
< gmaxwell>
luke-jr: at least by transaction count bitcoin core usage appears to outpace electrum something like 5:1
< luke-jr>
:o
< luke-jr>
that's surprisingly positive
< gmaxwell>
you get a distorted perspective from seeing what people post about.
< gmaxwell>
It's probably the case that more _people_ use electrum, but they're transacting infrequently.
< gmaxwell>
plus half those people just lost all their bitcoins anyways. :-/
< luke-jr>
are you sure you're not mixing up other light wallets for Core?
< echeveria>
electrum has some interesting usage stats that came out of the malware attack (trying to see a silver lining). information about the number of users and what sort of money they store there.
< echeveria>
gmaxwell: one mistake in MultiBit that caused duplicate payments was that it saved the previous address you paid, for some reason. so people would see the form partly filled out and assume that was the address they intended to pay, and then sent money there.
< * luke-jr>
wonders if running an Electrum server would enable him to get reasonable estimates of total Electrum wallets and their economic influence
< echeveria>
it would, roughly speaking. the RPC interface just has a literal list of addresses pushed to the server. there's a number of these which appear to be set up expressly for the task.
< luke-jr>
echeveria: a few years ago, someone decided to tip me unknownst to me, and googled "luke-jr bitcoin address", then paid a random address on the bc.i page (which luckily happened to be my *change* address in the transaction that came up)
< luke-jr>
echeveria: but do Electrum clients often pick a random server to use? or typically peg to the same one(s)?
< echeveria>
I sort of caution about making assumptions based on this sort of data. Bread Wallet used a privacy leak in their "sell BCH" function to determine that the average user who used the feature had X BTC in their wallet, and then multiplied by the number of installs to come to the conclusion that their users were storing billions of dollars. this is obviously not correct.
< luke-jr>
heh
< luke-jr>
I wish mobile wallets published their "number of current installs" numbers
< echeveria>
luke-jr: there's logic for pinning servers you've seen, but generally speaking it's random based on a returned list (which currently contains about 800 sybil servers and 150 or so real ones).
< luke-jr>
O.o
< gmaxwell>
luke-jr: in the last several releases core has made varrious changes that make its transactions readily identifyable.
< provoostenator>
It would help if more people, who work on functional tests, installed PyEnv. #14884 is only a partial solution to preventing too modern Python syntax from entering the codebase.
< bitcoin-git>
[bitcoin] instagibbs opened pull request #15452: Replace CScriptID and CKeyID in CTxDestination with dedicated types (master...key_script_dest) https://github.com/bitcoin/bitcoin/pull/15452
< bitcoin-git>
[bitcoin] achow101 opened pull request #15454: Remove the automatic creation and loading of the default wallet (master...no-default-wallet) https://github.com/bitcoin/bitcoin/pull/15454