Question: Sending expired timelocked utxo as a taker?

[theborakompanioni]

Trying to attempt a collaborative transaction by sweeping a mixdepth with only a single expired fidelity bond utxo.

2022-09-27 07:16:47,547 [DEBUG]  cj amount = 123454661
2022-09-27 07:16:47,562 [INFO]  ABORT:Failed to source a commitment; this debugging information may help:

1: Utxos that passed age and size limits, but have been used too many times (see taker_utxo_retries in the config):
None
2: Utxos that have less than 5 confirmations:
None
3: Utxos that were not at least 20% of the size of the coinjoin amount 123454661
None
***
Utxos that appeared in item 1 cannot be used again.
Utxos only in item 2 can be used by waiting for more confirmations, (set by the value of taker_utxo_age).
Utxos only in item 3 are not big enough for this coinjoin transaction, set by the value of taker_utxo_amtpercent.
If you cannot source a utxo from your spending mixdepth according to these rules, use the tool add-utxo.py to source a utxo from another mixdepth or a utxo external to your joinmarket wallet. Read the help with 'python add-utxo.py --help'

***
For reference, here are the utxos in your wallet:

mixdepth 0:
    52eab1cf0741eb1c427674220785f7c9a4d9fb7e6028f946d32f7010f30c63d1:0 - path: m/84'/1'/0'/2/25:1643673600, address: bcrt1qwtqrcjhrk9aah6pf54s65dhafrhepsaj33cy8hr9dmt7dlgdddhskx9h37, value: 123456356

When trying the same sweep with an additional (non-timelocked) utxo in the same mixdepth, it errors with -26 non-mandatory-script-verify-flag (Locktime requirement not satisfied):

2022-09-29 07:22:56,524 [DEBUG]  cj amount = 234565865
2022-09-29 07:22:56,542 [DEBUG]  Generated PoDLE: {'P': '03199ff0c0981f2b55cfacf262305ba2fadf01ad25a626234474fdcd3379062168',
 'P2': '02e65d9ec1dc7b51d7d9511422499998b68d1a47bf439804f0212338bceca52196',
 'commit': '067c112563ef04a3c581bb05140c4834314a47c788d1d7c6b00072aedd964962',
 'e': '918bc34203f6c1bb7b994d36a84bedcd83f0834d40ee19d3a6f3ca5116fa3b73',
 'sig': '8878a8e2a6abb455e048c8476c40eaaa050bce9d899a9ff1fa034c6619ca37b8',
 'used': False,
 'utxo': '9ff4b7fd14f696ae8980cd5d26edefabd79667423c5b94e665bed85480640b91:0'}
2022-09-29 07:22:56,542 [INFO]  INFO:Commitment sourced OK
2022-09-29 07:22:56,544 [DEBUG]  >>privmsg on onion-network: nick=J56YHpFBAW58o5DA cmd=fill msg=0 234565865 6ce89e2aebf40b8efdda3c99e8e03035edcb9b213f18878182d1bcf8534e0523 P067c112563ef04a3c581bb05140c4834314a47c788d1d7c6b00072aedd964962 037f8542be1724e9e9ebe52fe6f6b44490630435cc3a65f39c17d1db85331d754d MEQCIFImLI8OdRZuE3XGFBOOSc1W2/HXk7HHHqCl6WuU8QQIAiB7E/1Q++oJxCnIUbjASszjYKqq9DJe9jFonzxJQayYdA==
2022-09-29 07:22:56,545 [DEBUG]  Privmsg peer: J56YHpFBAW58o5DA but don't have peerid; sending via directory.
2022-09-29 07:22:58,857 [DEBUG]  >>privmsg on onion-network: nick=J56YHpFBAW58o5DA cmd=auth msg=L5tEQmHh2Yc6y9IIVwmqF51XH2mb6WWj7KtrNHi4hlAJ+1JRaerABpO0iyP5VaV69pqaqVLAUUZGbhfADoDqnLXJcEH0N0aGxxcmzLTsS4y0PA4kpAAas65O95UDeFFSYJGgCWoNdTpCCWSeowOK/ecvF0UCsMnP9zIAMmwd3rS+Yy9UrKxyvWr6lbLMOHBslGrUrn6bCqtwW0cXiCQAT2qB4KjITZTI/6piP506Yuc7tFpjzPVvbIGXvQy8D44P4E+goGDOvI5UiwYkxwKIiQUyHoGHia3fmXCSASem4xFP78PuMGPAavOgJriM6X7eP7xiP3UykYUWK5m7lWFyO46bUP8FZVGcPzfyiBLKcRD3oThDFC2LS4yhCh67Ri8zSfTGN0orJR6UooC0zkNisiMomIuizBJEevGbvFWF7SC/tMs2Q17Xe548kiBYYS5XvBaIBXX/gT7RlKCpAHkSSDzQ61zI+YBv5wsCs2CLK+36gQ== 037f8542be1724e9e9ebe52fe6f6b44490630435cc3a65f39c17d1db85331d754d MEQCIHhRSdRj62kJPmFX161QszwHyCGDGHssZp+ngrxdZomhAiA33KRBUExfaOofjQf1FKv9H8gpXF4gY+QYqO2oZeCAZw==
2022-09-29 07:22:58,858 [DEBUG]  Privmsg peer: J56YHpFBAW58o5DA but don't have peerid; sending via directory.
2022-09-29 07:23:02,863 [INFO]  Makers responded with: {'J56YHpFBAW58o5DA': [['a3368cbfd91d15167f2a2f4e469f96de055ed0ec4166f068dde2ebc219b9fc69:0'], '025c2ac2b74658387bcfa86563829f0253dea8c2f9b5b56630c5b84b3b435686d4', 'bcrt1qk30fdqnesl5v0mvle5cpkxej63swuvdwgt8mmx', 'bcrt1qseu8e7vx2ezxyq0r6pn4rthtdl3utlyr5yqrpm', 'MEQCIEyB1QdYCmNdQlDqluC+IHgn1nH/C0RV91NOR7e15bqGAiAB4+46/t5G5QFOZHnCSbepZvPZXhW1S/IHFO/tdHKBGw==', '60763e19fdbf716e05865eae66ec29ed1026437240fa9427045fead6c5b31e15']}
2022-09-29 07:23:02,872 [INFO]  fee breakdown for J56YHpFBAW58o5DA totalin=2500000000 cjamount=234565865 txfee=0 realcjfee=250
2022-09-29 07:23:02,872 [INFO]  INFO:Got all parts, enough to build a tx
2022-09-29 07:23:02,873 [INFO]  fee breakdown for me totalin=234567467 my_txfee=1352 makers_txfee=0 cjfee_total=250 => changevalue=0
2022-09-29 07:23:02,875 [DEBUG]  rpc: getmempoolinfo None
2022-09-29 07:23:02,879 [INFO]  Using this manually set tx feerate (randomized for privacy): 3343 sat/vkB (3.3 sat/vB).
2022-09-29 07:23:02,879 [DEBUG]  Ratio of actual to estimated sweep fee: 0.7633136094674556
2022-09-29 07:23:02,893 [INFO]  obtained tx
{
    "hex": "0200000003910b648054d8be65e6945b3c426796d7abefed265dcd8089ae96f614fdb7f49f0000000000feffffffd1630cf310702fd346f928607efbd9a4c9f78507227476421ceb4107cfb1ea520000000000feffffff69fcb919c2ebe2dd68f06641ecd05e05de969f464e2f2a7f16151dd9bf8c36a30000000000feffffff0311c907870000000016001486787cf98656446201e3d06751aeeb6fe3c5fc83e930fb0d00000000160014b45e96827987e8c7ed9fcd301b1b32d460ee31aee930fb0d000000001600146255c104c1f1ad15e561147bed1340250cc60e7a18010000",
    "inputs": [
        {
            "outpoint": "9ff4b7fd14f696ae8980cd5d26edefabd79667423c5b94e665bed85480640b91:0",
            "scriptSig": "",
            "nSequence": 4294967294,
            "witness": "00"
        },
        {
            "outpoint": "52eab1cf0741eb1c427674220785f7c9a4d9fb7e6028f946d32f7010f30c63d1:0",
            "scriptSig": "",
            "nSequence": 4294967294,
            "witness": "00"
        },
        {
            "outpoint": "a3368cbfd91d15167f2a2f4e469f96de055ed0ec4166f068dde2ebc219b9fc69:0",
            "scriptSig": "",
            "nSequence": 4294967294,
            "witness": "00"
        }
    ],
    "outputs": [
        {
            "value_sats": 2265434385,
            "scriptPubKey": "001486787cf98656446201e3d06751aeeb6fe3c5fc83",
            "address": "bcrt1qseu8e7vx2ezxyq0r6pn4rthtdl3utlyr5yqrpm"
        },
        {
            "value_sats": 234565865,
            "scriptPubKey": "0014b45e96827987e8c7ed9fcd301b1b32d460ee31ae",
            "address": "bcrt1qk30fdqnesl5v0mvle5cpkxej63swuvdwgt8mmx"
        },
        {
            "value_sats": 234565865,
            "scriptPubKey": "00146255c104c1f1ad15e561147bed1340250cc60e7a",
            "address": "bcrt1qvf2uzpxp7xk3tetpz3a76y6qy5xvvrn6hp9efj"
        }
    ],
    "txid": "bb40267d1db9f055007d7b669000aca2545774a209301166864dbaad6d37c66b",
    "nLockTime": 280,
    "nVersion": 2
}
2022-09-29 07:23:02,893 [INFO]  INFO:Built tx, sending to counterparties.
2022-09-29 07:23:02,898 [DEBUG]  >>privmsg on onion-network: nick=J56YHpFBAW58o5DA cmd=tx msg=n/adezLKs1tYPfMXI7a7cLxjndTEej4DA2iPkAJNSTbIxqHkFWFdnyXHSToTlWM/eD8zf4WpFJcii8vic2Zspy/X2oxpSAiY2JYpxeQCee2B2vSGJmuruHljHmnrv3/iC4DRp0yqWRqWiZ6xTd/6t7cBNjFyffqlGikYorJVWrbmO6JoujPTlU5OTJLe9FD/iEgeODcrBt8n7FLYBYutXb2+j0V4yQyiOmT10sCEt8sIYfWA/ni/ksrELuW934+yMWyZndGyhVoP8TTYZMaxFfJ8Xi/aEnfK7rCpIhqB3kqHILcdpT8ppixkguE2dsDOJKD344BZl+ecpW+EzJz/ckhLYxs5z4emNfJTYt8LYObW6cu2cXNaAMJpi6YgKryxRvUsxg2LPf/S4v+diCnuzIUvXVUYiQ9Y4gBRiAfzDZQkpg0B3hfxRmaom2n24Dfb6tunb0VKzqc= 037f8542be1724e9e9ebe52fe6f6b44490630435cc3a65f39c17d1db85331d754d MEQCICFQldQjGjCb+82UIFIOmW50EtcjdS2CItHTLY5Xd0f0AiB91keFfgmKmD4SlIgF0oxWExH8tOwN0Z+9QSYJykqIDg==
2022-09-29 07:23:02,898 [DEBUG]  Privmsg peer: J56YHpFBAW58o5DA but don't have peerid; sending via directory.
2022-09-29 07:23:03,078 [INFO]  Updating status to connected for peer x.onion:5222.
2022-09-29 07:23:03,079 [INFO]  We, NOT-SERVING-ONION, are calling the handshake callback as client.
2022-09-29 07:23:03,079 [INFO]  Sending this handshake: {"app-name": "joinmarket", "directory": false, "location-string": "NOT-SERVING-ONION", "proto-ver": 5, "features": {}, "nick": "J5BSDw6N3hh8vGaA", "network": "testnet"} to peer x.onion:5222
2022-09-29 07:23:08,361 [DEBUG]  found good sig at index=2
2022-09-29 07:23:08,362 [DEBUG]  nick = J56YHpFBAW58o5DA sent all sigs, removing from nonrespondant list
2022-09-29 07:23:08,362 [INFO]  all makers have sent their signatures
2022-09-29 07:23:08,362 [INFO]  INFO:Transaction is valid, signing..
2022-09-29 07:23:08,362 [DEBUG]  schedule item was: [0, 0, 1, 'bcrt1qvf2uzpxp7xk3tetpz3a76y6qy5xvvrn6hp9efj', 0, 16, 0]
2022-09-29 07:23:08,367 [DEBUG]  
02000000000103910b648054d8be65e6945b3c426796d7abefed265dcd8089ae96f614fdb7f49f0000000000feffffffd1630cf310702fd346f928607efbd9a4c9f78507227476421ceb4107cfb1ea520000000000feffffff69fcb919c2ebe2dd68f06641ecd05e05de969f464e2f2a7f16151dd9bf8c36a30000000000feffffff0311c907870000000016001486787cf98656446201e3d06751aeeb6fe3c5fc83e930fb0d00000000160014b45e96827987e8c7ed9fcd301b1b32d460ee31aee930fb0d000000001600146255c104c1f1ad15e561147bed1340250cc60e7a02483045022100deca48d7991df40db3196afaf6e19e8e3bb18589cdf0ee1ace8586203468fbe702204aa1ada80793b4ff6f671dc005c840418a21d193393cbf737e61d93b904ba05a012103199ff0c0981f2b55cfacf262305ba2fadf01ad25a626234474fdcd33790621680247304402204743f0cdbfe671e8cbbef4c26103979fa474b0bd30eac769d943853a69678f3c022067bc8822b93119124cb411ef3173deb69c583290938c93244fc0fa6f99b286f3012a040078f861b17521028fd9879ae1df6e4d3990f94ea451953b729141311ce3d220f159710cd8bef3e2ac02473044022020ace18f80251935e5d13873dadeabe1cc77151f76d0fc812a73f9ccaf3661d6022076b7b528678f88bb4f7bcdaddbfb2f19973eaab5141327b1e4fce22531fc5c3a0121025c2ac2b74658387bcfa86563829f0253dea8c2f9b5b56630c5b84b3b435686d418010000
2022-09-29 07:23:08,369 [INFO]  txid = bb40267d1db9f055007d7b669000aca2545774a209301166864dbaad6d37c66b
2022-09-29 07:23:08,370 [DEBUG]  rpc: sendrawtransaction ['02000000000103910b648054d8be65e6945b3c426796d7abefed265dcd8089ae96f614fdb7f49f0000000000feffffffd1630cf310702fd346f928607efbd9a4c9f78507227476421ceb4107cfb1ea520000000000feffffff69fcb919c2ebe2dd68f06641ecd05e05de969f464e2f2a7f16151dd9bf8c36a30000000000feffffff0311c907870000000016001486787cf98656446201e3d06751aeeb6fe3c5fc83e930fb0d00000000160014b45e96827987e8c7ed9fcd301b1b32d460ee31aee930fb0d000000001600146255c104c1f1ad15e561147bed1340250cc60e7a02483045022100deca48d7991df40db3196afaf6e19e8e3bb18589cdf0ee1ace8586203468fbe702204aa1ada80793b4ff6f671dc005c840418a21d193393cbf737e61d93b904ba05a012103199ff0c0981f2b55cfacf262305ba2fadf01ad25a626234474fdcd33790621680247304402204743f0cdbfe671e8cbbef4c26103979fa474b0bd30eac769d943853a69678f3c022067bc8822b93119124cb411ef3173deb69c583290938c93244fc0fa6f99b286f3012a040078f861b17521028fd9879ae1df6e4d3990f94ea451953b729141311ce3d220f159710cd8bef3e2ac02473044022020ace18f80251935e5d13873dadeabe1cc77151f76d0fc812a73f9ccaf3661d6022076b7b528678f88bb4f7bcdaddbfb2f19973eaab5141327b1e4fce22531fc5c3a0121025c2ac2b74658387bcfa86563829f0253dea8c2f9b5b56630c5b84b3b435686d418010000']
2022-09-29 07:23:08,372 [WARNING]  error pushing = -26 non-mandatory-script-verify-flag (Locktime requirement not satisfied)
2022-09-29 07:23:08,372 [INFO]  Coinjoin did not complete successfully.

The docs says:

It is possible to spend these untimelocked coins in a coinjoin as a taker.

Question: Is spending an expired fidelity bond possible as a taker or am I doing it wrong? As always, I am on regtest triggering all actions via API.

[theborakompanioni]

Okay.. I thought maybe the chain has not progressed enough.. but spending it in a "direct-send" worked just fine.. Sorry for these layman questions.. : /

[AdamISZ]

Sorry for coming to this a bit late. Note the error in your log says Locktime requirement not satisfied and then note this code:

https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/a06a83a9a4d4965027260218843f462e45cc98ed/jmclient/jmclient/taker.py#L509-L519

So, this should mean that spending should work in a coinjoin, if you're using the p2wpkh type. Of course, it's also possible there's another bug happening. (As a side note: I think we can generous to ourselves and say 'it's not a bug otherwise' since ~ everyone is using p2wpkh now for coinjoins. But debatable, perhaps).

On the other hand, it could be something else. I'll try to do a sanity test now.

[AdamISZ]

Sorry it seems I was being dumb, since your log clearly shows the tx having nLockTime of 280 and version of 2 (and native addresses as well!). So it's not that.

[AdamISZ]

OK, so I need to dig a bit further: the report above has two parts:

• the first is that it doesn't work with only an expired TL utxo, which ofc makes sense since you need a commitment which can't be sourced from that; so I guess we both agree that needs to be mentioned in the docs, but otherwise makes sense.

• the second one, the main point at issue. utxo controlled by TL script. But TL expired:

I have reproduced your error, in both aspects: in coinjoin, the entire negotiation is correct but the final tx push fails with Locktime requirement not satisfied, just like your case. Then repeating the same tx with -N0 (i.e. direct send), works. I notice: for the latter case, the locktime field is actually 1640995201 (a timestamp), for the former it is 632, a block height. This is why it failed, it needs to be a timestamp. This seems to be an error with compute_tx_locktime. I will check.

[AdamISZ]

OK, figured it out I think: this code section is present for direct_send but missing in coinjoin tx construction:

https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/a06a83a9a4d4965027260218843f462e45cc98ed/jmclient/jmclient/taker_utils.py#L143-L150

We will have to think about whether we should add this code to the coinjoin case (I think, not), or just update the docs.

[theborakompanioni]

Thank you for taking the time to verify. As you said, updating the docs as a first measure seems like a good idea. Whether you want to update/change any code as well is all up to you. Thank you :orange_heart:

[AdamISZ]

Thank you for taking the time to verify. As you said, updating the docs as a first measure seems like a good idea. Whether you want to update/change any code as well is all up to you. Thank you orange_heart

Right, so I should explain further, just in case it isn't obvious to any reader:

• Introducing timelocked outputs, we of course had to carefully check that they would be spendable in the wallet. But at the time they were introduced, we did not think carefully at all about the question of: how spendable are they in coinjoins?
• Hence after the release of FB, we had to update our thinking with a bit more analysis: it became clear that maker-side, they were not usable (necessity to send non-standard tx signature messages was not supported by the protocol), but we neglected to really analyze the taker case:

Spending these utxos requires the nLockTime field, which is a transaction wide value (i.e. it cannot be customized per input, as nSequence can) to be of the 'timestamp' type, not the 'block height' type. See BIP65 for details.

It would be possible to add code to do this; makers are not verifying any particular choice by the taker, about these values; see the comment about makers here:

https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/a06a83a9a4d4965027260218843f462e45cc98ed/jmclient/jmclient/taker.py#L512-L519

A reluctance to make this change, i.e. allowing the timestamp-type nLockType is natural from the perspective:

• Using non-standard utxos as input to coinjoins, as taker, is clearly marking out that input as belonging to the Taker. That does not imply that such a coinjoin "fails entirely" to create a privacy improvement, but it's a negative in that sense, always. So this is an argument about whether we even try to allow CLTV type utxos to be spent (not so much an argument about the implication, i.e. that we need to change nLockTime).
• Minor, but this would also take away the anti-fee sniping logic (see BIP 326) that we added because it's simple, logical and falls in line with 'anonymity set' of Core, Electrum etc. (not that of course there's an actual overlap there due to tx structure; so the argument is mainly about anti-fee sniping itself, which is not helped by locktimes in the far past, as they almost always are with an expired CLTV removed that, it's wrong - the nLockTime could be a current timestamp I believe? Though in direct_send we use the locktime+1, for some reason).
• There's also a general reluctance to add new changes to the coinjoin construction code for obvious inertia and conservatism reasons.

I'll just PR a doc change.

[theborakompanioni]

Thank you for the explanation - your reasoning makes perfect sense. Closing the issue as all questions are answered.