ln_init: deterministic channel IDs failure

[pinheadmz]

Error looks like this:

LNInit   - Waiting for 78 channel opens in mempool...
LNInit   - Confirmed 78 channel opens in block 300
LNInit   - Checking deterministic channel IDs in block...
LNInit   - Assertion failed
Traceback (most recent call last):
  File "/shared/archive.pyz/test_framework/test_framework.py", line 131, in main
    self.run_test()
  File "/shared/archive.pyz/ln_init.py", line 270, in run_test
    assert block_txs[ch["id"]["index"]] == ch["txid"], (
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Actual txid:ac3ee9267ff1bc1ba47fc48cf95e53c31ddfcc82163f718f5ea985b3b6dcf6e6
{'capacity': 1000000, 'id': {'block': 300, 'index': 3}, 'push_amt': 500000, 'source_policy': {'cltv_expiry_delta': 40, 'fee_base_msat': 0, 'fee_proportional_millionths': 2000, 'htlc_maximum_msat': 990000000, 'htlc_minimum_msat': 1000}, 'target': 'tank-0019-ln', 'target_policy': {'cltv_expiry_delta': 40, 'fee_base_msat': 0, 'fee_proportional_millionths': 750, 'htlc_maximum_msat': 990000000, 'htlc_minimum_msat': 1000}, 'source': 'tank-0018-ln', 'txid': '17c88fc3914742ef36cc0769eba9e935e76d44d527935e6629b35b21ff075d9e'}

Background: when we init a LN in warnet, we create each channel open TX with a decreasing fee rate, so we can predict where that TX will be in the block and therefore can predict the short channel ID which is just a series of integers block height || tx index || output index and we use this to make the warnet channel graph match the input JSON.

There is some kind of issue with the block in this example. One of the TXs got ordered incorrectly.

index in block	txid	fee	size (vbytes)	weight	actual rate	expected rate
1	cb57c0	0.00823914	164	658	5023.8	5001
2	85bd25	0.00823091	165	658	4988.4	4996
3	ac3ee9	0.00817324	164	656	4983.6	4961
4	17c88f	0.00822267	165	658	4983.4	4991

The issue is that 17c88f was supposed to be index 3 and ac3ee9 was supposed to be ... index 9! (not even close)

LNInit   - Sending channel open from tank-0018-ln -> tank-0019-ln with fee_rate=4991
LNInit   - Channel open tank-0018-ln -> tank-0019-ln
  outpoint=17c88fc3914742ef36cc0769eba9e935e76d44d527935e6629b35b21ff075d9e:0
  expected channel id: {'block': 300, 'index': 3}
...
LNInit   - Sending channel open from tank-0008-ln -> tank-0044-ln with fee_rate=4961
LNInit   - Channel open tank-0008-ln -> tank-0044-ln
  outpoint=ac3ee9267ff1bc1ba47fc48cf95e53c31ddfcc82163f718f5ea985b3b6dcf6e6:0
  expected channel id: {'block': 300, 'index': 9}

@cndolo as a short term temporary work around you can just disable the check that is failing in the scenario:

warnet/resources/scenarios/ln_init.py

Lines 263 to 273 in 7cb394e

	self.log.info("Checking deterministic channel IDs in block...")
	block = self.nodes[0].getblock(block_hash)
	block_txs = block["tx"]
	block_height = block["height"]
	for ch in channels:
	assert ch["txid"] != "N/A", f"Channel:{ch} did not receive txid"
	assert ch["id"]["block"] == block_height, f"Actual block:{block_height}\n{ch}"
	assert block_txs[ch["id"]["index"]] == ch["txid"], (
	f"Actual txid:{block_txs[ch['id']['index']]}\n{ch}"
	)
	self.log.info("👍")

This may mean that the channel policies applied to the graph in warnet are not a perfectly accurate match to the mainnet sample imported in the JSON

[pinheadmz]

long term fix will probably be to include less channels per block with wider target fee-rate spacing