Comments (9)
Tagging good first issue in case someone new comes around - you just need to check for the initial_routing_sync flag in the first Init message we receive from a peer in peer_handler.rs, then get a list of channels/nodes/channel_updates out of the Router (via some new API), then dump those into the socket. For now dont worry about filling up the socket's outbound buffer which is a potential DoS issue but not much we can do about that right now.
from rust-lightning.
Bolt 7 specifies :
Proving the existence of a channel between node_1 and node_2 requires:
proving that the funding transaction pays to bitcoin_key_1 and bitcoin_key_2
proving that node_1 owns bitcoin_key_1
proving that node_2 owns bitcoin_key_2
But I cant seem to find that we store bitcoin_key_1 or bitcoin_key_2 anywhere. Am I missing this?
from rust-lightning.
As my understanding, from the following paragraph in the spec, the receiver of the message locate the transaction output on the blockchain using short_channel_id and parse P2WSH to extract pubkey1 and pubkey2.
from rust-lightning.
As far as l have it you still need to know them as you need to fill in the message, the receiver then verifies that they exist?
But I have seen that channel already has a function to calculate this, but do you have to send only your channels, or all known channels?
from rust-lightning.
ah sorry, stupid answer.
Regarding the second,
upon receiving an init message with the initial_routing_sync flag set to 1:
SHOULD send gossip messages for all known channels and nodes, as if they were just received.
Also, TheBlueMatt says
... routing table dump in initial_routing_sync ...
from rust-lightning.
Ah, you are right. it may be better to keep bitcoin_keys in channel_announcemnet msg to easily re-construct messages later during initial_routing_sync.
from rust-lightning.
thats the route I currently followed
The node announcements message is also confusing me, as spec says:
MUST set signature to the signature of the double-SHA256 of the entire remaining packet after signature (using the key given by node_id).
But we dont have their private key? Either we must save those messages we receive or we should only send out a node announcement for ourself?
The same problem is with channel_annoucment messages., we need both to parties to sign a channel message, we cant send out channel announcements for channels we dont own, even if we are part of a channel we need the other party to sign as well. . We need the secret keys.
Currently I am leaning towards just "caching" all node and channel announcement messages so we can just send them out again.
from rust-lightning.
Think we can keep their - (not our or our peers') signatures?
For our channels, announcement_signatures to get peers'.
Regarding caching the messages themselves, I'm not so sure. If we cache them, we will have an extra burden to keep them synchronized with our internal network map Instead of having a single state repository and generating messages at will -- just a knee-jerk reaction, though.
from rust-lightning.
Oops, think this was resolved by #202/#247.
from rust-lightning.
Related Issues (20)
- Ignore ChannelUpdate entirely in onion failures
- [Memory] Persist `counterparty_claimable_outpoints` out of channel_monitor HOT 2
- Async Persistence TODOs HOT 1
- Drop the `Writeable` bound on channel signers entirely
- Batching of HTLC transactions for anchor output channels HOT 3
- BOLT12 support for Fedimint
- Upgrade `esplora-client` to 0.7 HOT 1
- Assume variable length onion, data loss protect, and static remotekey
- Gossip never seems to get a full take from Eclair/CLN
- `ChannelManager::accept_inbound_channel` doesn't reject channel on error
- `OffersMessageHandler` impl for `ChannelManager` accesses time HOT 1
- Upgrade to `rust-bitcoin` 0.32 HOT 4
- `peer_disconnected` event processing isn't robust if a peer_connected Errs
- Don't modify `ChannelMonitor`s during `ChannelManager` load
- `handling_channel_announcements` is flaky on windows HOT 1
- Blinded Paths are probe-able HOT 9
- Use cargo's new built-in cfg flag list
- Persist `ChannelMonitor` after first setting `balances_empty_height` in `archive_fully_resolved_channel_monitors`
- Improve docs for `Persist::archive_persisted_channel`
- Consider removing `path_id` from `Responder`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rust-lightning.