Topic: Mycelium Bitcoin Wallet - page 111. (Read 586402 times)

piuk very seldomly responds.
My guess is that they go for a happy-go-lucky approach. If you search for stuck transactions and blockchain.info you get quite a few hits.

sounds like a bug to me. the fees should not be that high. we will try to reproduce it, but i don't expect a fix extremely soon (realistically, i'd work on that week 20.1-24.1) as a workaround, i'd recommend importing the key  to bitcoin-qt and consolidating the funds there.

Bug report:

When attempting to send from this address: https://blockchain.info/address/1K3bMZ7SvkzoGZTYD5EpYPKbN8PPQKqidG

which currently contains 2.48345024 BTC
and hitting the "max" button to send everything
it will only allow me to send 1.91515024 BTC

Any attempt to enter any larger amount will be denied with "insufficient funds to pay fee".

This address contains only a dozen outputs and a fee of 0.5683 BTC (over 400 Euro!) seems a bit high to me.

Edit: is it maybe the unusual pay-to-pubkey format of some of the unspent outputs? These were generated by Schildbach when It moved coins internally between 2 addresses (this is a key that was formerly used in my Schildbach wallet and was imported into Mycelium). If this is the case then you need to fix it so that it can use these types of outputs as transaction inputs. You will need a different type of signature script for these inputs, only the signature and not the pubkey because the pubkey will come from the output script, see wiki: https://en.bitcoin.it/wiki/Script#Standard_Generation_Transaction_.28pay-to-pubkey.29

Edit2: This will most likely happen more often when people start importing keys from Schildbach. These pay-to-pubkey transactions are generated by Schildbach when it does its emergency transactions, when funds are sent to an old address that was flagged as insecure (due to the Android bug) it will immediately sweep the funds into a new secure address and it will use pay-to-pubkey for it. All these pay-to-pubkey transactions you can see arriving in my above address result from this.

I wonder if you could get light sensitive paper and lay the phone upside-down on top of it for a few minutes

I have printed the backup directly from the phone before.

Feature request:

If the wallet has multiple keys (addresses) and they have labels then please show the label of the receiving address in the transaction history instead of the sending address. The sending addresses are pretty much meaningless (to me at least and I guess to most other people too), I would rather like to see which of my own addresses has just received a payment. Currently there is no way to determine that information easily, even if I select the transaction details from the menu it won't show me the label, it will only show me the address (which I can't remember, that's why I have given them names in the first place).

Schildbach wallet suffers from the same problem (it has address labels but doesn't actually use them for anything and its author doesn't seem to be interested in fixing it), that's why I moved 5 Keys from Schildbach to Mycelium today, hoping it would work as expected but now I'm a little bit disappointed to see the exact same problem here :-(

Can you ask how blockchain.info does it?

Correct. The a relaying node (or miner for that matter) will regard another transaction using the same inputs as a double spend. The transaction has to get removed from the memory pool of receiving nodes before you can send out a version with a higher fee using some of the same inputs. This happens naturally over time (as nodes get rebooted) but it is hard to tell when that will be. So basically some of your inputs are stuck.

(real) Transaction replacement was part of the original Bitcoin protocol, but was disabled pretty early on (if it was ever fully enabled).

Ahh, yes, the payment protocol. We cannot really rely on it right now as it is not really used much yet. Going forward this is likely to change.

Is it so easy to scrap a tx? If it's in everyones mem-pool, would it likely get replaced by a double-spend one with a fee?

Where the merchant requests the transaction, the transaction is signed by the sender and transferred to the merchant, and the merchant verifies it before broadcasting it to the network. Thus the merchant is able to demand a certain custom sized fee, and decline a transaction if the fee they want is not included.
Regarding zero fees, why not do what blockchain.info does, and allow zero fee transactions, and if they don't get confirmed after 24 hours, scrap the transaction and make the coins spendable again.

I support keeping the mandatory minimum 0.0001 fee. There are plenty or reasons for it to stay, and it's worth it to maintain the simplicity of the app.



Nice!



The "backup missing" message may look annoying, but I think it makes sense to not change the requirements for removing it.

The "backup missing" message is shown as long as you have a private key which was created by the wallet and which hasn't been backed up with verification.
Private keys imported (e.g. from paper) are verified by default, as you have proven to have an external source (backup) of the key. One way to get around this is to create a private key by external means and import it to the wallet, and then delete the automatically generated initial key.

You don't have to print the PDF. You can scan it from the display of your computer.
The reason for verifying is that you may have made a mistake when you made the backup.

• The PDF send to a wrong email address, or you accidentally deleted it before printing ...
• The password not written down correctly/readable

A backup that does not work is worse than no backup at all, as you think you are good.

More coins have been lost due to lack of backups than due to theft. We really want to help users not loosing coins.

Message signing is in the works.

I am not certain what you mean by "merchant services options".
In the fee space bitcoin-qt 0.9 will have some changes for getting a "fee market" going, which will calculate fees dynamically depending on fees paid in previous blocks. We will implement something along those lines. Here are some of my thoughts on this topic: https://bitcointalksearch.org/topic/to-fee-or-not-to-fee-166302

The thing is that your transaction may not only "get somewhat delayed", it may never confirm at all. By paying 0.0001 for each 1000 bytes of transaction size (round up) it stays above the minimum relay fee required by nodes relaying the transaction to miners. Those are the rules of the network.
If we don't follow those rules users will experience transactions getting stuck. "freeing" your coins after that can be a nightmare, there are many threads on this forum on this topic. This will hit us (the developers) with a slew of angry users, as they will blame the wallet, and I really hate having angry users.

Fees in Bitcoin are quite complex and most users who consider themselves experts do not understand how it works.

All that said there is something we can do. The rules of the relaying nodes are not there to guarantee the miner some mining profit. The rules are there to limit transaction spam... a DOS attack filter, that prevents someone to send transactions to himself indefinitely, filling up the memory pool of relaying nodes. When the relay rules were introduced a portion of the memory pool / block size was reserved for what is called priority transactions. In short a transaction gets a priority according to the "age" of its inputs. If the "age" is sufficiently "old" (details here). Nodes will relay a priority transaction with a zero fee. Relaying does not guarantee inclusion in a block, and if the network continues to grow without the 1 MB block limit rising (or some other technical advancement) then the fees are bound to rise above the minimum relay fee.

Until now Mycelium has not considered zero fee high priority transactions. Something to work on.

Is there a way to get rid of the "backup missing" message? Why do you need to print off the PDF and then scan it in to verify? I don't want to make a print of it.

I second this. Sometimes I just want to move funds between my own accounts. Besides, with merchant services options coming out soon, you guys are having to work on custom set fees, anyway, right?...

I totally get your point.

Nonetheless, can you please (only in Expert mode, and perhaps with the information from your quote above as warning) add the possibility to customize the fee? How about: in Export mode by default still use 0.1 mBTC per 1000 bytes, but make it editable, and mention "recommended fee = xxx" in the edit fee screen/popup.

There are many occasions where I really don't care if a tx gets somewhat delayed or not (when transferring funds to myself, for example) and in Expert mode, one can be assumed to understand the difference.

Any updates on message signing with mycelium? copy/paste buttons on the gui would be handy too (for message signing, and generally copying addresses)

If I wasn't fully booked I'd probably jump on this offer. Couple months of Vienna working on a bitcoin wallet sounds nice.

It's good to hear you're on BIP32 integration.

I hope you will also consider integrating import of an extended public key into the address book so we can use that for recurring payments as described in this use case.