1

(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?
4
  • Hi Nerrix, while the construction you describe seems feasible, it's not clear to me what you're trying to achieve.
    – Murch
    Aug 26 '21 at 17:50
  • @Murch Bob has just a normal wallet, except that Alice can spend the held UTXOs after 10 blocks. Simply speaking.
    – Nerrix
    Aug 26 '21 at 18:01
  • Yeah, but why would you want to do that?
    – Murch
    Aug 26 '21 at 18:03
  • @Murch I can't go into much details here but this fallback to Alice after 10 blocks is needed for circumstances outside the world of Bitcoin ;) I am very certain about the setup named tho.
    – Nerrix
    Aug 26 '21 at 18:06
3

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.

2
  • Awesome answer. Am I understanding this correctly that this is the same as Bob's PubKey would be the Internal Key for Keypath spending and the Tweak to it could contain Alice's PubKey with a 10 block timelock? Actually this would be the way to go I guess?
    – Nerrix
    Aug 27 '21 at 18:37
  • 1
    Yes, you should make Bob's key the internal key for a keypath spend and for Alice's spending condition you could use a tapleaf via a scriptpath spend. I assume the most likely spending condition would be that Bob uses the UTXO, and locktime opcodes cannot be used in a keypath-spend anyway.
    – Murch
    Aug 27 '21 at 18:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.