<p>Elliptic curve private keys are just scalar integer values between <code>1</code> and <code>n</code> (The <em>order</em> of <code>G</code>). These can be encoded by any means, but usually they are just represented as 256-bit integers with whatever endianness the platform uses. If interpreted as an array of bytes, it is simply a 32 byte sequence.</p>

<p>The WIF (Wallet Import Format) of Bitcoin takes the 32 byte sequence, prepends a version byte, then takes the double-SHA256 to generate a checksum. The first 4 bytes of the checksum are appended to the version and private key bytes to make a sequence of 37 byte in total. This is then Base58Check encoded to produce the textual representation of private keys you're familiar with. The reason they all begin with 5 is because of the version byte.</p>

<p>There is no specification for the storage or import/export format of private keys in any of the lightning specifications and it is left up to implementers to decide how to store them, or how to or export them, if at all. You can use the same WIF format if you want, as Lightning uses the same curve as Bitcoin for its signing and key exchange.</p>

<p>Private keys are used for two different purposes in Lightning. The Lightning node itself has a single, fixed private key, which is used both to identify the node (by its respective public key), and to sign messages proving that they indeed originated from that node. It is also used to perform an authenticated key exchange when connecting to peers to prevent MitM attacks.</p>

<p>The other private keys used in Lightning are entries of a bitcoin wallet, used to sign transactions regarding the channel states, which are standard bitcoin transaction outputs.</p>

<p>However, just knowing the private key for a particular channel is insufficient to spend from that channel, as they are 2-of-2 multisig outputs, and both parties need to sign off the transaction to spend it. You therefore need to have knowledge of a spending transaction and a signature from the other party for that transaction <em>in addition</em> to your own private key for the channel. </p>

<p>It is clearly not much use to just export these private key on their own - you would need a more detailed format which contains all of the necessary parts to reconstruct the current state of the channel at minimum. In practice, you should have a record of all previous channel states too, so that you are able to construct a justice transaction if the other party attempts to broadcast an expired channel state, unless you've delegated this role to a watchtower, who should have a record.</p>

CC BY-SA 4.0
2019-10-11T21:27:09.527Z
2019-10-11T21:27:09.527Z
Mark H
<p>I know bitcoin private keys start with a 5... But how does a lightning bitcoin private key look like? Say I wanted to printed it out as a paper wallet. </p>

<private-key><lightning-network><paper-wallet>
What does a Bitcoin lightning private key look like?
Patoshi パトシ
# What does a Bitcoin lightning private key look like?

(Asked by: username_0 on 2019-10-11)

I know bitcoin private keys start with a 5... But how does a lightning bitcoin private key look like? Say I wanted to printed it out as a paper wallet.

**Tags:** private-key, lightning-network, paper-wallet


---

## 1 answers

### Answer by username_1 on 2019-10-11. Score: 4 | Accepted answer

Elliptic curve private keys are just scalar integer values between `1` and `n` (The *order* of `G`). These can be encoded by any means, but usually they are just represented as 256-bit integers with whatever endianness the platform uses. If interpreted as an array of bytes, it is simply a 32 byte sequence.

The WIF (Wallet Import Format) of Bitcoin takes the 32 byte sequence, prepends a version byte, then takes the double-SHA256 to generate a checksum. The first 4 bytes of the checksum are appended to the version and private key bytes to make a sequence of 37 byte in total. This is then Base58Check encoded to produce the textual representation of private keys you're familiar with. The reason they all begin with 5 is because of the version byte.

There is no specification for the storage or import/export format of private keys in any of the lightning specifications and it is left up to implementers to decide how to store them, or how to or export them, if at all. You can use the same WIF format if you want, as Lightning uses the same curve as Bitcoin for its signing and key exchange.

Private keys are used for two different purposes in Lightning. The Lightning node itself has a single, fixed private key, which is used both to identify the node (by its respective public key), and to sign messages proving that they indeed originated from that node. It is also used to perform an authenticated key exchange when connecting to peers to prevent MitM attacks.

The other private keys used in Lightning are entries of a bitcoin wallet, used to sign transactions regarding the channel states, which are standard bitcoin transaction outputs.

However, just knowing the private key for a particular channel is insufficient to spend from that channel, as they are 2-of-2 multisig outputs, and both parties need to sign off the transaction to spend it. You therefore need to have knowledge of a spending transaction and a signature from the other party for that transaction *in addition* to your own private key for the channel.

It is clearly not much use to just export these private key on their own - you would need a more detailed format which contains all of the necessary parts to reconstruct the current state of the channel at minimum. In practice, you should have a record of all previous channel states too, so that you are able to construct a justice transaction if the other party attempts to broadcast an expired channel state, unless you've delegated this role to a watchtower, who should have a record.


---

