<p>The values you've pasted <strong>are</strong> the node public key and the funding transaction output public key. The keys are encoded in compressed form (0x02 | 0x03 followed by the 32-byte x-coordinate of a point on the curve). The first byte indicates whether the y-coordinate is positive (0x02) or negative (x03). The 33-byte public key is the format used throughout the BOLT specs. All values in the BOLTs are encoded in network endian byte order.</p>

<p>There is no "bitcoin address" in either of these, nor are any convertible directly to an address. In bitcoin, the funding transactions use a P2WSH output, but the redeem script for this transaction is not revealed until the transaction is spent (channel closed). The only way to reconstruct the redeem script is if you know both funding public keys for the channel. in which case the redeem script is simply <code>02 &lt;pubkey1&gt; &lt;pubkey2&gt; 02 OP_CHECKMULTISIG</code>, where <code>&lt;pubkey1&gt;</code> is the lesser of the two public keys.</p>

<p>The way Lightning channels are mapped to a bitcoin transaction is through their <code>short_channel_id</code>, which is a triplet of <code>&lt;block_height&gt;x&lt;tx_index&gt;x&lt;output_index&gt;</code>, encoded as a 64-bit integer. (block_height and tx_index as 24-bits each and output_index as 16-bits).</p>

<p>The full <code>channel_id</code> can also be used to map the channel to a bitcoin transaction, as the <code>channel_id</code> is the <code>txid</code> xor <code>output_index</code>.</p>

CC BY-SA 4.0
2020-04-11T08:32:45.983Z
To give more context: the data above comes from a `channel_announcement` message where you have two nodes' pubkeys and the two corresponding Bitcoin public keys. If I understand correctly, these two Bitcoin keys are the ones that will be used to spend the UTXO that funded the channel, when the two nodes want to close it, but there is no way to link these keys to Bitcoin addresses of the nodes, neither the input addresses funding the channel nor the output addresses in the closing transaction, right?
M_R
CC BY-SA 4.0
2020-04-10T20:25:51.407Z
2020-04-10T20:30:59.193Z
2020-04-10T20:30:59.193Z
Mark H
<p>From the LND logs I have something like this (I changed some characters for privacy):</p>

<pre><code>NodeID1: ([33]uint8) (len=33 cap=33) {
 00000000  02 19 8b 61 42 18 89 24  74 fc 95 ed 64 c4 77 91  |.9.a@(.$t...d...|
 00000010  e9 94 97 50 42 d0 bd 7e  95 91 b0 ec 41 28 ab ac  |...PB..~....A(..|
 00000020  e4                                                |.|
}


BitcoinKey1: ([33]uint8) (len=33 cap=33) {
 00000000  02 63 a4 ca a4 63 8c 3c  43 fc 65 8a e5 7c b5 f8  |.c...c.&lt;C.e..|..|
 00000010  a7 8f f5 a4 d8 2e ad 0a  83 3a 17 e1 e8 1e c8 c8  |.........J......|
 00000020  91                                                |.|
}

</code></pre>

<p>I read and checked some <a href="https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses#How_to_create_Bitcoin_Address" rel="nofollow noreferrer">docs</a> and <a href="http://gobittest.appspot.com/Address" rel="nofollow noreferrer">services</a>, but the result is wrong. </p>

<p>What are the steps to obtain the node pubkey and the Bitcoin address?</p>

<p>I fear that similar questions have been already answered, but I'm still not able to answer mine.</p>

<bitcoin-core><lightning-network><lightning-network-daemon>
Converting NodeID and BitcoinKey from Lightning Network (LND) logs
M_R
# Converting NodeID and BitcoinKey from Lightning Network (LND) logs

(Asked by: username_0 on 2020-04-10)

From the LND logs I have something like this (I changed some characters for privacy):
NodeID1: ([33]uint8) (len=33 cap=33) {
 00000000  02 19 8b 61 42 18 89 24  74 fc 95 ed 64 c4 77 91  |.9.a@(.$t...d...|
 00000010  e9 94 97 50 42 d0 bd 7e  95 91 b0 ec 41 28 ab ac  |...PB..~....A(..|
 00000020  e4                                                |.|
}


BitcoinKey1: ([33]uint8) (len=33 cap=33) {
 00000000  02 63 a4 ca a4 63 8c 3c  43 fc 65 8a e5 7c b5 f8  |.c...c.
I read and checked some docs and services, but the result is wrong. 
What are the steps to obtain the node pubkey and the Bitcoin address?
I fear that similar questions have been already answered, but I'm still not able to answer mine.

**Tags:** bitcoin-core, lightning-network, lightning-network-daemon


---

## 1 answers

### Answer by username_1 on 2020-04-10. Score: 1 | Accepted answer

The values you've pasted **are** the node public key and the funding transaction output public key. The keys are encoded in compressed form (0x02 | 0x03 followed by the 32-byte x-coordinate of a point on the curve). The first byte indicates whether the y-coordinate is positive (0x02) or negative (x03). The 33-byte public key is the format used throughout the BOLT specs. All values in the BOLTs are encoded in network endian byte order.

There is no "bitcoin address" in either of these, nor are any convertible directly to an address. In bitcoin, the funding transactions use a P2WSH output, but the redeem script for this transaction is not revealed until the transaction is spent (channel closed). The only way to reconstruct the redeem script is if you know both funding public keys for the channel. in which case the redeem script is simply `02   02 OP_CHECKMULTISIG`, where  is the lesser of the two public keys.

The way Lightning channels are mapped to a bitcoin transaction is through their `short_channel_id`, which is a triplet of `xx`, encoded as a 64-bit integer. (block\_height and tx\_index as 24-bits each and output\_index as 16-bits).

The full `channel_id` can also be used to map the channel to a bitcoin transaction, as the `channel_id` is the `txid` xor `output_index`.

> **Comments:**
> **username_0**: To give more context: the data above comes from a `channel_announcement` message where you have two nodes' pubkeys and the two corresponding Bitcoin public keys. If I understand correctly, these two Bitcoin keys are the ones that will be used to spend the UTXO that funded the channel, when the two nodes want to close it, but there is no way to link these keys to Bitcoin addresses of the nodes, neither the input addresses funding the channel nor the output addresses in the closing transaction, right?  

---

