Topic: Electrum - Bitcoin client for the common users (friendly and instant) - page 27. (Read 110105 times)

Stupid question: When I import privatekeys into my Electrum wallet, does that somehow affect the deterministic address generation? Will the future generated deterministic keys differ from the keys Electrum would have created if I hadn't imported other private keys?

python 2.7

Electrum is based on 2.7 or 3.3 python?
I tried with 3.3 and it didn't compile the setup.py, error on line 16

Windows User here

I have the code for watch-only address import in my fork of Electrum along with some other useful stuff. I'm waiting for Electrum to stabilize with all the new stuff done before attempting to pull/merge fix my fork so that I can send pull requests. I suspect that my stuff may not merge nicely now due to many changes since September, and I haven't had time lately, but I do want to eventually offer my improvements to the mainline.

Hmm, I think "contiguous" is more appropriate than "next" here, although I am not a native speaker. Also, I think "gap" is better than "buffer", because it has nothing to do with "buffer" in the sense of "memory" or so...

Anyway, another text proposal from my side (albeit not quite as concise):

BTW: I have another proposal for Electrum's implementation of the "recovery from seed"-procedure in the first place:
Why not hard-coding a reasonably high number, like e.g. N_gap_default_recovery=[20], into Electrum's code, that implies that every wallet from seed recovery will always use this value of N_gap=[20] for the recovery procedure. If it doesn't find any used address in a sequence of [20] contiguous addresses, it stops the recovery process, and than in the receive address list of course it only displays as many addresses as specified in the user settings (e.g. N_gap=3 or whatever). Only if the user changes the value N_gap in the user settings to a higher value than this hard-coded value of [20], a warning message pops up that tells the user that he should remember this value in case he should later want to recover the wallet from seed and asks if the user really wants to set such an unusually high gap limit and knows what he is doing ("only for expert users..." or something...).
Upon recovery of the wallet from seed, there could be two buttons, called something like "recover from seed now" and "recover from seed with special gap limit". When clicking the second button, a new dialog asks for the gap_limit value (that the user then typically sets to a value > [20]) that the user wants to use for the wallet recovery procedure.
   Why this? And why "20"? Because under normal circumstances a normal user probably never needs to set a gap limit > 20, but 20 is still low enough such that the wallet recovery procedure does not take overly long. Note that under normal usage, the user will anyway be 100 or more addresses down in the seed's sequence of addresses, so the wallet recovery procedure will not take significantly longer if the recovery procedure needs to check e.g. 170 addresses instead of only 150 addresses.
   To summarize: With this modification the average user gains some comfort in terms of configuring the gap_limit within a reasonable range (1-20) without getting "bothered" with having to remember anything about the "gap_limit". Only very few expert users that need to use gap_limit values >20 (for whatever reason...) will need to care about it.

[off-topic: Another useful feature would be to sort the lists by address/by date/by label name/by balance/by nb of Tx/by flag/... upon clicking on the respective column heading - actually this is the only thing I missed in today's GUI - aside a comfortable GUI-based offline transaction concept à la Armory and GUI-based private key importing (e.g. for vanity-keys administered inside Electrum) or public-key-only-importing (e.g. for "watch-only"-wallets).]

Propolsal: Call it a buffer not a gap(makes significantly more sense to me to call it a buffer), and replace contiguous with a more simple "next"

The help says: "The gap limit is the maximal number of contiguous unused addresses in your sequence of receiving addresses."
As a corrolary, the recovery stops when no more address can be extracted without violating this condition.

I am sorry if that is not clear for you. If you find a better way to explain it, in a reasonably concise manner, please make a constructive proposal.

I read that but it doesn't have any specifcs. I'm asking about exact conditions that determine when recovery stops creating addresses but I guess I should just read the code as that's what we expect each user to do, right?

yes, the gap limit is used to know when recovery should stop.
there is an explanation text that you can read, see the the help button in your settings dialog.

How does Electrum decide how many addresses to recover from the seed? For example, does it stop when an address is generated with no trx in the blockchain? Does it generate them singly or in sets of N qty, where N is the gap limit? If every address in one gap limit set is not used does that stop further recovery?

if it was the case, it would be really bad... it would mean you do not recover all your money.
do you think it would be acceptable ?



Of course not.
Your password is only used to encrypt your seed locally (on your hard disk).
you can use the same wallet (same seed) on different computers, with different passwords.

OK so I've installed Electrum and wrote down the seed and sent a coin there.  Now I see the wallet has created more addresses than the five initially created.  If I restore my wallet from seed will it have these newly created extra wallet addresses in it or just the first five wallet initial wallet addresses created first with the wallet on installation?

Also if I create my wallet from seed will it still have the same password from the initial wallet?

I have been thinking about this as well. However this is becoming privacy issue...

I would think this could be built into the client as an option. eg. it has an option for default transaction fee now but this could be split into two items or simply have the value split in half.

Then when the client builds a "send" transaction it adds an output for the server's btc address for the fee portion. This seems to me like the most transparent yet configurable way to allow a small stream of fees to support the server handling transactions. It's not even much code to do that. But it would perhaps require that servers have an api call that provides the correct address as parsing it out of the Wall text seems like a poor idea.

how do IRC servers make for living?

Didn't even think of that...  Well, donate button for the server you're connected to then

No, I don't. I'm not even keeping the logs for longer then a day (lograte just throws them away at midnight).

Are you recording IP-Address to Public Seed mapping information? It might be possible to monetize such info at some point in time. It's an issue.

I think it's very hard to offer something on a paid server that a non-paid server can't do. There has to be an incentive to pay for the server, something that differs from the free servers.

Anyone can setup as many virtual Electrum server as he wish...