Taproot PTLC: Non-Multisig partly timelocked spending conditions

Question

(Taproot environment) What I came up with is the following logic:

$alice = A;
$bob = B;

pk($bob) || (pk($alice) && older(10))

(See on Minsc).

I looked at the generated / resulting Bitcoin Script, which worked in Regtest.

What I was not able to reproduce / verify are the following question:

• Could Bob batch spend UTXOs across contracts with different partners (partners like Alice, in this case) in a single transaction?

Basically Bob creates an address based off the conditions above and James or multiple Payers send their UTXOs to the Tapscript contract.

Bob now wants to spend the received coins, but to reduce fees, he wants to batch spending. So a typical transaction would contain several UXTOs from several different tapscripts. The outputs are 3rd party addresses - including Alice's.

In case Bob is not able to do those transactions, Alice should be able to claim the UXTOs remaining after 10 blocks.

• Is this reproducable in Mainnet once Taproot is activated? Am I missing something?

Answer 1

Yes, assuming James sends Bob two outputs with the following spending conditions:

pk($bob) || (pk($alice) && older(10))
pk($bob) || (pk($carol) && older(10))

Bob can spend these UTXOs together in one transaction by unilaterally satisfying the first spending conditions just with his signatures. Once either of the two UTXOs has ten confirmations, either Alice or Carol respectively also gain the ability to spend said UTXO unilaterally.

If Bob's transaction tx_B has not been confirmed at that blockheight, e.g. Alice could create a conflicting transaction tx_A only using the UTXO she controls as an input and send the funds to one of her own addresses instead of whatever Bob was trying to pay. Given that Bob's transaction tx_B should be broadly present in the mempools of nodes on the network, Alice's tx_A would be dropped by nodes that already have seen tx_B under the "first-seen-safe" policy and would therefore relay poorly on the network, but Alice could hand tx_A directly to miners.

Alternatively, the relay impediment would not apply, if Bob's tx_B had signaled replaceability, and Alice attached a higher transaction fee to her tx_A in which case it would generally displace Bob's transaction in nodes' mempools.

So, while Alice and Carol would be able to produce competing spending instructions after 10 confirmations, it would not be trivial to reliably enforce that their transactions would be preferred over Bob's transaction.