Block generation skipping chained transactions

[kallewoof]

Describe the issue

Running elements regtest with transactions that are often chained together, elements is skipping some transactions in the mempool when generating a new block.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Start a regtest elements.
2. Make ten or so transactions which are chained together.
3. Check mempool
4. Generate 1 block
5. Check mempool

Expected behaviour

The mempool transactions should all go into the block as they all fit.

Actual behaviour

Some transactions which are chained with other mempool transactions are excluded.

What version of bitcoin-core are you using?

It's elements-core, but anyway -- I'm using elements 0.14.1.

Any extra information that might be useful in the debugging process.

$ ./elements-cli -regtest getrawmempool
[
  "940d3e626e22386f742f98e74a319170ee6a30fdd05acf2d77e13526a7ffccd6",
  "902370106157ddd9324f3bf61ef02ad7b9fd59d5a691a288ebf14c6a7fbfd2ba",
  "e9f42debda006e591959b6637a3ba95187faac1518ccad4d8d81b8539ba1a175",
  "5956a2f2c048ae98512e160a769aff0663e4ca56e2b5e62cc0fd66c0e9eced43",
  "9e602a7b745c0fd239e3b96fcb95dadd9a7e8db48ac68fbe605fa40d003c4707",
  "7cce894edd4de0e5ba1d664de3b2506f3c3259121ab2ede19d4bdaaf2f8a2228",
  "aca06d137a8a73531e619e92b43c73879658dc9581a8280cdb87b04c7d41de9e",
  "18e8409d21740819b66594ff3010d2401b1842220908e62ec308c1d86efdf7c6",
  "9096f63eac3e4b1304dedbff6bab1f298572c5ed46e1289c30b3e76721ae80bb",
  "d9a13360f80a1c3435b279d18d59c43fd66a14dcf7fd497516ef511424a2cd77",
  "bc1954dddc2312c406dd412d15fc8256f45e4aab2fedc7a7a73b8a4302e9063a"
]
$ ./elements-cli -regtest generate 1
[
  "269818b24650662ab986ac6843ff789dd0a183ac46edffa4dd9fce2b08f0887b"
]
$ ./elements-cli -regtest getrawmempool
[
  "aca06d137a8a73531e619e92b43c73879658dc9581a8280cdb87b04c7d41de9e",
  "18e8409d21740819b66594ff3010d2401b1842220908e62ec308c1d86efdf7c6",
  "9096f63eac3e4b1304dedbff6bab1f298572c5ed46e1289c30b3e76721ae80bb",
  "d9a13360f80a1c3435b279d18d59c43fd66a14dcf7fd497516ef511424a2cd77",
  "bc1954dddc2312c406dd412d15fc8256f45e4aab2fedc7a7a73b8a4302e9063a"
]
$ ./elements-cli -regtest getrawtransaction aca06d137a8a73531e619e92b43c73879658dc9581a8280cdb87b04c7d41de9e 1 | grep txid
  "txid": "aca06d137a8a73531e619e92b43c73879658dc9581a8280cdb87b04c7d41de9e",
      "txid": "e9f42debda006e591959b6637a3ba95187faac1518ccad4d8d81b8539ba1a175",
$ # e9f.. was in mempool and is now in the block
$ ./elements-cli -regtest getrawtransaction e9f42debda006e591959b6637a3ba95187faac1518ccad4d8d81b8539ba1a175 1 | grep txid
  "txid": "e9f42debda006e591959b6637a3ba95187faac1518ccad4d8d81b8539ba1a175",
      "txid": "23e8bcdc419a3159e89744650aad31120ea17a9417713a8bc5e76ca086e23f43",
      "txid": "edcdb69da02e10b110f722277cc340db8043f8ee2b665671845622ab76e95df5",
$ # none of the tx's e9f depended on where in the mempool

[instagibbs]

how were these chains created? Using a naive "send all coins to myself 20x and generate a block" seems to work on this end.

[kallewoof]

They were made using a rather naive implementation of coin select which I think is currently picking 0-conf first rather than picking from 1+conf. Beyond that, it's 100% standard stuff. One wallet sends to some other wallet. Other wallet uses the incoming utxo to send to another wallet, etc.

[kallewoof]

I will try to make something reproducible using elements-cli asap.

Edit: yeah, that was easier said than done. Elements (rightly) does not play well with 0-confs.

[instagibbs]

resolved #211