[Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network

Ugam Kamat ugamkamat1 at gmail.com
Mon Jan 27 07:50:02 UTC 2020


Hey Subhra – In order to have faith that the channel announced by the nodes is actually locked on the Bitcoin mainchain we need to have the outpoint (`txid` and `vout`) of the funding transaction. If we do not verify that the funding transaction has been confirmed, nodes can cheat us that a particular transaction is confirmed when it is not the case. As a result we require that nodes announce this information along with the public keys and the signatures of the public keys that was used to lock the funding transaction.

 

This information is broadcasted in the `channel_announcement` message in the `short_channel_id` field which includes the block number, transaction number and vout. Since Bitcoin does not allow confidential transactions, we can query the blockchain and find out the channel capacity even when the amounts are never explicitly mentioned. 

 

 

Ugam

 

From: Lightning-dev <lightning-dev-bounces at lists.linuxfoundation.org> On Behalf Of Subhra Mazumdar
Sent: Monday, January 27, 2020 12:45 PM
To: lightning-dev at lists.linuxfoundation.org
Subject: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network

 

Dear All,

         What can be the potential problem if a channel is opened whereby the channel capacity is not revealed publicly but just a range proof of the attribute (capacity >0 and capacity < value) is provided ? Will it pose a problem during routing of transaction ? What are the pros and cons ?

I think that revealing channel capacity make the channels susceptible to channel exhaustion attack or a particular node might be targeted for node isolation attack ? 


-- 

Yours sincerely,
Subhra Mazumdar.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200127/cf9b0f81/attachment-0001.html>


More information about the Lightning-dev mailing list