What is an "insecure transaction type", as mentioned by Bitcoin Wallet for Android? 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?
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 &lt; 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 &lt; NO_SEQUENCE - 1;
}


However, Java natively uses big endian format instead of little endian format.
&lt;speculation&gt;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.&lt;/speculation&gt;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.