<<  >> (p.20)
    Author Topic: Bitcoin Wallet for Android  (Read 121859 times)
    Andreas Schildbach (OP)
    Hero Member
    *****
    Offline Offline

    Activity: 483
    Merit: 551


    View Profile
    August 16, 2013, 09:32:05 AM
     #381

    Quote
    Import public and or private key by scanning QR code, so you can monitor and/or spend

    Using a vanity address?

    Trying out several mobile wallet apps, using the same set of keys?

    Those will probably never be supported. Importing keys is dangerous. Vanity addresses are a broken concept. If you want to try out different wallet apps, why don't you try them out how they're supposed to work and send coins between them?

    Quote
    Keep private key on paper, and public key in wallet. To spend money, QR scan the private key, store only in memory, spend from private key, and wipe from memory, never saving to storage

    This is a recipe for disaster. If you try that with Bitcoin Wallet, you likely will loose all your change from that paper wallet. So say you have stored your lifetime savings of 500 BTC on one paper wallet. Now you decide to pay a hefty doctor's bill from that wallet, let's say 10 BTC. The doctor will receive 10 BTC, the other 490 BTC will disappear into the void. So don't ever do this!

    That said, I would like to support swiping paper wallets entirely. The trouble is, a true SPV client cannot do that. Someone would need to invent a new paper wallet format that not only includes the private key, but also the unspent outputs that go to the address (a bit simplified). If someone comes up with a BIP standard for that and manages to get community concensus, I'd happily be amongst the first to support that. Contact me if you're interested.

    Quote
    Delete private key and only keep public to monitor amount.

    Generating a key offline for security reasons?

    Another feature I would love to see is deterministic wallets. Back up only backs up the deterministic seed. Every time you spend from an address, all bitcoins are spent, with part going to the person receiving, and the change part going into a new address. The only empty address gets archived and is unused, but can be restored if needed.

    Those should be covered with implementing BIP32. Work is on the way, but there is still much to do. Bitcoinj already has the algorithm, but somebody's got to do the wallet integration. And then of course, the UI needs to be adapted.
Page 19
Viewing Page: 20