1. There is an Electrum client in development for Kivy (specifically for Android) which Kivy supports iOS.
2. Kivy is a compiler for Python that compiles into objective C or Java (for iOS or Android)
3. If you got in touch with the developer working on Kivy, it would not be unrealistic.

Two caveats:
1. Most of the Kivy project has been coded, and most of the work, if you were to help, would be fine tuning for the iOS compiler instead of the Android compiler. Your school may not like that you just jumped on an almost all done project instead of making your own.
2. Electrum deals with money. That may have legal implications wherever you live, I don't know.

Kivy:
http://kivy.org/

A mock-up of the in-development mobile app for Electrum:
https://www.flinto.com/p/2a99c7d8

If you idle on IRC in #electrum, I believe qua-non is the name of the guy working on it.

How would you plan to implement this securely without exposing the pubkey?

The entire reason for not reusing addresses and using two types of hash on the pubkey is so you wouldn't have to expose it, protecting you from a theoretical breaking of ECDSA.

Obviously this would require a digital signature to prove ownership to the lock function, and thus expose the pubkey.

How would you mitigate this problem?

I saw your post in IRC.

You are aware that Ubuntu, just like Mac OS, has its toolbars on the top of the screen, correct?

The "File" "Wallet" ... etc. menus are on the top of your Ubuntu's desktop, NOT on the top of the window itself. (You, of course, must have Electrum open as the active window when you click on the top for the menu to show up.

Let me guess, Windows user?

Make sure your private key looks like this.

If you have something before or after it, delete the unnecessary text and try again.

You can import multiple keys at once by adding a line break between keys (no commas or anything)

ex.

Bitcoin Core wallet.dat has hundreds of hidden addresses in a "pool" of addresses.

Importing the entire wallet would take a long time, and could swamp your Electrum wallet with keys that are not able to be backed up by your seed phrase.

This is why it is better for the user to send their bitcoins to a newly created Electrum wallet.

A "noob" type person would probably think that "oh, ok, now I have imported my wallet.dat, I can just remember this 12 word phrase and delete my wallet, right? *deletes*"

No one wants something like that to happen, so just send.

Yes. Just recently the lead dev was on IRC and mentioned he was almost done with other engagements, and since Electrum 2.0 is, for the most part, ready. He would continue work on it soon.

Just be patient. He also mentioned that if Kivy's iOS porting was good, it could lead to a soon-to-follow iOS version... but that's a big if.

Pretty much.

Also another downside is that it would be nearly impossible (without a change in the current firmware) to send TO one of these addresses with this method from a Trezor etc. (As you need to multiply their scan_pubkey with the private key of your first input's address.)


This COULD be remedied by inserting the scan_pubkey into the trezor, having the trezor multiply the appropriate privkey with the inserted scan_pubkey and returning the shared secret pubkey.
Also, this would make it difficult to send TO from an offline wallet (a la Electrum offline wallet) but that would just be a pain in the *** rather than an impossibility. It would involve changing the format of an unsigned transaction for signing offline into a format that would not be backwards compatible with older software... which is not ideal.

Anywho, my main goal for this test is to learn more about the server load caused by checking every input of every transaction.

The current Android version is deprecated since 1.8.3... meaning that it will no longer be updated. (you can try compiling it using 1.9.8, but it will be super buggy)

2.0 will have a newer Android version that will come out on the Android Google Play Store and the UI will be 100x better.

However, with 1.8.3 Android (the crappy one) the way you do this is as follows:
1. You create your main wallet. Then exit Electrum.
2. You use a file explorer app to go into the sd card and change the name of wallet.dat to wallet.dat.old or something else.
3. Open Electrum again and it will ask to create a new wallet.
4. Click restore. Then click QR code. Then scan the QR code of the Master Public Key from your wallet you want to watch.
5. Now to switch between wallets, just make sure the one you want to open is named "wallet.dat" It might help to name the one that is not wallet.dat whatever it is... so if you see "wallet.dat.watch" you know the main wallet is wallet.dat and "wallet.dat.main" would let you know the watch only wallet is wallet.dat... etc.

Android for 2.0 will have multiple wallet access from the main menu screen, as well as access to multi-sig that can work together with your PC etc. for 2FA

Just wanted to:

1. bump this.

2. Let anyone know that I am going to be implementing this into mr_burdell's testnet branch of Electrum (because testnet FTW) starting today and maybe have it running early next week.

3. I will be testing discovery methods while communicating with mr_burdell to see what the load on his server is like. (he is the only testnet server afaik)

4. If anyone else would want to test it out with us, idle in #electrum for the next week or so and I'll pop up when I'm done.

Currently there are no easy watch-only solutions for deterministic wallets. (Note: Pre-2.0 Electrum is not HD, as there is no Hierarchy)

It would be easy to make, but to be honest, Electrum isn't an always-open solution anyways... so if you can spare the 10 seconds to own your main wallet, just make another shortcut on your desktop to open a second instance of Electrum to your wallet you want to watch.

You can open as many Electrum windows as you want, and they will share the daemon in the background. So if you set a shortcut that points to the second wallet using the -w argument, it shouldn't add any more than 2 seconds to the user experience.


Signing balances: Currently there are no programs to sign/verify for MPK balances. However, it would be easy to make... The signature would be telling them your MPK though, so they would be able to follow your balance for the rest of time... this is probably why no one takes the time to make such a feature, a lot of privacy advocates in the space.

> The most important is the one you've noticed, but I think it's worse than you think it is:   It prevents any delegation of scanning because you cannot scan without putting one of you spending keys at risk.

This is where the "Dual-key" method of Dark Wallet comes into play. The "Scan keypair" is a special key that is down a predetermined BIP32 oath of all hardened keys. This key is only used to generate the shared secret for discovery, but the private key is not used for spending. This key's private key remains unencrypted in the wallet file for Dark Wallet so that it can be multiplied to the ephemeral pubkey.

I think that if you are ok with giving someone your extended public key, the equivalent in this scheme would be to give them your scan PRIVATE key (as this is what is needed for discovery, but not spending)

I agree that this would be difficult to do with something like a Trezor... (I'm sure no matter what the circumstances, they don't want ANY private key to leave the device) but to be honest I don't find that to be a problem. Trezor is compatible with BIP32 (and 39 and 44), and that's it, that's fine. Not every wallet must support receiving to this scheme.

I also realize it would be difficult to send TO one of these types of addresses FROM a Trezor, unless you could somehow send the pubkey to Trezor, have it perform the ECmult and spit out the shared secret point... but again, I think if there was enough demand, it would not be impossible.

> It creates an assumption that you have access to the private keys on the coins you're spending. In the case of a shared wallet, vault service, escrow, or coinjoin you do not (or only have some of them). If it relaxes which keys can be used for inputs, it would at least still support the coinjoins but require N fold more ECDH work for the scanner (as it much check each input).

In the case of hosted wallets. By this point, static addresses are almost useless. Sending to a coinbase hosted address of this scheme would only have the merit of not letting the outside user see Coinbase's funds... but to begin with most people don't post Bitcoin addresses from Coinbase to begin with (they have payment pages etc.) So I don't see this as an issue. Different use cases for different people.

I also though of the N fold problem for coinjoin. My thoughts were that someone could just scan every input from every transaction, OR the sequence value of the input used could be changed from 0xffffffff to some other set value, and the client would only check inputs with that value etc. (This is similar, in effect, to the prefix's role in the current Stealth system) This would be where you could trade off privacy for performance. ie. SPV wallets could require a specific value in sequence for all payments (in other words, any address generated by the SPV wallet will place a specific prefix value) and the sender would always follow the prefix value included in the address. This way weaker clients could be slightly less private, but keep the merit of not reusing addresses, and having a static address to send to, and clients like Armory could have 100% private addresses that scan every single input for possible matches as they come in.

> It also makes the user pair mapping staionary. If I pay you some coins, and then later pay you some coins recieved to the same key... it'll use the same address, and thats bad for both our privacy. This also means that I cannot forget where I've sent funds without also forgetting my spending keys.

This is not true. My method states that the address generation requires 3 EC points, 1 from ECDH, 1 from the scan pubkey (contained in the stealth address) and 1 from the hash of the prevout hash || vout of the input || index=0x00 (The index is only used when the same person sends to the same stealth address more than once in the same transaction. A rare use case, but need to account for it) because of this, using the same prevout hash and vout would mean it was a double spend... so the addresses should never generate the same... in regards to the index. In the situation where the client scans every input of every transaction, the client would say, if a stealth send is found, try the same input again but changing index to 0x01, and increment until you find no more matches.

> Then, related to the assumption of private key access, there is the issue that it it creates a bad coupling beyween the spender and the recivers pubkey types. If I start using some new kind of multisig script, or perhaps a hash based signature or something else to control my own funds, then suddenly there are all these addresses which I can no longer directly send to.

This is true. However, I think as long as the ScriptSig has ANY pubkey in it that the person generating the tx has access to, it should be fine. (aka, discovery might be something like "if input is p2sh, check the redeemscript for pubkeys and iterate through them, etc.) and the person who generated the transaction on the senders side would use their keypair to generate the output when they sign the incomplete transaction.

> I'd originally thought it might be useful to _optionally_ support doing something like this, when the stars and moon align to make it possible... but the required bad security practices and huge slowdowns from having to do lots of extra ecdh to scan made it seem much less attractive. Plus there is a risk that the one side of the optional configuration doesn't exist and you get people unable to use different pubkey types, or people losing funds that were sent to them because their software won't notice the payments.

I also think that this is an optional thing to do. Similar to the way p2sh is optional, and BIP32 is optional...
I think the idea of the current implementation of Stealth and my method are similar in their main goal which is privacy, but static addresses.
There are a lot of hurdles that can be overcome by removing privacy, like for instance, making a 4 byte prefix and placing it on your address, then anyone sending to that address must change their ECDH input's sequence value to that or something else. Heck, if it becomes widespread enough maybe doing a fork like p2sh could happen somehow to give it it's own place on the transaction etc.


I think your points are valid, but most of them seem non-issue / would be known as accepted by anyone wanting privacy.

Thanks a lot for the feedback. If you have any more questions let me know!

Also, > If I start using some new kind of multisig script, or perhaps a hash based signature or something else to control my own funds, then suddenly there are all these addresses which I can no longer directly send to.

I am curious what other kinds of scripts you had in mind here.

Prerequisite: Understanding how DarkWallet currently implements stealth addresses.
See: https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth

Remember: Don't turn this into a thread about yes/no to stealth in general. I would like to keep the discussion on how to make my method better, AND possible merits / demerits of this method compared to how DarkWallet currently handles them.

Here's my proposal in psuedo-Python format. (this is not a script, so don't try to run it :-P)
http://pastebin.com/bcs8XFNG

Caveats:
1. Can't send to stealth from Trezor using this method. (as you need to multiply your private key with the scan_pubkey)
    Unless Trezor allowed for performing ECmultiplication on the device, and Trezor returns the shared secret.

2. When thinking about coinjoin and other aspects where multiple people spending to multiple stealth addresses, if we consider coinjoin, we must check every input of every transaction against our info... which is costly. Doing things to mark inputs as stealth info (maybe changing the sequence value) could be considered... but for 100% stealth and 100% no way to discern stealth from normal... there seems to be no other way than to check every input.

However: that being said... it eliminates the requirement for the OP_RETURN table on Obelisk servers... and it's not much more strenuous than running a full node. (having to scan every input of every transaction etc. when blocks come in) but it will be more strenuous for SPV servers, as upon every block they will have to send every transaction to each user... it will also be hard to do on mobile devices (drain battery)... obviously the wallet file would store the most recently checked block so that it doesn't check from the beginning every time.

Perhaps a mode where the wallet doesn't actively search, but users need to input the txid or something that they receive from the sender might be good for mobile...


I am open to comments. Currently I think that the OP_RETURN usage is a hurdle to making stealth addresses ubiquitous... and I'm sure my method won't get us all the way there.

Just wanted you guys to know I'm thinking about you. :-D

PS. Electrum 2.0 /w Send-to stealth support? https://github.com/spesmilo/electrum/pull/817
      Anyone who can help test this commit, please thank you! :-)

https://github.com/spesmilo/electrum/pull/817

If anyone could pull these commits and test it out for me, I'd appreciate it.

Currently, only DarkWallet can receive stealth payment, so try making a new Main Net DarkWallet and send yourself 0.0001 BTC or so. Remember DarkWallet can only receive stealth payments after they've confirmed.

50% of Pregnancies should be Men.

50% of Sperm donors should be Women.

Replace the addresses with what you want to query, it will come back as a json.

Here's how you can estimate your fee:

(149 Bytes (181 Bytes if uncompressed)x number of inputs) + (34 Bytes x number of outputs) + 10 Bytes = Size of transaction in bytes.

If you are receiving a lot of small amounts, then your input count will be sky high, and if you're sending to a bunch of people at once, then outputs will be high too.

With compressed inputs, you can fit 27 inputs and 27 outputs in a 5,000 byte transaction. For uncompressed you can fit 23 inputs and 23 outputs.

If you want to keep your transactions sub-1,000... you need to keep them down to 5 inputs and 5 outputs for compressed, 4 inputs and 4 outputs for uncompressed.

But when you think about it, you're getting more bang for your buck with the larger transactions.


Let's take things back a bit... Why don't you just create your own raw transactions and use bitcoind to sign them? (ie. DON'T use Createrawtransaction and just make your own and feed it into signrawtransaction?)

If you set it to 0.0001 and it's giving you a 0.0005 fee, that means your transaction's filesize is between 4,001 bytes and 5,000 bytes.

You won't lose everything.

As long as you have those 12 words.

Using my 12 words I could calculate the first 100 addresses (along with their WIF private keys) of my wallet for you in about 1 minute using commands in a Python console WITHOUT even touching Electrum OR the internet.

It's all just math.

1 + 5 is always 6

Your 12 words will always generate the same addresses in the same order.

Hint: You don't need Electrum servers at all to restore your Electrum wallet.

Yeah. Though the easier way might be what ThomasV just said:

1. Click "Master Public Key" on your wallet.
2. Copy it.
3. Click "Create New" under File.
4. Name your wallet file "default_wallet" (or you can just name it something else, then rename it later, Electrum opens default_wallet by default on startup)
5. Choose "Create New Watch Only Wallet"
6. Input your Master Public Key from #2
7. Delete your old seeded wallet (assuming the seeded wallet is already on your other computer) and make sure the new watch-only wallet is named default_wallet and is in the wallets folder.