<h2>TL;DR:</h2>

<p>It seems that <code>Bitcoin Wallet for Android</code> incorrectly labels <code>nLockTime</code> transactions as <code>OptInRBF</code> due to a bug in <code>bitcoinj</code>. The <a href="https://github.com/bitcoinj/bitcoinj/issues/1225" rel="nofollow noreferrer">issue has been reported</a>. You don't need to do anything.</p>

<hr>

<p>Apparently, Bitcoin Wallet for Android recognized your transaction as <a href="https://bitcoincore.org/en/faq/optin_rbf/" rel="nofollow noreferrer"><code>OptInRBF</code></a> (as pointed out by the code you found). The warning you are seeing was only added to the app on <a href="https://github.com/bitcoin-wallet/bitcoin-wallet/commit/55eb0dd95dd839b5c869f61ef0b6b44e2f2ae796" rel="nofollow noreferrer">March 10th 2016</a>.</p>

<h2>What is OptInRBF?</h2>

<p><code>OptInRBF</code> 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 <strong>cannot create rbf transactions</strong>, yet. Wallets have to "opt-in" to send them.  </p>

<p>Replace-by-fee is a flag that can be set on transactions to communicate that one might want to change the transaction <strong>before it is included in a block</strong>. 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.<br>
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.  </p>

<h2>Where does the warning come from?</h2>

<p>Looking at the <a href="http://srv1.yogh.io/#tx:id:69a0d15abaae43f5e5e05d3c679b73986f9cd7f00add1c307e507754bf935d83" rel="nofollow noreferrer">raw data of the first transaction</a>, it turns out that the transaction's <code>sequence</code> number is indeed below max value: It shows <code>0xFEFFFFFF</code> while the maximum would be <code>0xFFFFFFFF</code>. The sequence with an <code>E</code> in second place is an unsigned <strong>little</strong> endian long for "one below maximum". This is the sequence of a <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012268.html" rel="nofollow noreferrer"><code>nLockTime</code> transaction</a>. </p>

<p><code>OptInRBF</code> have sequences that are smaller than the <code>nLockTime</code> sequence, i.e. <code>sequence &lt; MAX - 1</code>. Therefore, it appears that either <code>bitcoinj</code> or <code>Bitcoin Wallet for Android</code> misclassifies <code>nLockTime</code> transactions as <code>OptInRBF</code>. The problem is that <a href="https://github.com/bitcoin/bitcoin/pull/2340" rel="nofollow noreferrer">since Bitcoin Core 0.11</a> all transactions have an <code>nLockTime</code> sequence.</p>

<p>At first glance, the <a href="https://github.com/bitcoinj/bitcoinj/blob/becd8641c92817e85029ddd63d1f424cdd626278/core/src/main/java/org/bitcoinj/core/TransactionInput.java#L385" rel="nofollow noreferrer"><code>bitcoinj</code> code</a> that checks whether a transaction is <code>OptInRBF</code> seems fine: </p>

<pre><code>public boolean isOptInFullRBF() {
    return sequence &lt; NO_SEQUENCE - 1;
}
</code></pre>

<p>However, Java natively uses <a href="https://stackoverflow.com/questions/362384/are-integers-in-java-little-endian-or-big-endian">big endian format</a> instead of little endian format.<br>
&lt;speculation&gt;Therefore, there may be an issue with<code>NO_SEQUENCE - 1</code> which might resolve to <code>0xFFFFFFFE</code> and the <code>nLockTime</code> sequence <code>0xFEFFFFFF</code> read as big endian would appear much smaller than that and could therefore be labeled as <code>OptInRBF</code>.&lt;/speculation&gt;<sup>1</sup></p>

<p>I've reported the <a href="https://github.com/bitcoinj/bitcoinj/issues/1225" rel="nofollow noreferrer">issue</a> and am trying to craft a <a href="https://github.com/bitcoinj/bitcoinj/pull/1226" rel="nofollow noreferrer">bug fix</a>.</p>

<hr>

<p><sup>1</sup> It turns out that my speculation was incorrect. <code>BitcoinJ</code> and <code>Bitcoin Wallet for Android</code> handle transactions with the <code>nLockTime</code> 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.</p>

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

CC BY-SA 3.0
2016-03-23T12:04:44.550Z
Just to clarify this, bitcoinj (and Bitcoin Wallet) is indeed using little endian to parse this field.
Andreas
CC BY-SA 3.0
2016-03-23T13:35:38.590Z
@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
CC BY-SA 3.0
2017-07-15T12:43:58.053Z
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
CC BY-SA 3.0
2017-07-15T16:53:01.950Z
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
CC BY-SA 3.0
2016-03-16T11:34:47.820Z
2016-03-23T13:33:42.580Z
2017-05-23T12:34:59.703Z
Murch
<p>I am running <code>Bitcoin Core v0.11.0.0-gd26f951 (64-bit)</code> at home on Ubuntu, and have installed the <code>Bitcoin Wallet for Android</code> on my phone. I sent two transactions from home to my phone: <a href="https://blockexplorer.com/tx/168ad57b8f99d4e966249d5f6332805e13e53c7e579f2e17fca22fe9df0430cd" rel="nofollow">First</a>, <a href="https://blockexplorer.com/tx/69a0d15abaae43f5e5e05d3c679b73986f9cd7f00add1c307e507754bf935d83" rel="nofollow">Second</a>. 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.</p>

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

<pre><code> This payment was delayed because the sender used an insecure transaction type.
</code></pre>

<p>underneath both transactions. What does that mean?</p>

<p>I googled the phrase and got exactly one hit, in <a href="https://raw.githubusercontent.com/schildbach/bitcoin-wallet/master/wallet/res/values/strings.xml" rel="nofollow">a resource bundle that is part of the code for the bitcoin-wallet project on github</a>, which appears to be the Android app. The corresponding key is <code>transaction_row_message_received_rbf</code>, which generated no hits at all.</p>

<p><strong>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?</strong></p>

CC BY-SA 3.0
2016-03-17T10:03:52.553Z
I've edited question and answer to include all information from the numerous comments and removed the comments to reduce the visual clutter.
Murch
CC BY-SA 3.0
2016-03-21T16:53:18.033Z
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
CC BY-SA 3.0
2016-03-21T17:01:18.573Z
@Murch I believe so, although I find the process of determining the transaction ID slightly mysterious. The Bitcoin Wallet for Android doesn't show them, so I just searched for the destination address on blockchain.info. Assuming Bitcoin Core has logged the IDs I can double check for you when I get home.
Pepijn Schmitz
CC BY-SA 3.0
2016-03-21T17:35:04.757Z
That would be marvelous. If you need help, please just post here. I could assist when I get back later.
Murch
CC BY-SA 3.0
2016-03-21T20:29:34.907Z
@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: https://drive.google.com/file/d/0B3HeHhx785UOWmdSdUo0SHpIcFU/view?usp=sharing
Pepijn Schmitz
CC BY-SA 3.0
2016-03-21T22:24:20.077Z
Thanks, I've added your information and the screenshot to the bug report.
Murch
CC BY-SA 3.0
2016-03-21T22:27:19.493Z
@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
CC BY-SA 3.0
2016-03-22T13:44:55.323Z
@AndreasSchildbach Sure. Where shall I send it?
Pepijn Schmitz
CC BY-SA 3.0
2016-03-23T12:03:23.870Z
To the pre-populated e-mail address.
Andreas
CC BY-SA 3.0
2016-03-23T12:30:16.530Z
@AndreasSchildbach Done!
Pepijn Schmitz
CC BY-SA 3.0
2016-03-23T17:09:50.183Z
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 https://github.com/bitcoin-wallet/bitcoin-wallet/releases
Andreas
CC BY-SA 3.0
2016-03-23T17:11:39.883Z
@AndreasSchildbach Thanks! Will updating also fix the transactions already in the wallet, or just future ones?
Pepijn Schmitz
CC BY-SA 3.0
2016-03-24T14:33:40.913Z
@PepijnSchmitz It should fix your current wallet as well. It would be nice if you could confirm this is indeed the case.
Andreas
CC BY-SA 3.0
2016-03-24T18:24:09.083Z
@AndreasSchildbach I installed the new version of the app, and it did indeed fix the warnings! Thanks!
Pepijn Schmitz
<bitcoin-core><transaction-verification><bitcoin-wallet-app><sequence><replace-by-fee>
What is an "insecure transaction type", as mentioned by Bitcoin Wallet for Android?
Pepijn Schmitz
# What is an "insecure transaction type", as mentioned by Bitcoin Wallet for Android?

(Asked by: username_0 on 2016-03-16)

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](https://blockexplorer.com/tx/168ad57b8f99d4e966249d5f6332805e13e53c7e579f2e17fca22fe9df0430cd), [Second](https://blockexplorer.com/tx/69a0d15abaae43f5e5e05d3c679b73986f9cd7f00add1c307e507754bf935d83). 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](https://raw.githubusercontent.com/schildbach/bitcoin-wallet/master/wallet/res/values/strings.xml), 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?**

**Tags:** bitcoin-core, transaction-verification, bitcoin-wallet-app, sequence, replace-by-fee

> **Comments:**
> **username_1**: I've edited question and answer to include all information from the numerous comments and removed the comments to reduce the visual clutter.  
> **username_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.  
> **username_0**: @username_1 I believe so, although I find the process of determining the transaction ID slightly mysterious. The Bitcoin Wallet for Android doesn't show them, so I just searched for the destination address on blockchain.info. Assuming Bitcoin Core has logged the IDs I can double check for you when I get home.  
> **username_1**: That would be marvelous. If you need help, please just post here. I could assist when I get back later.  
> **username_0**: @username_1 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: https://drive.google.com/file/d/0B3HeHhx785UOWmdSdUo0SHpIcFU/view?usp=sharing  
> **username_1**: Thanks, I've added your information and the screenshot to the bug report.  
> **username_2**: @username_0 Hi username_0, 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?  
> **username_0**: @AndreasSchildbach Sure. Where shall I send it?  
> **username_2**: To the pre-populated e-mail address.  
> **username_0**: @AndreasSchildbach Done!  
> **username_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 https://github.com/bitcoin-wallet/bitcoin-wallet/releases  
> **username_0**: @AndreasSchildbach Thanks! Will updating also fix the transactions already in the wallet, or just future ones?  
> **username_2**: @username_0 It should fix your current wallet as well. It would be nice if you could confirm this is indeed the case.  
> **username_0**: @AndreasSchildbach I installed the new version of the app, and it did indeed fix the warnings! Thanks!  

---

## 1 answers

### Answer by username_1 on 2016-03-16. Score: 4 | Accepted answer

## 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](https://github.com/bitcoinj/bitcoinj/issues/1225). You don't need to do anything.

---

Apparently, Bitcoin Wallet for Android recognized your transaction as [`OptInRBF`](https://bitcoincore.org/en/faq/optin_rbf/) (as pointed out by the code you found). The warning you are seeing was only added to the app on [March 10th 2016](https://github.com/bitcoin-wallet/bitcoin-wallet/commit/55eb0dd95dd839b5c869f61ef0b6b44e2f2ae796).

## 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](http://srv1.yogh.io/#tx:id:69a0d15abaae43f5e5e05d3c679b73986f9cd7f00add1c307e507754bf935d83), 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](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012268.html).

`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](https://github.com/bitcoin/bitcoin/pull/2340) all transactions have an `nLockTime` sequence.

At first glance, the [`bitcoinj` code](https://github.com/bitcoinj/bitcoinj/blob/becd8641c92817e85029ddd63d1f424cdd626278/core/src/main/java/org/bitcoinj/core/TransactionInput.java#L385) that checks whether a transaction is `OptInRBF` seems fine:

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

```

However, Java natively uses [big endian format](https://stackoverflow.com/questions/362384/are-integers-in-java-little-endian-or-big-endian) instead of little endian format.  
<speculation>Therefore, there may be an issue with`NO_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](https://github.com/bitcoinj/bitcoinj/issues/1225) and am trying to craft a [bug fix](https://github.com/bitcoinj/bitcoinj/pull/1226).

---

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 username_0, Gregory Sanders, username_2 Schildbach, and Wladimir van der Laan for help in figuring this out.

> **Comments:**
> **username_2**: Just to clarify this, bitcoinj (and Bitcoin Wallet) is indeed using little endian to parse this field.  
> **username_1**: @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. ;)  
> **username_3**: 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.  
> **username_1**: Hi @username_3 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.  

---

