thanks a lot; I hope this helps. |
|
|
|
Remember, ignorance is bliss!
Thanks for your opinion, I hope I didn't start any "currency wars" in this channel :|. I don't think it would be difficult to create an alt-coin version of Electrum. I do not want to be involved in that for the moment. |
|
|
|
Hello,
I don't want to cry on IRC anymore about this. Instead I will leave this post here.. maybe someone will figure it out and help me in the future.
This is the message I get while starting electrum server:
...
In older versions of server, importing of blocks was just bloody slow. In recent version it is not importing at all.
.bitcoin folder re-created from scratch
MySQL database removed and created again
Result is the same...
that traceback was a bug in the server that I introduced recently; try now, it should be fixed. I do not know what causes the import of blocks in abe to be slow. you might want to ask the abe developer about that. on my machine it was reasonable. |
|
|
|
I started to implement a few of your RPCs. I realize that 'subscribe' and 'unsubscribe' are not sufficient to handle sessions; we need a rpc that returns a session ID. |
|
|
|
the interest must come from some where else...
not true. the interest comes from other loans made in the meantime. central banks never stop loaning money |
|
|
|
I think this project died, and I can't find any WORKING, CURRENT RPC front-ends on Android. Anyone have any ideas on either getting this project back up and updated and working with the current bitcoind? Or are there alternatives out there I'm just not seeing?
nice project. I am looking for an existing android client that could be adapted to Electrum. I was thinking to use BitcoinSpinner, but perhaps this one would be better. |
|
|
|
Could it be made so that the deterministic addresses and the imported ones can be exported separately? That way I could export just the non-deterministic keys for backup or whatever
Thomas just posted how to export all keys above, just grab the one you imported manually and note it down. I don't want to have to worry about splitting my exports manually. That isn't feasible for scripted backups. The ability to export just the non-deterministic keys would make automated backups that don't expose the deterministic keys that don't need to be backed up. did you test the command? imported keys are marked as such. you can do : python electrum.py addresses -k | grep imported
|
|
|
|
Can you confirm if the following is correct?
The imported keys are not contained among the deterministic key set generated so if/when you delete your wallet the imported keys will not be coming back when you use the seed-phrase to regenerate the deterministic portion of the wallet.
that is correct. perhaps I should add a big fat warning during the import command? in any case, I think that this command should not be available from the gui, in order to make sure that it is not used too easily. |
|
|
|
I don't. I think 90-something-percent of future Bitcoin users will be using it on an iPad or mobile phone or on their computer in a web browser. What!? Nonono, that would be a bad outcome, to be avoided if at all possible! There are lots of threats against browser-based programs that don't apply to desktop apps. And if there's 2-device authentication, then it's much easier to compromise a matching pair if both clients are in a browser; they're more likely to have vulnerabilities in common. For example, someone could steal an SSL certificate, and MITM traffic on the internet connection that both devices share, replacing both clients with malicious software. Please, reconsider. The future of Bitcoin depends on there not being any more MyBitcoins or Allinvains. I wrote that online wallet services are an invitation to fraud and theft, a month before the MyBitcoin fiasco. That is still true. Don't encourage people to use them, or there will be more disasters. There is a middle ground between a full bitcoin client and an online wallet: thin clients. I can even imagine a thin client integrated into the web browser, as an extension; I guess this is what Gavin had in mind. |
|
|
|
I just uploaded version 0.35 to the website. Changelog: * New 'import' command to add extra keypairs to your wallet. Example: python electrum.py import 1MtQTsraWDcb7REUnVu8LS9hZswrLfWbH9:5KeCdRAkygEGfSzQ3ZNpQ2qE6PdEYCZ52S9Uq5DoBxkSgayX6ng
Note that you can export your keypairs in the same format using: python electrum.py addresses -k
* random selection of the default server on wallet creation * bug fix: previous version was not correctly synchronized after creating new addresses |
|
|
|
I think the mnemonic algorithm is kind of weird (using quartets of bytes??) I suggest we use the full 2000 english words list with a complete base2000 encoding: any reason for doing that? Well, the good thing is that anyone can do his own recipe with his client, as
the server is not supposed to be aware of the particular encoding, right?
indeed, that's something the server does not see. |
|
|
|
|
I answered in the windows thread; note that there is little I can to to help fix problems that occur on Windows
|
|
|
|
that's annoying. a few weeks ago I added a patch that was supposed to fix copy/paste for windows: if platform.system() == 'Windows':
from Tkinter import Tk
r = Tk()
r.withdraw()
r.clipboard_clear()
r.clipboard_append( address )
r.destroy()
else:
c = gtk.clipboard_get()
c.set_text( address )
perhaps this needs a fix? |
|
|
|
slush is going to working on a new qt client? And you're working on a gtk client in Python and I was working on a qt client in Python ( https://en.bitcoin.it/wiki/Spesmilo ). I'm going to make a client eventually for libbitcoin and was planning to adapt bitcoin-qt. We have a ton of overlap between us. When we're both around on irc and slush too might be cool to let each other know what we're all up to. Form a group or something. and I was planning to replace bitcoind + abe with libbitcoin for the servers :-) I didn't know Spesmilo was python-qt; yes we should talk |
|
|
|
Thanks for the info. My goal for Electrum was to create a client that everybody can use and understand. Features that add complexity to the interface should at least be optional. There are numerous threads where new users ask where their bitcoins have gone, after they sent them to a wallet that did not finish downloading the blockchain. Another major problem for Bitcoin acceptance is having to perform wallet backups; lots of people, including myself, do mistakes when it comes to backing up data regularly and safely. These two problems are solved by light and deterministic clients. Electrum adds nice seeds mnemonics and a fully open-source architecture to this concept. The third problem is that people have to wait for confirmations. I do not see an easy answer to this. My gut feeling is that "green" addresses are not the correct answer. For small-amount face-to-face transactions, I would say that waiting for confirmations is unnecessary. Something like http://www.transactionradar.com/ should provide enough security. For online transactions, waiting for confirmations is, in general, much less of a problem. |
|
|
|
|
there are currently 3 times more bids than asks in the orderbook; in these conditions a drop is very unlikely.
|
|
|
|
|
I do not think that it has "settled", but I believe that volatility will be lower in the future than it was so far.
|
|
|
|
Any interest in having the addresses be more visible to the user? I know some people are for keeping all the "extra" addresses relatively hidden since they might confuse the user. With these patches the "extras" wouldn't be as confusing since they would all be automatically linked to their transactions. And importantly, users could also completely ignore these features and let the client pick everything automatically.
to be honest, it is not in my list of priorities at the moment (not that I am against it, but there are more urgent things). But I think that slush mentioned coin selection as a property of his future qt gui. |
|
|
|
If you want to move funds between your own wallets, why wait any time? It's not like you are going to double spend against yourself. I think it would be nice if this was an option.
the capability to spend funds immediately is a desirable feature, whether the address they come from is "green" or not. as far as I understand, there are two aspects that users might be interested in * the user shoud be able to see when received funds come from a green address (rendering) * when spending, the user should be able to select "green or confirmed" inputs, or the coin selection method should automatically prioritize "green" inputs when confirmed inputs are exhausted |
|
|
|
|
Show Posts
