5

I am running Bitcoin Core v0.11.0.0-gd26f951 (64-bit) at home on Ubuntu, and have installed the Bitcoin Wallet for Android on my phone. I sent two transactions from home to my phone: First, Second. One had a very low fee and took days, so I sent another one with a slightly higher fee which took only minutes. Both arrived though, and have almost two thousand confirmations by now and show green in the app.

The Bitcoin app now (I first noticed it today and I don't think it initially said it) says

 This payment was delayed because the sender used an insecure transaction type.

underneath both transactions. What does that mean?

I googled the phrase and got exactly one hit, in a resource bundle that is part of the code for the bitcoin-wallet project on github, which appears to be the Android app. The corresponding key is transaction_row_message_received_rbf, which generated no hits at all.

Can anyone tell me what this "insecure transaction type" could be, and why Bitcoin-Qt would be using it? Do I need to prevent it, and if so how do I do so?

  • 1
    I've edited question and answer to include all information from the numerous comments and removed the comments to reduce the visual clutter. – Murch Mar 17 '16 at 10:03
  • 1
    I've been in touch with the maintainer of the Bitcoin Wallet for Android and BitcoinJ. Just to confirm, the two transactions you posted in a comment here and I have edited into your question are in fact the ones that show up as "insecure transaction type"? The maintainer could not reproduce the problem, so we are just checking up on our assumptions. – Murch Mar 21 '16 at 16:53
  • 1
    @Murch I verified that those transaction IDs are indeed correct, although Bitcoin Core appends a "-000" to both of them, I don't know what that means. And here is a screenshot of the app showing the message: drive.google.com/file/d/0B3HeHhx785UOWmdSdUo0SHpIcFU/… – Pepijn Schmitz Mar 21 '16 at 20:29
  • 1
    @PepijnSchmitz Hi Pepijn, I'm currently working on the bug you're experiencing. Could you do me a favor and use the in-app bug reporting facility (Options > Settings > Diagnostics > Report issue) to send us the dump of your wallet? – Andreas Schildbach Mar 21 '16 at 22:27
  • 2
    Thanks to your dump, I was able to reproduce the issue and fix it. It wasn't in how the data was parsed from the P2P network, rather there was a bug in the protobuf serialization of the sequence number field. An updated version of Bitcoin Wallet (v4.49) is rolling out. The queue can be skipped by downloading from github.com/bitcoin-wallet/bitcoin-wallet/releases – Andreas Schildbach Mar 23 '16 at 17:09
4

TL;DR:

It seems that Bitcoin Wallet for Android incorrectly labels nLockTime transactions as OptInRBF due to a bug in bitcoinj. The issue has been reported. You don't need to do anything.


Apparently, Bitcoin Wallet for Android recognized your transaction as OptInRBF (as pointed out by the code you found). The warning you are seeing was only added to the app on March 10th 2016.

What is OptInRBF?

OptInRBF is short for "Opt-in replace-by-fee", which was added to Bitcoin Core in 0.12.0. The new version allows Bitcoin Core to receive and correctly treat replace-by-fee transactions. However, Bitcoin Core cannot create rbf transactions, yet. Wallets have to "opt-in" to send them.

Replace-by-fee is a flag that can be set on transactions to communicate that one might want to change the transaction before it is included in a block. Therefore, such transactions shouldn't be considered reliable until they get their first confirmation. After they are included in a block, they are just as safe as any other transaction.
Mining pools that support rbf will allow a newer version of the transaction to replace the older, especially if the newer transaction pays a higher fee. This is for example useful for increasing the fee on a transaction when it is stuck, or to combine multiple transactions into one when you decide to send another transaction before a previous is confirmed.

Where does the warning come from?

Looking at the raw data of the first transaction, it turns out that the transaction's sequence number is indeed below max value: It shows 0xFEFFFFFF while the maximum would be 0xFFFFFFFF. The sequence with an E in second place is an unsigned little endian long for "one below maximum". This is the sequence of a nLockTime transaction.

OptInRBF have sequences that are smaller than the nLockTime sequence, i.e. sequence < MAX - 1. Therefore, it appears that either bitcoinj or Bitcoin Wallet for Android misclassifies nLockTime transactions as OptInRBF. The problem is that since Bitcoin Core 0.11 all transactions have an nLockTime sequence.

At first glance, the bitcoinj code that checks whether a transaction is OptInRBF seems fine:

public boolean isOptInFullRBF() {
    return sequence < NO_SEQUENCE - 1;
}

However, Java natively uses big endian format instead of little endian format.
<speculation>Therefore, there may be an issue withNO_SEQUENCE - 1 which might resolve to 0xFFFFFFFE and the nLockTime sequence 0xFEFFFFFF read as big endian would appear much smaller than that and could therefore be labeled as OptInRBF.</speculation>1

I've reported the issue and am trying to craft a bug fix.


1 It turns out that my speculation was incorrect. BitcoinJ and Bitcoin Wallet for Android handle transactions with the nLockTime sequence fine, and parse it using little endian format as required. So far, the maintainer was unable to reproduce the described issue with the provided transactions (instead they were shown correctly without warning). Therefore, the reason for the warning's appearance is still unknown.

Thank you to Pepijn Schmitz, Gregory Sanders, Andreas Schildbach, and Wladimir van der Laan for help in figuring this out.

  • Just to clarify this, bitcoinj (and Bitcoin Wallet) is indeed using little endian to parse this field. – Andreas Schildbach Mar 23 '16 at 12:04
  • @AndreasSchildbach: Thanks, I've updated my answer to reflect the current understanding of the issue. Sorry for jumping to that conclusion, it just seemed to be such a good explanation. ;) – Murch Mar 23 '16 at 13:35
  • Any explanation why the message would appear on a multisig transaction that used OptInRBF but not nLocktime, even after >10 confirmations? This is on latest version of Bitcoin Wallet for Android (v5.25). Asking here because it's one of the few sensible hits when searching for the message, and possibly related. – AronVanAmmers Jul 15 '17 at 12:43
  • Hi @AronVanAmmers that sounds interesting. Could you please create a new question so we can properly address your topic? If you can please provide as much information as possible, e.g. link to the transaction on a blockexplorer that would be great. – Murch Jul 15 '17 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.