Scanning private keys doesn't work yet

[hank]

I'd like to be able to scan private keys and put them in the wallet from sites like liteaddress.

[hank]

else if (PATTERN_PRIVATE_KEY.matcher(input).matches())
{
    try
    {
        final ECKey key = new DumpedPrivateKey(Constants.NETWORK_PARAMETERS, input).getKey();
        final Address address = new Address(Constants.NETWORK_PARAMETERS, key.getPubKeyHash());

        bitcoinRequest(address, null, null, null);
    }
    // ...
}

Current behavior is to just derive the address from the private key and start a new sendrequest. This is rather useless since you'd just scan the QR of the address to do that, not the private key. Scanning private either implies an import of the address to the wallet or a sweep. We should probably ask which they want to do, and then execute it. Sweeping might require a fair bit of code because we need to:

• Import the address into a temporary wallet
• Create a SendRequest from that wallet with the full balance (emptyWallet set)
• Calculate the appropriate fee
• Send it to another address in our main wallet (maybe let user pick?)

This should probably be done in a rather automated way.
Importing the keys would be easier, and I think is a more realistic near-term goal. Next release seems appropriate for that, and we can revisit sweeps.

[hank]

@wtogami and I agree that this should be tabled for now. It looks like SendCoinsFragment and Activity could be easily modified to take an ephemeral wallet object as a parameter to an intent to make this work. Then an arbitrary send could happen. The main issue is the blockchain rescan required to derive the balance. More thought needs to be put into it.

[hank]

I just had an idea that applies to this ticket as well as #21 - what if paper wallets were HD wallets. For instance:

• I start with a new HD wallet on paper, and I scan the seed with the app to import it, and input the block height of the first transaction, the chain will be scanned and I get my balance.
• Then I make a transaction, putting the change into the next deterministic address.
• Now, imagine that I record the block height that the transaction appears in after the first confirmation on the piece of paper - say 492100. I could then blow away the HD wallet from memory.
• Later I come back and perform the process with the same seed again, but this time input that I want to use the second address, and it starts at block 492100. The chain immediately finds the transaction, finishes syncing, and I make it and blow away the ephemeral wallet again.

By chaining in this way, the sync time is simply the time between now and the last transaction, which isn't all that bad really - it doesn't get perpetually longer like it does with traditional paper wallets. Also, by encrypting the seeds with a passphrase, the paper wallets themselves could be secured.