noBody𓅦🧱 on Nostr: Semisol 👨💻 Carman 🏴☠ Tony or any lightning devs able to weigh in on ...
Semisol 👨💻 (npub1226…grkj) Carman 🏴☠ (npub1u8l…turz) Tony (npub1t0n…jgqv) or any lightning devs able to weigh in on this?
TLDR of context: why can’t we just make an on-chain “invoice” (address with amount) with some kind of script or signature from the lightning node to open an outbound channel from any funding source directly?
Rather than 1) funding the node on-chain, and then 2) opening the channel on-chain
TLDR of context: why can’t we just make an on-chain “invoice” (address with amount) with some kind of script or signature from the lightning node to open an outbound channel from any funding source directly?
Rather than 1) funding the node on-chain, and then 2) opening the channel on-chain
quoting note1vvp…6gtgMy smart friends are mostly asleep so here is (the relevant prt of) what chatgpt says:
>
Your suggestion is about combining these steps into a single on-chain transaction. Ideally, this would involve creating an "invoice" or a contract that, when funded, automatically initializes a Lightning channel with the specified node. This would reduce the number of on-chain transactions (and thus fees) required to fund a Lightning channel.
There are a few reasons why this isn't currently standard practice:
1. **Technical Complexity**: Implementing a system where a single on-chain transaction can directly open a Lightning channel requires significant changes to how Lightning nodes operate and interact with the Bitcoin blockchain.
2. **Security Concerns**: Automatically opening channels based on received funds could introduce new security vulnerabilities, requiring careful design to prevent exploits.
3. **Protocol Limitations**: The current Bitcoin and Lightning Network protocols may not support such a feature directly, and introducing it could require substantial protocol upgrades or changes.
4. **Node Operation and Control**: Allowing automatic channel creation might reduce the control node operators have over their channel management, which can be crucial for effective routing and liquidity management.
5. **Network Standards and Compatibility**: For such a feature to be effective, it would need to be widely adopted and standardized across the Lightning Network, requiring coordination and agreement among developers and node operators.
The high fees due to activities like ordinal inscriptions are indeed a concern for Bitcoin users. Unfortunately, until the network evolves to allow more efficient use of block space or until the hype around activities that consume a lot of block space subsides, users may have to contend with these high fees. The suggestion you've made is interesting and could be a valuable area for future development in the Lightning Network ecosystem.
<
I haven’t read it all yet, i got illiterately excited to share it with you