<p>Yes, assuming James sends Bob two outputs with the following spending conditions:</p>
<blockquote>
<pre><code>pk($bob) || (pk($alice) &amp;&amp; older(10))
pk($bob) || (pk($carol) &amp;&amp; older(10))
</code></pre>
</blockquote>
<p>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.</p>
<p>If Bob's transaction <code>tx_B</code> has not been confirmed at that blockheight, e.g. Alice could create a conflicting transaction <code>tx_A</code> 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 <code>tx_B</code> should be broadly present in the mempools of nodes on the network, Alice's <code>tx_A</code> would be dropped by nodes that already have seen <code>tx_B</code> under the &quot;first-seen-safe&quot; policy and would therefore relay poorly on the network, but Alice could hand <code>tx_A</code> directly to miners.</p>
<p>Alternatively, the relay impediment would not apply, if Bob's <code>tx_B</code> had signaled replaceability, and Alice attached a higher transaction fee to her <code>tx_A</code> in which case it would generally displace Bob's transaction in nodes' mempools.</p>
<p>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.</p>

CC BY-SA 4.0
2021-08-27T18:37:04.507Z
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?
ByteFlowr
CC BY-SA 4.0
2021-08-27T18:47:19.943Z
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
CC BY-SA 4.0
2021-08-26T18:29:07.970Z
2021-08-26T18:53:23.263Z
2021-08-26T18:53:23.263Z
Murch
<p>(Taproot environment) What I came up with is the following logic:</p>
<pre><code>$alice = A;
$bob = B;

pk($bob) || (pk($alice) &amp;&amp; older(10))
</code></pre>
<p>(<a href="https://min.sc/#c=%24alice%20%3D%20A%3B%0A%24bob%20%3D%20B%3B%0A%0Apk%28%24bob%29%20%7C%7C%20%28pk%28%24alice%29%20%26%26%20older%2810%29%29" rel="nofollow noreferrer">See on Minsc</a>).</p>
<p>I looked at the generated / resulting Bitcoin Script, which worked in Regtest.</p>
<p>What I was not able to reproduce / verify are the following question:</p>
<ul>
<li>Could Bob batch spend UTXOs across contracts with different partners (partners like Alice, in this case) in a single transaction?</li>
</ul>
<p>Basically Bob creates an address based off the conditions above and James or multiple Payers send their UTXOs to the Tapscript contract.</p>
<p>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.</p>
<p>In case Bob is not able to do those transactions, Alice should be able to claim the UXTOs remaining after 10 blocks.</p>
<ul>
<li>Is this reproducable in Mainnet once Taproot is activated? Am I missing something?</li>
</ul>

CC BY-SA 4.0
2021-08-26T17:50:57.883Z
Hi Nerrix, while the construction you describe seems feasible, it's not clear to me what you're trying to achieve.
Murch
CC BY-SA 4.0
2021-08-26T18:01:11.267Z
@Murch Bob has just a normal wallet, except that Alice can spend the held UTXOs after 10 blocks. Simply speaking.
ByteFlowr
CC BY-SA 4.0
2021-08-26T18:03:25.970Z
Yeah, but why would you want to do that?
Murch
CC BY-SA 4.0
2021-08-26T18:06:11.510Z
@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.
ByteFlowr
<script><taproot><hash-time-locked-contract><point-time-locked-contract>
Taproot PTLC: Non-Multisig partly timelocked spending conditions
ByteFlowr
# Taproot PTLC: Non-Multisig partly timelocked spending conditions

(Asked by: username_0 on 2021-08-26)

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

```
$alice = A;
$bob = B;

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

```

([See on Minsc](https://min.sc/#c=%24alice%20%3D%20A%3B%0A%24bob%20%3D%20B%3B%0A%0Apk%28%24bob%29%20%7C%7C%20%28pk%28%24alice%29%20%26%26%20older%2810%29%29)).

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?

**Tags:** script, taproot, hash-time-locked-contract, point-time-locked-contract

> **Comments:**
> **username_1**: Hi Nerrix, while the construction you describe seems feasible, it's not clear to me what you're trying to achieve.  
> **username_0**: @username_1 Bob has just a normal wallet, except that Alice can spend the held UTXOs after 10 blocks. Simply speaking.  
> **username_1**: Yeah, but why would you want to do that?  
> **username_0**: @username_1 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.  

---

## 1 answers

### Answer by username_1 on 2021-08-26. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_0**: 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?  
> **username_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.  

---

