you can do the same with type 2 deterministic wallets.
I already thought about building this into Electrum.
The drawback is that you need to know the ID of the payment (your invoice), and to use exactly the same ID on both ends.
if there is some confusion there, I imagine that it some disputes can arise between sender and receiver.
I'll have to read up on type 2 deterministic wallets. I don't think I'm discovering something new. I question why we need all these addresses and private keys in the first place. All you need is one private key per entity. Create a new address? Just sha(description) or sha(timestamp). Want my SMTP to send your email? sha(message) to each recipient so they can recover coins. I agree. as I said, I considered doing this within Electrum. I guess I will add it at some point. Two obstacles have prevented me from doing it: - lack of privacy. if you give out your master public key, anyone can see if you received payment at a given label. - it is not as idiot-proof as Bitcoin addresses. As I said above, if the label is misspelled or incorrectly transmitted, the receiver might get very angry. the second point could be mitigated if the address generation from public key is a webservice. that service would keep a log of all the addresses generated, and it would be possible to find a missing payment. |
|
|
|
|
you can do the same with type 2 deterministic wallets.
I already thought about building this into Electrum.
The drawback is that you need to know the ID of the payment (your invoice), and to use exactly the same ID on both ends.
if there is some confusion there, I imagine that it some disputes can arise between sender and receiver.
|
|
|
|
|
note: the version of this script included in the 1.3 package does not work.
Please use the version in the git repo.
|
|
|
|
every date is 1970-01-01 09:00. Is that just me?
still after you restart the client? this might be a gui problem |
|
|
|
I tried out Electrum and I'm quite impressed with it. Light, simple to use deterministic wallet that doesn't need to download the whole blockchain to spend from it - that's really great!
Is there a simple way to dynamically generate deterministic addresses for Electrum on the server side without risk of compromising private keys (so that I could receive bitcoins on my desktop without synchronization of addresses)?
yes, there is a script that does that. see "merchant.py" in the scripts directory. (note that the merchant script included in the 1.3 package does not work; you need to pull the recent git) here is the relevant thread : https://bitcointalk.org/index.php?topic=117199.0 |
|
|
|
I'm using 1.3; all transactions show up as pending, even those done months ago. The list is not sorted, probably for the same reason.
Any ideas? Only me?
it is because they need to be verified. just wait a bit As I said they are months old! The other electrum (0.61) has them all confirmed. There are 100s of transactions. What causes this? the old version did trust the server about confirmations. The new version verifies that all your transactions are included in the blockchain. The verification should only take a few minutes; if it is longer than that you have a problem. |
|
|
|
I'm using 1.3; all transactions show up as pending, even those done months ago. The list is not sorted, probably for the same reason.
Any ideas? Only me?
it is because they need to be verified. just wait a bit |
|
|
|
|
thanks for the Windows build.
Note that you can include an incomplete headers file; it will still save some download time.
The length of the file should be a multiple of 80
|
|
|
|
Is there a registration problem right now?
I have sent the fee but my username and email is not known to the system.
Even though I received the welcome Email.
Hi, I just saw your message and sent you a PM. indeed, it seems there was a problem with the payment processor. I will activate your acount manually. Edit: the problem has been solved, and your account has been created. sorry for the delay. |
|
|
|
But I also needed to download ecdsa, slowaes and setuptools as dependencies.
oh sorry, I forgot to add them again.  ok, I just uploaded new packages that contain ecdsa and aes On a different note, I'm not sure if this has been covered elsewhere, but Electrum 1.01 (which I was using this morning before I saw the new release) was not listing new transactions. I had a few transactions last night that didn't show up in 1.01 (all had 80+ confirmations) until I changed the server to ecdsa.org (all the other servers allowed synchronization but didn't display the latest transactions). Same thing in Electrum for Android. The transactions that occurred last night are not showing up, even though it says it's synchronized. I'd try ecdsa.org to see if that fixes it too but it doesn't seem to want to let me use that server.
Edit:
Switched to ecdsa.org on e4a and now everything is good.
yes, that was probably a server problem |
|
|
|
I get the following error in windows: C:\Electrum-1.3>python electrum
File "electrum", line 204
except SystemExit, e:
^
SyntaxError: invalid syntax Anyone? you are probably using python3. try with python2. |
|
|
|
It seems the below option no longer works (electrum still seems to download & check the headers):
indeed, I had to remove that option, because Electrum now uses block headers to get the timestamps of transactions. |
|
|
|
|
Electrum 1.3 is officially released!
Changelog:
* New client-server protocol, the client downloads raw transactions and deserializes them.
* Simple Payments Verification (SPV) is now fixed. (the previous version had a vulnerability, reported by mhanne)
* A file containing the blockchain headers is included in the package.
* A new 'text-mode' user interface is available. It does not have as many features as the other GUIs, but it works and can be used if you don't have a graphical environment.
|
|
|
|
|
Hi,
I did not release version 1.3 yesterday as planned, because it needs a bit more testing (several bugs were fixed yesterday), and also because I would like to wait until a few more servers have upgraded to protocol version 0.5.
(this is a major protocol change and 1.3 clients cannot use old servers; if you use the recent git version you will notice that the client does not even report the old servers).
In the meantime, many thanks to all the people who have been testing the git version. please keep reporting bugs!
|
|
|
|
No problem...
Now I'm getting another error every few seconds. (This is with my existing wallet, while downloading/verifying the headers):
I was not able to reproduce it, but I fixed a possible race condition that could have caused it. please let me know if it is fixed |
|
|
|
I'm getting this error at startup when trying the latest github code: [...]
thanks for testing! try now, I fixed that |
|
|
|
Someone showed me that my current SPV implementation (in version 1.2) has a bug, and that it needs to be updated; the client needs to download its transactions in serialized form in order to ensure they have the correct hash.
I will try to do this soon, but it might take some time, because it requires a modification in the protocol.
This bug is fixed in the github repo. The fix comes along a protocol change, that will also fix the infamous "cannot spend coins" bug I will try to release version 1.3 tomorrow (the 1-year anniversary of Electrum!). Note that since the protocol has changed, new clients will only be able to connect to upgraded servers. |
|
|
|
|
I pushed another server update: version 0.5
This version requires the latest version of bitcoind (currently in git head), compiled with a new patch that is in the directory "patch"
This new protocol sends serialized transactions directly to the client, and will be required by electrum 1.3 clients.
So, please update your servers; I know it is a pain to have to patch bitcoind again, but this is necessary for spv.
|
|
|
|
|
Show Posts
