<p>I will only give the answer for a mutual close. The situation for unilateral (forced) channel close should be similar only that you have too look in the commitment transactions and that you have to look for <code>local_delayedpubkey</code> instead of <code>localpubkey</code>.</p>
<p>You can look at <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md" rel="nofollow noreferrer">BOLT 03: Transactions where it is specified</a>. In particular the section <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#closing-transaction" rel="nofollow noreferrer">closing transaction</a>. From there we quote:</p>
<blockquote>
<p>txout script: as specified in that node's <code>scriptpubkey</code> in its `shutdown message``</p>
</blockquote>
<p>This means we look in <a href="https://github.com/lightningnetwork/lightning-rfc/blob/a07dc3df3b4611989e3359f28f96c574f7822850/02-peer-protocol.md" rel="nofollow noreferrer">BOLT 02: Peer Protocol</a> for the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/a07dc3df3b4611989e3359f28f96c574f7822850/02-peer-protocol.md#closing-initiation-shutdown" rel="nofollow noreferrer">closing shutdown message</a>. There the following is specified:
Either node (or both) can send a shutdown message to initiate closing, along with the scriptpubkey it wants to be paid to.</p>
<blockquote>
<p>type: 38 (shutdown)</p>
<p>data:</p>
<p>[32:channel_id]</p>
<p>[2:len]</p>
<p>[len:scriptpubkey]</p>
</blockquote>
<p>which means that the shutdown message basically specifies a channel and a scriptpubkey to which the amount is being paid. Furthermore it is specified that the sender:</p>
<blockquote>
<p>MUST set scriptpubkey in one of the following forms:</p>
<p>OP_DUP OP_HASH160 20 20-bytes OP_EQUALVERIFY OP_CHECKSIG (pay to pubkey hash), OR</p>
<p>OP_HASH160 20 20-bytes OP_EQUAL (pay to script hash), OR</p>
<p>OP_0 20 20-bytes (version 0 pay to witness pubkey), OR</p>
<p>OP_0 32 32-bytes (version 0 pay to witness script hash)</p>
</blockquote>
<p>The spec also mentions the ability to specify the closing <code>scriptpubkey</code> during channel establishment in the announcment messages. The spec keeps silent about the form of the output address.</p>
<p>To a first approximation it seems that every implementation can choose those keys for themselves as long as they are of the above form. However - while this might work - the spec tells something different (in order to make privacy watch tower services possible). So looking at another section of the bolt3 <a href="https://github.com/lightningnetwork/lightning-rfc/blob/a07dc3df3b4611989e3359f28f96c574f7822850/03-transactions.md#keys" rel="nofollow noreferrer">about key derivation</a> we find learn:</p>
<blockquote>
<p>These pubkeys are simply generated by addition from their base points:</p>
<p><code>pubkey = basepoint + SHA256(per_commitment_point || basepoint) * G</code></p>
</blockquote>
<p>The <code>localpubkey</code> uses the local node's <code>payment_basepoint</code></p>
<p>The corresponding private keys can be derived via:</p>
<blockquote>
<p><code>privkey = basepoint_secret + SHA256(per_commitment_point || basepoint)</code></p>
</blockquote>
<p>This means that we have to figure out how to derive the <code>basepoint_secret</code> and the <code>per_commitment_point</code> which is also explained in this BOLT and so much detail that I haven't looked at it yet.</p>

CC BY-SA 4.0
2018-12-17T13:36:11.577Z
2018-12-17T13:36:11.577Z
2020-06-16T11:10:03.350Z
Rene Pickhardt
<p>I've recently opened a payment channel in the Bitcoin testnet LN.<br>
The funding TX ded9fc8b1ee5506037e057a37057a598c362c4b698a40076e75ea88e2ae8a2a2 decoded:   </p>

<pre><code>{
  "txid": "ded9fc8b1ee5506037e057a37057a598c362c4b698a40076e75ea88e2ae8a2a2",
  "hash": "4357b13721588eae4979c6f2814be14bad60535ce284b495f089b3eb68c24e03",
  "version": 2,
  "size": 405,
  "vsize": 243,
  "weight": 972,
  "locktime": 0,
  "vin": [
    {
      "txid": "9d25bdb718e534d6ada203c1291c123a64e96b9cfa9c0c50041499a60034cc0b",
      "vout": 1,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "30440220064b2596e29dd361e76839bc2aa9c3f98690a6b181bfa7809aaddd6faa656ae602201882cc8b29fe2e5e2cdbfd42dbdaa432e69d38fd4b0a018878b4f04d284d70ba01",
        "02aaf68be77ecf046ba50f6aa04f7feca52ca10f8e9a728962d47dabc590170b70"
      ],
      "sequence": 4294967294
    },
    {
      "txid": "cf4e8553b976f05e3dba2189c50a682c3e8801d6cc8506b90eba35aefb915aa8",
      "vout": 0,
      "scriptSig": {
        "asm": "001473b9bbe0a9c3753c77e0e2a75ea80284c0573568",
        "hex": "16001473b9bbe0a9c3753c77e0e2a75ea80284c0573568"
      },
      "txinwitness": [
        "304402207b325f4a5f4dae4fdae611826b8358845f5393322814d564e4d87fd40563eff702203dcb12991ff0207d2855b088221ee79d65f034636eb285317a67aa6b1642120101",
        "03d4926529290be91f2290b017b5dbf0f2bcf9d33a2bf0c90ed86138ceeb1d4970"
      ],
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 0.01188846,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 3d8f9974dc89ea3ad4b7306c6820ff64083bf4d1",
        "hex": "00143d8f9974dc89ea3ad4b7306c6820ff64083bf4d1",
        "reqSigs": 1,
        "type": "witness_v0_keyhash",
        "addresses": [
          "tb1q8k8ejaxu384r449hxpkxsg8lvsyrhax3xh2lsc"
        ]
      }
    },
    {
      "value": 0.01400000,
      "n": 1,
      "scriptPubKey": {
        "asm": "0 00c3e38f885b98f1d536bfc9f3e6c4b15bbe3879094e191936b8c5d792de6252",
        "hex": "002000c3e38f885b98f1d536bfc9f3e6c4b15bbe3879094e191936b8c5d792de6252",
        "reqSigs": 1,
        "type": "witness_v0_scripthash",
        "addresses": [
          "tb1qqrp78rugtwv0r4fkhlyl8ekyk9dmuwrep98pjxfkhrza0yk7vffqpzuhga"
        ]
      }
    }
  ]
}   
</code></pre>

<p>and to closing TX a867d06e9841b8c60318554bb4efc9bcf050dae4789f63403737597adc864af8   decoded:   </p>

<pre><code>{
  "txid": "a867d06e9841b8c60318554bb4efc9bcf050dae4789f63403737597adc864af8",
  "hash": "dde0cc812f55df3a3163de5963bf74ba5cc51e1fbc0a5bd568eb3cf9fc10b28f",
  "version": 2,
  "size": 304,
  "vsize": 139,
  "weight": 553,
  "locktime": 0,
  "vin": [
    {
      "txid": "ded9fc8b1ee5506037e057a37057a598c362c4b698a40076e75ea88e2ae8a2a2",
      "vout": 1,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "",
        "3045022100fb500b4d35fe0e64aca0bd5311e58182aaec09345eba79b470d7985a7f5824cb022044a98de94465c520a06b9e4084f5d2b92d3e042bf51e603f8b8e1d318e23e09e01",
        "3044022050a97294e904033fc32b313db771c7fa81c96a2cd51f868b1d35ec100224bc5a02207e8528e2ba002a127ed9ca85fc35804c1bbd98f106e6ab0920b08af794b5b4bf01",
        "5221025fce122008fae0295572467c5f28ae5c2dda9653be88038b85fc70e501be062b2103db50a4a1c290e2570ba36317709cc5ea6f9d94d43532581f9c8da945f7baeba852ae"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.01399770,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 f75a397c32f4bb83df13f684cc34d9a51bd98b4a OP_EQUAL",
        "hex": "a914f75a397c32f4bb83df13f684cc34d9a51bd98b4a87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2NFo6yaTxo78vvCHe3bk6gGVngRyp2Psvnk"
        ]
      }
    }
  ]
}   
</code></pre>

<p>I am having a hard time to figure out how I can know the receiving address ("2NFo6yaTxo78vvCHe3bk6gGVngRyp2Psvnk") prior to the closing of the channel? Is it an address in the outputs of the funding transaction? Because I can't find this address there. So, how did the building of the closing transaction take place? 
I'll be happy to understand more about the funding and closing tx scripts / process. </p>

<lightning-network><ln-opening-channels><ln-closing-channels>
How is the recipient address for closing a Lightning Channel derived?
Haddar Macdasi
# How is the recipient address for closing a Lightning Channel derived?

(Asked by: username_0 on 2018-12-16)

I've recently opened a payment channel in the Bitcoin testnet LN.  
The funding TX ded9fc8b1ee5506037e057a37057a598c362c4b698a40076e75ea88e2ae8a2a2 decoded:

```
{
  "txid": "ded9fc8b1ee5506037e057a37057a598c362c4b698a40076e75ea88e2ae8a2a2",
  "hash": "4357b13721588eae4979c6f2814be14bad60535ce284b495f089b3eb68c24e03",
  "version": 2,
  "size": 405,
  "vsize": 243,
  "weight": 972,
  "locktime": 0,
  "vin": [
    {
      "txid": "9d25bdb718e534d6ada203c1291c123a64e96b9cfa9c0c50041499a60034cc0b",
      "vout": 1,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "30440220064b2596e29dd361e76839bc2aa9c3f98690a6b181bfa7809aaddd6faa656ae602201882cc8b29fe2e5e2cdbfd42dbdaa432e69d38fd4b0a018878b4f04d284d70ba01",
        "02aaf68be77ecf046ba50f6aa04f7feca52ca10f8e9a728962d47dabc590170b70"
      ],
      "sequence": 4294967294
    },
    {
      "txid": "cf4e8553b976f05e3dba2189c50a682c3e8801d6cc8506b90eba35aefb915aa8",
      "vout": 0,
      "scriptSig": {
        "asm": "001473b9bbe0a9c3753c77e0e2a75ea80284c0573568",
        "hex": "16001473b9bbe0a9c3753c77e0e2a75ea80284c0573568"
      },
      "txinwitness": [
        "304402207b325f4a5f4dae4fdae611826b8358845f5393322814d564e4d87fd40563eff702203dcb12991ff0207d2855b088221ee79d65f034636eb285317a67aa6b1642120101",
        "03d4926529290be91f2290b017b5dbf0f2bcf9d33a2bf0c90ed86138ceeb1d4970"
      ],
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 0.01188846,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 3d8f9974dc89ea3ad4b7306c6820ff64083bf4d1",
        "hex": "00143d8f9974dc89ea3ad4b7306c6820ff64083bf4d1",
        "reqSigs": 1,
        "type": "witness_v0_keyhash",
        "addresses": [
          "tb1q8k8ejaxu384r449hxpkxsg8lvsyrhax3xh2lsc"
        ]
      }
    },
    {
      "value": 0.01400000,
      "n": 1,
      "scriptPubKey": {
        "asm": "0 00c3e38f885b98f1d536bfc9f3e6c4b15bbe3879094e191936b8c5d792de6252",
        "hex": "002000c3e38f885b98f1d536bfc9f3e6c4b15bbe3879094e191936b8c5d792de6252",
        "reqSigs": 1,
        "type": "witness_v0_scripthash",
        "addresses": [
          "tb1qqrp78rugtwv0r4fkhlyl8ekyk9dmuwrep98pjxfkhrza0yk7vffqpzuhga"
        ]
      }
    }
  ]
}   

```

and to closing TX a867d06e9841b8c60318554bb4efc9bcf050dae4789f63403737597adc864af8 decoded:

```
{
  "txid": "a867d06e9841b8c60318554bb4efc9bcf050dae4789f63403737597adc864af8",
  "hash": "dde0cc812f55df3a3163de5963bf74ba5cc51e1fbc0a5bd568eb3cf9fc10b28f",
  "version": 2,
  "size": 304,
  "vsize": 139,
  "weight": 553,
  "locktime": 0,
  "vin": [
    {
      "txid": "ded9fc8b1ee5506037e057a37057a598c362c4b698a40076e75ea88e2ae8a2a2",
      "vout": 1,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "",
        "3045022100fb500b4d35fe0e64aca0bd5311e58182aaec09345eba79b470d7985a7f5824cb022044a98de94465c520a06b9e4084f5d2b92d3e042bf51e603f8b8e1d318e23e09e01",
        "3044022050a97294e904033fc32b313db771c7fa81c96a2cd51f868b1d35ec100224bc5a02207e8528e2ba002a127ed9ca85fc35804c1bbd98f106e6ab0920b08af794b5b4bf01",
        "5221025fce122008fae0295572467c5f28ae5c2dda9653be88038b85fc70e501be062b2103db50a4a1c290e2570ba36317709cc5ea6f9d94d43532581f9c8da945f7baeba852ae"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.01399770,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 f75a397c32f4bb83df13f684cc34d9a51bd98b4a OP_EQUAL",
        "hex": "a914f75a397c32f4bb83df13f684cc34d9a51bd98b4a87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2NFo6yaTxo78vvCHe3bk6gGVngRyp2Psvnk"
        ]
      }
    }
  ]
}   

```

I am having a hard time to figure out how I can know the receiving address ("2NFo6yaTxo78vvCHe3bk6gGVngRyp2Psvnk") prior to the closing of the channel? Is it an address in the outputs of the funding transaction? Because I can't find this address there. So, how did the building of the closing transaction take place?
I'll be happy to understand more about the funding and closing tx scripts / process.

**Tags:** lightning-network, ln-opening-channels, ln-closing-channels


---

## 1 answers

### Answer by username_1 on 2018-12-17. Score: 1

I will only give the answer for a mutual close. The situation for unilateral (forced) channel close should be similar only that you have too look in the commitment transactions and that you have to look for `local_delayedpubkey` instead of `localpubkey`.

You can look at [BOLT 03: Transactions where it is specified](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md). In particular the section [closing transaction](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#closing-transaction). From there we quote:

> txout script: as specified in that node's `scriptpubkey` in its `shutdown message``

This means we look in [BOLT 02: Peer Protocol](https://github.com/lightningnetwork/lightning-rfc/blob/a07dc3df3b4611989e3359f28f96c574f7822850/02-peer-protocol.md) for the [closing shutdown message](https://github.com/lightningnetwork/lightning-rfc/blob/a07dc3df3b4611989e3359f28f96c574f7822850/02-peer-protocol.md#closing-initiation-shutdown). There the following is specified:
Either node (or both) can send a shutdown message to initiate closing, along with the scriptpubkey it wants to be paid to.

> type: 38 (shutdown)
>
> data:
>
> [32:channel\_id]
>
> [2:len]
>
> [len:scriptpubkey]

which means that the shutdown message basically specifies a channel and a scriptpubkey to which the amount is being paid. Furthermore it is specified that the sender:

> MUST set scriptpubkey in one of the following forms:
>
> OP\_DUP OP\_HASH160 20 20-bytes OP\_EQUALVERIFY OP\_CHECKSIG (pay to pubkey hash), OR
>
> OP\_HASH160 20 20-bytes OP\_EQUAL (pay to script hash), OR
>
> OP\_0 20 20-bytes (version 0 pay to witness pubkey), OR
>
> OP\_0 32 32-bytes (version 0 pay to witness script hash)

The spec also mentions the ability to specify the closing `scriptpubkey` during channel establishment in the announcment messages. The spec keeps silent about the form of the output address.

To a first approximation it seems that every implementation can choose those keys for themselves as long as they are of the above form. However - while this might work - the spec tells something different (in order to make privacy watch tower services possible). So looking at another section of the bolt3 [about key derivation](https://github.com/lightningnetwork/lightning-rfc/blob/a07dc3df3b4611989e3359f28f96c574f7822850/03-transactions.md#keys) we find learn:

> These pubkeys are simply generated by addition from their base points:
>
> `pubkey = basepoint + SHA256(per_commitment_point || basepoint) * G`

The `localpubkey` uses the local node's `payment_basepoint`

The corresponding private keys can be derived via:

> `privkey = basepoint_secret + SHA256(per_commitment_point || basepoint)`

This means that we have to figure out how to derive the `basepoint_secret` and the `per_commitment_point` which is also explained in this BOLT and so much detail that I haven't looked at it yet.


---

