smite-ir: implement RecvChannelReady operation#129
Conversation
| /// Receive and parse a `channel_ready` response. | ||
| /// | ||
| /// This is a no-op unless some tracked channel is awaiting `channel_ready` | ||
| /// (still at commitment number 0 with the counterparty's next per-commitment | ||
| /// point unknown) and its funding transaction has enough confirmations for | ||
| /// the target to have sent `channel_ready`. | ||
| RecvChannelReady, |
There was a problem hiding this comment.
The executor automatically handles the second_per_commitment_point internally, but would it still be valuable to output the ChannelReady object, or maybe just the alias field?
There was a problem hiding this comment.
I think we can output the alias field from the peer, but there are two issues:
- it is a tlv, so it may be absent
- the
RecvChannelReadyoperation itself can be a no-op in some cases if nochannel_readyis expected
So, if we want the output_type to be VariableType::ShortChannelId, we would need to output a default alias value whenever we are unable to extract one. Perhaps we could use the SCID 0 in those cases?
There was a problem hiding this comment.
Ah, yeah that's a bit ugly. We can figure it out later if we need it.
NishantBansal2003
force-pushed
the
recv-channel-ready
branch
from
740b316 to
2b9c25a
Compare
Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
NishantBansal2003
force-pushed
the
recv-channel-ready
branch
from
2b9c25a to
3389d10
Compare
morehouse
left a comment
morehouse
left a comment
There was a problem hiding this comment.
Ready to merge after squashing the fixup
| state.commitment.commitment_number == 0 | ||
| && state.next_counterparty_per_commitment_point().is_none() | ||
| && bitcoin_cli.get_transaction_confirmations(state.config.funding_outpoint.txid) | ||
| >= MAX_MINIMUM_DEPTH |
There was a problem hiding this comment.
In the future, once we start saving open_channel and accept_channel data, we could use the actual minimum_depth value from accept_channel instead.
| /// Receive and parse a `channel_ready` response. | ||
| /// | ||
| /// This is a no-op unless some tracked channel is awaiting `channel_ready` | ||
| /// (still at commitment number 0 with the counterparty's next per-commitment | ||
| /// point unknown) and its funding transaction has enough confirmations for | ||
| /// the target to have sent `channel_ready`. | ||
| RecvChannelReady, |
There was a problem hiding this comment.
Ah, yeah that's a bit ugly. We can figure it out later if we need it.
Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
NishantBansal2003
force-pushed
the
recv-channel-ready
branch
from
3389d10 to
1bf2364
Compare
2 participants
Depends-on: #128
Adds a
RecvChannelReadyoperation. Receivingchannel_readyfrom the target is different from other channel-opening messages: it is independent of whether we have sent our ownchannel_ready, and the target will only send it once the funding transaction has been broadcast and reached theminimum_depthrequested inaccept_channel.To handle this,
RecvChannelReadyis made conditional. When executed, it may either receive achannel_readyor do nothing. Achannel_readyis expected when a tracked channel is still at commitment number 0, the counterparty’s next per-commitment point is unknown, and the funding transaction has at least 8 confirmations. Since Lightning implementations typically use a default maximumminimum_depthof 8 inaccept_channel, reaching 8 confirmations guarantees the target has sent itschannel_ready