Bitcoin Wallet for Android

[Mike Hearn]

Unfortunately both of those features, whilst they make total sense, are a bit tricky to do.

1) Fees are currently hard-coded by the Bitcoin network. It will take a global upgrade to change them Gavin is working on code that will make fees float, but it's complex and not done yet. I wouldn't anticipate that happens until maybe March or April of next year. I'm hoping he will choose to do an intermediate 0.8.x release that drops the hard-coded fee again before then.

2) The P2P network cannot provide the data required to import money from arbitrary private keys. Andreas could "cheat" by relying on blockchain.info, but that's not very decentralised. Adding support to the P2P network is possible, but nobody is working on it at the moment.

For now, for (2), the simplest approach is to use the blockchain.info app and then send the money onwards to wherever you want it to reside.

[1713966649]

1713966649

[1713966649]

1713966649

[1713966649]

1713966649

[1713966649]

1713966649

[1713966649]

1713966649

[1713966649]

1713966649

[2weiX]

Unfortunately both of those features, whilst they make total sense, are a bit tricky to do.

1) Fees are currently hard-coded by the Bitcoin network. It will take a global upgrade to change them Gavin is working on code that will make fees float, but it's complex and not done yet. I wouldn't anticipate that happens until maybe March or April of next year. I'm hoping he will choose to do an intermediate 0.8.x release that drops the hard-coded fee again before then.

2) The P2P network cannot provide the data required to import money from arbitrary private keys. Andreas could "cheat" by relying on blockchain.info, but that's not very decentralised. Adding support to the P2P network is possible, but nobody is working on it at the moment.

For now, for (2), the simplest approach is to use the blockchain.info app and then send the money onwards to wherever you want it to reside.

1) If that is so, how come other applications let me set the fee arbitrarily? If what you're saying is true, why is there ever such a thing as a zero-fee transaction?

2) OK, I have to take that at face value since I have no idea how Andreas' app works internally and how that's different from anything else. I haven't seen that feature in the blockchain app either, btw.

[Mike Hearn]

1) If that is so, how come other applications let me set the fee arbitrarily? If what you're saying is true, why is there ever such a thing as a zero-fee transaction?

You can set it to either zero, or the current fee level the app uses, or higher. However, setting it higher does not guarantee faster confirmation - often it will be pointless. Setting it to zero can result in confirmation delays of greater than 24 hours at the moment, OR failure to relay. Setting it lower than the current level but above zero can result in the transaction failing to relay.

So it's complicated. If users were able to set the fee themselves, very likely many people would either waste money or create transactions that never confirm.

2) OK, I have to take that at face value since I have no idea how Andreas' app works internally and how that's different from anything else. I haven't seen that feature in the blockchain app either, btw.

I'm pretty sure the website can do it at least. The problem with importing a private key is you need an index into the UTXO set. Currently P2P nodes don't calculate such an index. Block explorers do, however. So to make that feature work with just the P2P network we'd need a way for bitcoind/bitcoin-qt nodes to calculate the index and define a p2p protocol extension to query it, and because it's expensive (in terms of cpu/disk time) not all nodes would want to do it, so some would have to opt in and then we'd need a way to find them like by using addr service bits.

It can be done. But it's not a high priority. Storing private keys in qrcodes is a bit odd anyway. Outside of physical bitcoins it's normally never a good idea.

[Andreas Schildbach]

Also, importing private keys into your wallet is quite risky and should be discouraged. This is especially true if they were created by a third party (Casascius) and in the hands of several intermediates (merchants, postal services and so on). Don't do that!

The only usecase I can imagine the app to support is swiping the keys (to your wallet). But still, it's got the problem of no P2P support for that usecase like Mike outlined.

[Andreas Schildbach]

I just read about Casascius coins and their "mini private key format" and its a disaster: Their private keys have a lot less entrophy by design.

[Dabs]

I import private keys all the time. But I use bitcoin-qt when I do that.

[Rassah]

You can import private keys using Mycelium for Android, but it's not a true P2P app.

[hgmichna]

You can import private keys using Mycelium for Android, but it's not a true P2P app.

This statement needs a bit more qualification. While it is formally true, Mycelium uses central servers only to obtain blockchain information. Everything that is critical to its security is done in peer-to-peer fashion. Private keys are kept in Mycelium's local, private data storage, so in terms of security it is no different from a peer-to-peer app.

To me this looks like an interesting compromise. The app is lightweight and functions without any delay, yet it retains as much security as is possible on Android, which is more than any program could have on a Windows computer, for example.

The downside is that it depends on its servers. If they all went down, Mycelium would cease to function. Take your pick.

[Andreas Schildbach]

You can import private keys using Mycelium for Android, but it's not a true P2P app.

While it is formally true, Mycelium uses central servers only to obtain blockchain information. Everything that is critical to its security is done in peer-to-peer fashion. Private keys are kept in Mycelium's local, private data storage, so in terms of security it is no different from a peer-to-peer app.

The blockchain is very security critical. By relying on a centralized server for that you lose quite some security and reliability compared to a true p2p app imho.

[apetersson]

The downside is that it depends on its servers. If they all went down, Mycelium would cease to function. Take your pick.

Right now, if the Mycelium servers would go down, you can import a key into any other client easily. The quickest way would be to export a single key in SIPA format (as qr code, or via clipboard) and import it into bitcoin-qt or any other client. so your money is not "locked" like with a web-wallet or a wallet where an encrypted wallet is stored in the cloud. it is all on YOUR phone and in YOUR backups.

Also, if you need to decrypt the 2-factor backup key without a Smartphone, the code is Apache Licensed at https://raw.github.com/mycelium-com/wallet/master/public/bitlib/src/main/java/com/mrd/bitlib/crypto/MrdExport.java and a textual decription of the algorithm is in the pdf.

[Jan]

Both models have their pros and cons. Some prefer one, some prefer the other.  We need as much diversity in bitcoinland as we can get. Not everyone wants the chicken to taste the same.

[Andreas Schildbach]

Both models have their pros and cons.

What's the pro of relying on a proprietary centralized service? The only pro I can think of is support for importing private keys, but that's a dangerous operation anyway.

[Jan]

Both models have their pros and cons.

What's the pro of relying on a proprietary centralized service? The only pro I can think of is support for importing private keys, but that's a dangerous operation anyway.

Andreas, I am really not trying to pick a fight here. But let me answer your questions.
Importing/exporting private keys is crucial for giving people the freedom to choose another wallet and doing backup/restore. Importing to memory is crucial for cold storage spending, which is quite handy for secure offline storage and swiping a paper slip from a Bitcoin ATM.
We are both relying on proprietary centralized servers to get exchange rates. Mycelium also relies on that to get unspent outputs and transaction history

[Andreas Schildbach]

Andreas, I am really not trying to pick a fight here. But let me answer your questions.

I just wanted to know the pros. I think the question isn't answered. What's the pro of relying on a centralized service for getting unspent outputs and transaction history?

You're right about the exchange rates. To my knowledge, atm its not possible to get them in a decentralized way.

[Jan]

Andreas, I am really not trying to pick a fight here. But let me answer your questions.

I just wanted to know the pros. I think the question isn't answered. What's the pro of relying on a centralized service for getting unspent outputs and transaction history?

You're right about the exchange rates. To my knowledge, atm its not possible to get them in a decentralized way.

hmm.. I believe I wrote that in my last answer:

Both models have their pros and cons.

What's the pro of relying on a proprietary centralized service? The only pro I can think of is support for importing private keys, but that's a dangerous operation anyway.

Andreas, I am really not trying to pick a fight here. But let me answer your questions.
Importing/exporting private keys is crucial for giving people the freedom to choose another wallet and doing backup/restore. Importing to memory is crucial for cold storage spending, which is quite handy for secure offline storage and swiping a paper slip from a Bitcoin ATM.
We are both relying on proprietary centralized servers to get exchange rates. Mycelium also relies on that to get unspent outputs and transaction history

So to rephrase:
1. Restoring your device and BAM, you are good to go
2. Cold storage spending from a paper backup.
3. Cold storage spending from a Bitcoin ATM paper slip.

Bitcoin Wallet for Android has other benefits, and I really really believe that we need as much diversity as we can get. One size does not fit all.

[apetersson]

I just wanted to know the pros. I think the question isn't answered. What's the pro of relying on a centralized service for getting unspent outputs and transaction history?

This is your thread so i really hate to turn this into an advertisement for our software, but since you insist i cannot refuse

Well, syncing is much faster, basically instant, if you don't need to scan the blockchain. It would be nice if we could get that from P2P nodes, but since this is not possible we have to be pragmatic.

Also, the amount of possible error states is simpler. In our code, we can assume cooperating peers (so no half-open tcp connections, stalling connections, etc). Syncing once and closing the connection immediately afterwards is much friendlier to the battery than maintaining a background process.

That said, i think it is possible that we can achieve "best of both worlds" by implementing a P2P network where you can efficiently query an UTXO-set in near-constant time, with POW, as outlined here: https://bitcointalk.org/index.php?topic=88208.0. But since this is not implemented yet, it is not an option so far.

[2weiX]

so mycelium would, theoretically, be able to provide a simple "enter and swipe" import function for casascius coins?

[Jan]

so mycelium would, theoretically, be able to provide a simple "enter and swipe" import function for casascius coins?

It is already there. I would prefer not to clutter this thread with Mycelium stuff. You have to put the string into the clipboard for this to work. (This means trusting the other apps on your device) and then go to Cold Storage and click the "Clipboard" button, and so forth.

[Mike Hearn]

Requesting UTXOs from the P2P network would not require any complicated new protocols because it doesn't need to be authenticated. A remote node can already lie-through-omission due to the Bloom filtering and make you think an output is unspent when really it isn't. A simple query/response protocol would thus not have any different security to today. The complicated part is that not every node operator will want to provide this service, as it's expensive and not needed for normal operation, so we'd need addr handling/peer discovery to work better first.

[Andreas Schildbach]

Well, syncing is much faster, basically instant, if you don't need to scan the blockchain. It would be nice if we could get that from P2P nodes, but since this is not possible we have to be pragmatic.

Well, you can get that from the p2p network. Use checkpoints and bloom filters. Both MultiBit and Bitcoin Wallet have proven that this allows for "basically instant" startup.

Also, the amount of possible error states is simpler. In our code, we can assume cooperating peers (so no half-open tcp connections, stalling connections, etc). Syncing once and closing the connection immediately afterwards is much friendlier to the battery than maintaining a background process.

Agreed. A single request/response is simpler than maintaining a node in a p2p network. However, that problem has been solved.

I believe if there is any significant difference in battery drain its mainly because Bitcoin Wallet can also receive coins (and notify you) in the background, while afaik Mycelium doesn't do that yet (why?).

That said, i think it is possible that we can achieve "best of both worlds" by implementing a P2P network where you can efficiently query an UTXO-set in near-constant time, with POW, as outlined here: https://bitcointalk.org/index.php?topic=88208.0.

I agree. Improving the p2p protocol is exactly the path I'm striving for. See bloom filters, which were designed and implemented as a non-proprietary extension to the p2p protocol in early 2013.

And don't take me wrong. This is not a question of Mycelium vs. Bitcoin Wallet. This is a conflict between centralized and de-centralized. Bitcoin's main benefit is de-centralization, and I want to stick to this idea whereever possible. I agree with Jan that diversity is good for Bitcoin.