<p>The inputs of a transaction have absolutely no ability to effect the outputs in any situation. They can only define who can spend, not the conditions for how they go about spending it. </p>

CC BY-SA 4.0
2019-03-22T16:56:52.960Z
It had not occurred to me before now that the redeemScript is one of the inputs, so thank you for that - that's obvious to me now it's pointed out.
I suspect I was conflating "the script" used on the page in the narrower sense of "redeemScript".
Alistair Mann
CC BY-SA 4.0
2019-03-22T13:35:38.867Z
2019-03-22T13:35:38.867Z
Claris
<p>Starting from this text at <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Script</a>:</p>

<p><em>"The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide 1. a public key that, when hashed, yields destination address D embedded in the script ..."</em></p>

<p>and then looking at the HTLC script:</p>

<pre><code>OP_IF
    [HASHOP] &lt;digest&gt; OP_EQUALVERIFY OP_DUP OP_HASH160 &lt;seller pubkey hash&gt;            
OP_ELSE
    &lt;num&gt; [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 &lt;buyer pubkey hash&gt;
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
</code></pre>

<p>My original thought was that the HTLC could only be redeemed to the address behind <code>&lt;seller pubkey hash&gt;</code> or <code>&lt;buyer pubkey hash&gt;</code>: they are the only data relating to addresses embedded in the script so must be the "destination address" referred to above. I understand this to be wrong.</p>

<p>Am I now correct in thinking:</p>

<ol>
<li>That the two pubkey hashes merely establish the right of the redeemer to take the respective branch;</li>
<li>There is in fact <strong>no</strong> "destination address D embedded in the script" for an HTLC;</li>
<li>That the seller or buyer may redeem to any address they like;</li>
<li>And that address can remain undecided through the funding and life of the HTLC until the moments before redemption?</li>
</ol>

<transactions><script><signature><p2sh><hash-time-locked-contract>
Destination address(es) when redeeming an HTLC
Alistair Mann
# Destination address(es) when redeeming an HTLC

(Asked by: username_0 on 2019-03-22)

Starting from this text at <https://en.bitcoin.it/wiki/Script>:

*"The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide 1. a public key that, when hashed, yields destination address D embedded in the script ..."*

and then looking at the HTLC script:

```
OP_IF
    [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>            
OP_ELSE
    <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG

```

My original thought was that the HTLC could only be redeemed to the address behind `<seller pubkey hash>` or `<buyer pubkey hash>`: they are the only data relating to addresses embedded in the script so must be the "destination address" referred to above. I understand this to be wrong.

Am I now correct in thinking:

1. That the two pubkey hashes merely establish the right of the redeemer to take the respective branch;
2. There is in fact **no** "destination address D embedded in the script" for an HTLC;
3. That the seller or buyer may redeem to any address they like;
4. And that address can remain undecided through the funding and life of the HTLC until the moments before redemption?

**Tags:** transactions, script, signature, p2sh, hash-time-locked-contract


---

## 1 answers

### Answer by username_1 on 2019-03-22. Score: 1 | Accepted answer

The inputs of a transaction have absolutely no ability to effect the outputs in any situation. They can only define who can spend, not the conditions for how they go about spending it.

> **Comments:**
> **username_0**: It had not occurred to me before now that the redeemScript is one of the inputs, so thank you for that - that's obvious to me now it's pointed out. I suspect I was conflating "the script" used on the page in the narrower sense of "redeemScript".  

---

