Topic: Abandoned project... (Read 4297 times)
Haven't looked into it... but if there's a way already setup, then I would likely implement that version ahead of designing my own (since I'd have to create the desktop counterpart anyways).
I was just thinking of adding that to my wishlist for future handling 
When working on each of the design phases, I'll try to make sure I handle the offline case and try to plan such a feature in so that when I do get around to implementing it, it won't be against the grain.
Since the client will have to deal with being offline, I may have to send along additional data other than just the transaction - I'll likely have to transmit sufficient identifying information... example to illustrate the issue:
* Transmit to phone transaction through series of QR codes or some other means
* Phone decodes transaction
* Phone scans through addresses until it finds the ones that match up w/ the transactions (generating 1 after the other...) so the related private key can be determined
* Phone presents transaction back via series of QR codes
The address scanning could possibly take a LONG time... so additional data could be transferred along with the transaction data for how the online client was able to generate the public key (Electrum sequence identifier, or in case of BIP 0032, the child number and parent identifier... perhaps the whole list of parent/child identifiers)
In any case, I think it is a very good use case to have a phone that is dead to the world for all intents and purposes, but can do the job of a hardware wallet.
It may make sense to make a separate application for this purpose... of course it'd use the same library I am writing up... but it would be without Internet usage and many features would be omitted to save space and memory ... things a "dead" legacy phone may be low on (like my old Samsung Moment that's kicking around).
When working on each of the design phases, I'll try to make sure I handle the offline case and try to plan such a feature in so that when I do get around to implementing it, it won't be against the grain.
Since the client will have to deal with being offline, I may have to send along additional data other than just the transaction - I'll likely have to transmit sufficient identifying information... example to illustrate the issue:
* Transmit to phone transaction through series of QR codes or some other means
* Phone decodes transaction
* Phone scans through addresses until it finds the ones that match up w/ the transactions (generating 1 after the other...) so the related private key can be determined
* Phone presents transaction back via series of QR codes
The address scanning could possibly take a LONG time... so additional data could be transferred along with the transaction data for how the online client was able to generate the public key (Electrum sequence identifier, or in case of BIP 0032, the child number and parent identifier... perhaps the whole list of parent/child identifiers)
In any case, I think it is a very good use case to have a phone that is dead to the world for all intents and purposes, but can do the job of a hardware wallet.
It may make sense to make a separate application for this purpose... of course it'd use the same library I am writing up... but it would be without Internet usage and many features would be omitted to save space and memory ... things a "dead" legacy phone may be low on (like my old Samsung Moment that's kicking around).
Ok, Tor usage...
Slush runs a Tor-protected Electrum server (alongside the normal servers):
TCP: electrum.bitcoin.cz:50001
TCP+SSL: electrum.bitcoin.cz:50002
HTTP: electrum.bitcoin.cz:8081
HTTPS: electrum.bitcoin.cz:8082
TCP: 4lhnnupincd3gyda.onion:50001 (Tor)
^^ info copied from the cached version of download.electrum.org
Your best best for getting a fully tor-protected connection is to use a Tor service. There are other Tor-protected Electrum servers I believe...
You can configure Electrum to use a proxy out-of-the-box by using "./electrum --proxy=socks5:localhost:9050"
... note that, as I currently recall, Label Sync (and probably alias resolution) do not use the proxy... could easily be wrong...
Electrum for Android "should" have proxy support once released, that way you can hook it up to either a remote proxy or a local Tor instance (ex: Orbot). I'll be sure to test the reference implementation of the socket system in Android and my test device, but if there's any concern, I could probably cook up a "test" to see if the proxy implementation is doing it right (no DNS leakage/etc).
Slush runs a Tor-protected Electrum server (alongside the normal servers):
TCP: electrum.bitcoin.cz:50001
TCP+SSL: electrum.bitcoin.cz:50002
HTTP: electrum.bitcoin.cz:8081
HTTPS: electrum.bitcoin.cz:8082
TCP: 4lhnnupincd3gyda.onion:50001 (Tor)
^^ info copied from the cached version of download.electrum.org
Your best best for getting a fully tor-protected connection is to use a Tor service. There are other Tor-protected Electrum servers I believe...
You can configure Electrum to use a proxy out-of-the-box by using "./electrum --proxy=socks5:localhost:9050"
... note that, as I currently recall, Label Sync (and probably alias resolution) do not use the proxy... could easily be wrong...
Electrum for Android "should" have proxy support once released, that way you can hook it up to either a remote proxy or a local Tor instance (ex: Orbot). I'll be sure to test the reference implementation of the socket system in Android and my test device, but if there's any concern, I could probably cook up a "test" to see if the proxy implementation is doing it right (no DNS leakage/etc).
If you want to bring that to fruition, I'll PM you details.
Regarding addresses and standard Electrum derivation that I am more familiar with, if you have the master public key, you can derive all addresses you will ever receive to, however with just addresses, it is not practical to determine related addresses.
Heres a post I did on Electrum derivation, jumping between addresses requires the Master Public Key: http://e4a-ne.blogspot.com/2013/07/electrum-address-generation.html
As for backup, my backup format will be backed up encrypted by a chosen passphrase. I will follow Titanium Backup's method and use an asymmetric key so that backups require no password, but restoring will. Personally I don't fully trust a backup service unless zero knowledge or client-side encryption is used.
I don't think obfuscation / misdirection will be necessary given the encryption, however if someone wants me to add something akin to "hidden volumes" by making multiple passwords come up with different wallets, that can be a commissioned feature.
I'll also consider at some point making wallets' "public" data encrypted so if you lose your phone, your privacy is not lost regarding my client.
I will post again a little later about Tor usage (which I'll make possible in my client by allowing proxies).
Regarding addresses and standard Electrum derivation that I am more familiar with, if you have the master public key, you can derive all addresses you will ever receive to, however with just addresses, it is not practical to determine related addresses.
Heres a post I did on Electrum derivation, jumping between addresses requires the Master Public Key: http://e4a-ne.blogspot.com/2013/07/electrum-address-generation.html
As for backup, my backup format will be backed up encrypted by a chosen passphrase. I will follow Titanium Backup's method and use an asymmetric key so that backups require no password, but restoring will. Personally I don't fully trust a backup service unless zero knowledge or client-side encryption is used.
I don't think obfuscation / misdirection will be necessary given the encryption, however if someone wants me to add something akin to "hidden volumes" by making multiple passwords come up with different wallets, that can be a commissioned feature.
I'll also consider at some point making wallets' "public" data encrypted so if you lose your phone, your privacy is not lost regarding my client.
I will post again a little later about Tor usage (which I'll make possible in my client by allowing proxies).
The entire project was funded, with around 6.5 BTC over the top, adding additional features to the 1st release:
* Litecoin
* Basic BIP32 support
* Label Sync support
So, 10 BTC was the amount necessary to fund the project as a basic. Stretch goals were setup to raise the bar and positioned such that people could vote on what features were desired.
3 more BTC on top of the 10 were to get Litecoin support. Since the server infrastructure for Electrum doesn't take terribly much change to support Litecoin, the development server-side is minimal if not really already there - the cost there is servers running (though some people donated this if I recall right!). Client development involves adding generic "coin" support, which is good for basic client agility, and adding multi-wallet support to the UI side... which is already required to handle processing BIP 32 and Electrum-style wallets simultaneously but independently... just w/ the fact that the coin is different, not just address pool.
Indeed, Litecoin is often converted to Bitcoin for use... in fact one of the original stretch goals I was going to tack on was auto-conversion support by using a web-service to receive coinX and send out coinY without mucking around with requiring accounts... but that was stalled because the one Exchange I saw (BTC-e) doesn't have automated withdraw/deposit APIs. If another exchange offers sufficient APIs, I may consider creating a webservice to automate this process and add it to the client... but that's in the future, may not be readily possible... and might requiring its own funding.
* Litecoin
* Basic BIP32 support
* Label Sync support
So, 10 BTC was the amount necessary to fund the project as a basic. Stretch goals were setup to raise the bar and positioned such that people could vote on what features were desired.
3 more BTC on top of the 10 were to get Litecoin support. Since the server infrastructure for Electrum doesn't take terribly much change to support Litecoin, the development server-side is minimal if not really already there - the cost there is servers running (though some people donated this if I recall right!). Client development involves adding generic "coin" support, which is good for basic client agility, and adding multi-wallet support to the UI side... which is already required to handle processing BIP 32 and Electrum-style wallets simultaneously but independently... just w/ the fact that the coin is different, not just address pool.
Indeed, Litecoin is often converted to Bitcoin for use... in fact one of the original stretch goals I was going to tack on was auto-conversion support by using a web-service to receive coinX and send out coinY without mucking around with requiring accounts... but that was stalled because the one Exchange I saw (BTC-e) doesn't have automated withdraw/deposit APIs. If another exchange offers sufficient APIs, I may consider creating a webservice to automate this process and add it to the client... but that's in the future, may not be readily possible... and might requiring its own funding.
Any updates on this project, Thomas? Total of 16 BTC contributed over 1 year ago, and still nothing to show for it. 
I received new information about the project a week ago. He apologised for the lack of updates and promised more updates in the coming weeks.
Hi, it seems Thomas escaped with money, did not he?
Seems so 
Hi, it seems Thomas escaped with money, did not he?
Great to hear that you've already been thinking about it. In theory, would the process you described be compatible with the existing Electrum desktop client? Apparently the 1.8 client has the ability to send and receive transactions via QR codes, though I haven't actually tried it myself.
Hi, I know you've got a lot of work ahead of you already, but I'd like to request one specific feature that I've been searching for in a mobile client: offline transaction import, signing, and export, ideally using QR codes. This would allow for an old smartphone to be used as a dedicated BTC cold storage device without needing to buy specialized hardware or use an offline PC. I think a lot of people might find that to be incredibly useful.
I can contribute the rest for the remote backup support if you are short on that. If it is possible, I think it would be good to have an option to hide the balance of the wallet, or have it indistiguishable from a watching-only address, so that the NSA or whoever has access to my dropbox can't see how many coins I have.
A couple other quick questions: Can you point me to a link to how to use electrum over tor?
Also, someone told me that electrum wallet addresses are linked, in that someone can tell if two addresses come from the same seed. Is this correct?
A couple other quick questions: Can you point me to a link to how to use electrum over tor?
Also, someone told me that electrum wallet addresses are linked, in that someone can tell if two addresses come from the same seed. Is this correct?
Did this get funded all the way? Why is so much of the donation amount going to litecoin support? Litecoin has a miniscule amount of users compared to bitcoin, and it doesn't even have 100 merchants after two years of supporters running around promoting it. How can this be worth a dev's time to support? Litecoiners can easily convert to bitcoin if they want to do anything with their coins.
will the litecoin integration in the android version mean the PC version is getting it too?
Oh! Another thing! If anyone can drum up a nice high-res logo (or better yet, vector format) for Electrum for Android, I'm soliciting for low-res samples and if it's good, you get 0.1 BTC up front and if project goes through funding, another 0.1 BTC + of course your name in credits. (Sound fair?)
I'll probably make another bigger post on logo request later in other places to try to get more eyes.
I'll probably make another bigger post on logo request later in other places to try to get more eyes.
The Electrum atom logo is in vector format. Look for it in the electrum-web images on GitHub.
I have this seed in vector format too http://cl.ly/PkDg (I mean the seed alone, but has no examples in the phone)
Doing awesome on the fund raiser - too bad BTC value is tanking... may make the Litecoin server goal a larger stretch to pay for server... (actively investigating necessary resources on what it takes to run one using 'Abe')...
If you code it up I will donate a server capable of running Litecoind on Abe for at least a year.
ABANDONED
Jump to: