<blockquote>
  <p>wouldn't it be possible to parse the blockchain for all live payment channels to create a complete, up-to-date map of the Network so that you do not have to use flooding or beacons on the Network itself?</p>
</blockquote>

<p>No because it is not possible to know which transactions are related to a payment channel opening, and channel closing transactions can be ambiguous. The funding transaction sends money to a 2-of-2 multisig, but these are in outputs as a P2WSH or P2SH-P2WSH script which means that the redeemScript that specifies the 2-of-2 are not known. You cannot assume that any P2WSH or P2SH (because a P2SH-P2WSH looks just like a P2SH) is for funding a payment channel.</p>

<p>For closing transactions, if there is a cooperative close, then the spend of the funding transaction's outputs will look just like a normal 2-of-2 multisig, which is not indicative of a payment channel. In a unliateral close, you would be able to identify the unilateral close only after the person closing the channel spends their output.</p>

CC BY-SA 4.0
2018-05-08T23:42:27.113Z
2018-05-08T23:42:27.113Z
Ava Chow
<p>Researching about the available routing algorithms for the Bitcoin Lightning Network, I have been reading <a href="http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf" rel="nofollow noreferrer">the Flare whitepaper</a>, and this idea/question came to mind:</p>

<p>Since all payment channels are created with a blockchain transaction, and Flare itself checks the Blockchain to see if a channel is live or has been closed, wouldn't it be possible to parse the blockchain for all live payment channels to create a complete, up-to-date map of the Network so that you do not have to use flooding or beacons on the Network itself?</p>

<p>Do/can on-chain transactions that create the payment channel store nodes' ids? If yes, then this seems a trivial and maybe effective tactic.</p>

CC BY-SA 3.0
2018-02-19T08:55:38.000Z
You can add data to the blockchain, like IP address or node name, yes. This would lead to a bloat of the blockchain, where everyone is already complaining about it's size ... Then the client would also have to parse the blockchain, to find it's counterparty? Maybe this is a good point for a discussion in bitcointalk.org? I have seen several lightning threads there ...
pebwindkraft
<lightning-network><lightning-routing>
Mapping the Bitcoin Lightning Network: Why not use the Blockchain?
S34W0LF
# Mapping the Bitcoin Lightning Network: Why not use the Blockchain?

(Asked by: username_0 on 2018-02-17)

Researching about the available routing algorithms for the Bitcoin Lightning Network, I have been reading [the Flare whitepaper](http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf), and this idea/question came to mind:

Since all payment channels are created with a blockchain transaction, and Flare itself checks the Blockchain to see if a channel is live or has been closed, wouldn't it be possible to parse the blockchain for all live payment channels to create a complete, up-to-date map of the Network so that you do not have to use flooding or beacons on the Network itself?

Do/can on-chain transactions that create the payment channel store nodes' ids? If yes, then this seems a trivial and maybe effective tactic.

**Tags:** lightning-network, lightning-routing

> **Comments:**
> **username_1**: You can add data to the blockchain, like IP address or node name, yes. This would lead to a bloat of the blockchain, where everyone is already complaining about it's size ... Then the client would also have to parse the blockchain, to find it's counterparty? Maybe this is a good point for a discussion in bitcointalk.org? I have seen several lightning threads there ...  

---

## 1 answers

### Answer by username_2 on 2018-05-08. Score: 1

> wouldn't it be possible to parse the blockchain for all live payment channels to create a complete, up-to-date map of the Network so that you do not have to use flooding or beacons on the Network itself?

No because it is not possible to know which transactions are related to a payment channel opening, and channel closing transactions can be ambiguous. The funding transaction sends money to a 2-of-2 multisig, but these are in outputs as a P2WSH or P2SH-P2WSH script which means that the redeemScript that specifies the 2-of-2 are not known. You cannot assume that any P2WSH or P2SH (because a P2SH-P2WSH looks just like a P2SH) is for funding a payment channel.

For closing transactions, if there is a cooperative close, then the spend of the funding transaction's outputs will look just like a normal 2-of-2 multisig, which is not indicative of a payment channel. In a unliateral close, you would be able to identify the unilateral close only after the person closing the channel spends their output.


---

