<p>The <a href="https://github.com/lightningnetwork/lightning-rfc/blob/8516beb2c4fe6fc19bb4b1824b1635ae13805f49/07-routing-gossip.md#requirements" rel="nofollow noreferrer">specification</a> of the <code>short_channel_id</code> describes the format as follows:</p>
<blockquote>
<p>The <code>short_channel_id</code> is the unique description of the funding transaction. It is constructed as follows:</p>
<ol>
<li>the most significant 3 bytes: indicating the block height</li>
<li>the next 3 bytes: indicating the transaction index within the block</li>
<li>the least significant 2 bytes: indicating the output index that pays to the channel.</li>
</ol>
</blockquote>
<p>Hence to convert between the two formats you can use the following python snippets:</p>
<pre><code>def lnd_to_cl_scid(s):
    block = s &gt;&gt; 40
    tx = s &gt;&gt; 16 &amp; 0xFFFFFF
    output = s  &amp; 0xFFFF
    return (block, tx, output)

def cl_to_lnd_scid(s):
    s = [int(i) for i in s.split('x')]
    return (s[0] &lt;&lt; 40) | (s[1] &lt;&lt; 16) | s[2]
</code></pre>
<p>The reason we (c-lightning) use the dotted format is because it allows us to look up the funding TX without having to do a conversion (and it usually is shorter than the <code>u64</code> representation)</p>

CC BY-SA 4.0
2018-09-20T12:23:56.280Z
2022-12-20T11:58:30.047Z
2022-12-20T11:58:30.047Z
cdecker
<p><a href="https://github.com/lightningnetwork/lnd/blob/8379bbaa9b259544c2c8591782a78d7384680b2a/lnwire/short_channel_id.go#L25-L43" rel="nofollow noreferrer">https://github.com/lightningnetwork/lnd/blob/8379bbaa9b259544c2c8591782a78d7384680b2a/lnwire/short_channel_id.go#L25-L43</a></p>

<pre><code>// NewShortChanIDFromInt returns a new ShortChannelID which is the decoded
// version of the compact channel ID encoded within the uint64. The format of
// the compact channel ID is as follows: 3 bytes for the block height, 3 bytes
// for the transaction index, and 2 bytes for the output index.
func NewShortChanIDFromInt(chanID uint64) ShortChannelID {
    return ShortChannelID{
        BlockHeight: uint32(chanID &gt;&gt; 40),
        TxIndex:     uint32(chanID&gt;&gt;16) &amp; 0xFFFFFF,
        TxPosition:  uint16(chanID),
    }
}

// ToUint64 converts the ShortChannelID into a compact format encoded within a
// uint64 (8 bytes).
func (c ShortChannelID) ToUint64() uint64 {
    // TODO(roasbeef): explicit error on overflow?
    return ((uint64(c.BlockHeight) &lt;&lt; 40) | (uint64(c.TxIndex) &lt;&lt; 16) |
        (uint64(c.TxPosition)))
}
</code></pre>

CC BY-SA 4.0
2018-08-08T15:41:06.557Z
2018-08-08T15:41:06.557Z
Andrey Dzhukov
<p>I have the following function definition in my Bash profile:</p>
<pre class="lang-bash prettyprint-override"><code>scid() {
    local -i scid
    if (( ${#} )) ; then
        for scid ; do
            echo &quot;$((scid &gt;&gt; 40))x$((scid &gt;&gt; 16 &amp; 0xFFFFFF))x$((scid &amp; 0xFFFF))&quot;
        done
    else
        while read -r scid ; do
            scid &quot;${scid}&quot;
        done
    fi
}
</code></pre>
<p>This lets me conveniently convert those ugly LND-style short channel IDs into the standards-compliant format, either by passing them to the <code>scid</code> function as arguments or by piping them in, one per line:</p>
<pre class="lang-bash prettyprint-override"><code>$ scid 556369376388317185
506015x904x1
$ echo 556369376388317185 | scid
506015x904x1
</code></pre>

CC BY-SA 4.0
2024-10-18T05:20:00.313Z
2024-10-18T05:20:00.313Z
Matt Whitlock
<p>Sorry for the dumb question, but I'm not very good in lightning network...
So I have two daemons: <code>c-lightning</code> and <code>LND</code>.</p>
<p>Channels from the <code>c-lightning</code> comes like this <code>505580x1917x1</code>;
Channels from the <code>LND</code> comes like this <code>556369376388317185</code>;</p>
<p>Is it possible to bring them to a single format? For example <code>c-lightning</code> convert to simple integer like <code>LND</code> in order to find same channels from both daemons?</p>

CC BY-SA 4.0
2019-03-23T09:29:03.537Z
In the spec meeting in November it was agreed to make the format of the short channel Id part of the protocol. In future implementations should use the clightning format with `x` as a separator instead of `:` while colon was very readable the short channel ids that use x as a separator are doubleclickable.
Rene Pickhardt
<lightning-network><lightning-network-daemon><core-lightning><channels>
How to convert channel id from c-lightning to lnd?
user1692333
# How to convert channel id from c-lightning to lnd?

(Asked by: username_0 on 2018-08-08)

Sorry for the dumb question, but I'm not very good in lightning network...
So I have two daemons: `c-lightning` and `LND`.

Channels from the `c-lightning` comes like this `505580x1917x1`;
Channels from the `LND` comes like this `556369376388317185`;

Is it possible to bring them to a single format? For example `c-lightning` convert to simple integer like `LND` in order to find same channels from both daemons?

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

> **Comments:**
> **username_1**: In the spec meeting in November it was agreed to make the format of the short channel Id part of the protocol. In future implementations should use the clightning format with `x` as a separator instead of `:` while colon was very readable the short channel ids that use x as a separator are doubleclickable.  

---

## 3 answers

### Answer by username_2 on 2018-09-20. Score: 8

The specification of the short_channel_id describes the format as follows:

The short_channel_id is the unique description of the funding transaction. It is constructed as follows:

the most significant 3 bytes: indicating the block height
the next 3 bytes: indicating the transaction index within the block
the least significant 2 bytes: indicating the output index that pays to the channel.


Hence to convert between the two formats you can use the following python snippets:
def lnd_to_cl_scid(s):
    block = s >> 40
    tx = s >> 16 & 0xFFFFFF
    output = s  & 0xFFFF
    return (block, tx, output)

def cl_to_lnd_scid(s):
    s = [int(i) for i in s.split('x')]
    return (s[0] << 40) | (s[1] << 16) | s[2]

The reason we (c-lightning) use the dotted format is because it allows us to look up the funding TX without having to do a conversion (and it usually is shorter than the u64 representation)


---

### Answer by username_3 on 2018-08-08. Score: 2

https://github.com/lightningnetwork/lnd/blob/8379bbaa9b259544c2c8591782a78d7384680b2a/lnwire/short_channel_id.go#L25-L43
// NewShortChanIDFromInt returns a new ShortChannelID which is the decoded
// version of the compact channel ID encoded within the uint64. The format of
// the compact channel ID is as follows: 3 bytes for the block height, 3 bytes
// for the transaction index, and 2 bytes for the output index.
func NewShortChanIDFromInt(chanID uint64) ShortChannelID {
    return ShortChannelID{
        BlockHeight: uint32(chanID >> 40),
        TxIndex:     uint32(chanID>>16) & 0xFFFFFF,
        TxPosition:  uint16(chanID),
    }
}

// ToUint64 converts the ShortChannelID into a compact format encoded within a
// uint64 (8 bytes).
func (c ShortChannelID) ToUint64() uint64 {
    // TODO(roasbeef): explicit error on overflow?
    return ((uint64(c.BlockHeight) << 40) | (uint64(c.TxIndex) << 16) |
        (uint64(c.TxPosition)))
}


---

### Answer by username_4 on 2024-10-18. Score: 0

I have the following function definition in my Bash profile:
scid() {
    local -i scid
    if (( ${#} )) ; then
        for scid ; do
            echo "$((scid >> 40))x$((scid >> 16 & 0xFFFFFF))x$((scid & 0xFFFF))"
        done
    else
        while read -r scid ; do
            scid "${scid}"
        done
    fi
}

This lets me conveniently convert those ugly LND-style short channel IDs into the standards-compliant format, either by passing them to the scid function as arguments or by piping them in, one per line:
$ scid 556369376388317185
506015x904x1
$ echo 556369376388317185 | scid
506015x904x1


---

