AwaitingRemoteRevoke = (1 << 7),
}
-// TODO: We should refactor this to be a Inbound/OutboundChannel until initial setup handshaking
+// TODO: We should refactor this to be an Inbound/OutboundChannel until initial setup handshaking
// has been completed, and then turn into a Channel to get compiler-time enforcement of things like
// calling get_channel_id() before we're set up or things like get_outbound_funding_signed on an
// inbound channel.
}
/// Handles a funding_signed message from the remote end.
- /// If this call is successfull, broadcast the funding transaction (and not before!)
+ /// If this call is successful, broadcast the funding transaction (and not before!)
pub fn funding_signed(&mut self, msg: &msgs::FundingSigned) -> Result<(), HandleError> {
if !self.channel_outbound {
return Err(HandleError{err: "Received funding_signed for an inbound channel?", msg: None});
}
//TODO: Note that this must be a duplicate of the previous commitment point they sent us,
- //as otherwise we will have a commitment transaction that they cant revoke (well, kinda,
+ //as otherwise we will have a commitment transaction that they can't revoke (well, kinda,
//they can by sending two revoke_and_acks back-to-back, but not really). This appears to be
//a protocol oversight, but I assume I'm just missing something.
if self.their_cur_commitment_point != msg.next_per_commitment_point {
self.funding_tx_confirmed_in = header.bitcoin_hash();
//TODO: Note that this must be a duplicate of the previous commitment point they sent us,
- //as otherwise we will have a commitment transaction that they cant revoke (well, kinda,
+ //as otherwise we will have a commitment transaction that they can't revoke (well, kinda,
//they can by sending two revoke_and_acks back-to-back, but not really). This appears to be
//a protocol oversight, but I assume I'm just missing something.
let next_per_commitment_secret = match self.build_local_commitment_secret(self.cur_local_commitment_transaction_number) {
/// Panics if called at some time other than immediately after initial handshake, if called twice,
/// or if called on an inbound channel.
/// Note that channel_id changes during this call!
- /// Do NOT broadcast the funding transaction until after a successfull funding_signed call!
+ /// Do NOT broadcast the funding transaction until after a successful funding_signed call!
pub fn get_outbound_funding_created(&mut self, funding_txid: Sha256dHash, funding_output_index: u16) -> Result<msgs::FundingCreated, HandleError> {
if !self.channel_outbound {
panic!("Tried to create outbound funding_created message on an inbound channel!");
chan.local_keys.payment_base_key = SecretKey::from_slice(&secp_ctx, &hex_bytes("1111111111111111111111111111111111111111111111111111111111111111").unwrap()[..]).unwrap();
chan.local_keys.delayed_payment_base_key = SecretKey::from_slice(&secp_ctx, &hex_bytes("3333333333333333333333333333333333333333333333333333333333333333").unwrap()[..]).unwrap();
chan.local_keys.htlc_base_key = SecretKey::from_slice(&secp_ctx, &hex_bytes("1111111111111111111111111111111111111111111111111111111111111111").unwrap()[..]).unwrap();
- // chan.local_keys.commitment_seed isnt derived in the test vectors :(
+ // chan.local_keys.commitment_seed isn't derived in the test vectors :(
chan.channel_monitor.set_funding_info(Sha256dHash::from_hex("8984484a580b825b9972d7adb15050b3ab624ccd731946b3eeddb92f4e7ef6be").unwrap(), 0);
for (i, keys) in onion_keys.iter().enumerate() {
if i == payloads.len() - 1 { continue; }
let mut chacha = ChaCha20::new(&keys.rho, &[0u8; 8]);
- chacha.process(&ChannelManager::ZERO, &mut buf); // We dont have a seek function :(
+ chacha.process(&ChannelManager::ZERO, &mut buf); // We don't have a seek function :(
ChannelManager::xor_bufs(&mut res[0..(i + 1)*65], &buf[(20 - i)*65..21*65]);
}
res
// will automatically handle building the update_add_htlc and
// commitment_signed messages when we can.
// TODO: Do some kind of timer to set the channel as !is_live()
- // as we dont really want others relying on us relaying through
+ // as we don't really want others relying on us relaying through
// this channel currently :/.
}
}
}
fn handle_funding_created(&self, their_node_id: &PublicKey, msg: &msgs::FundingCreated) -> Result<msgs::FundingSigned, HandleError> {
- //TODO: broke this - a node shouldnt be able to get their channel removed by sending a
+ //TODO: broke this - a node shouldn't be able to get their channel removed by sending a
//funding_created a second time, or long after the first, or whatever (note this also
//leaves the short_to_id map in a busted state.
let chan = {
}
fn handle_update_add_htlc(&self, their_node_id: &PublicKey, msg: &msgs::UpdateAddHTLC) -> Result<(), msgs::HandleError> {
- //TODO: BOLT 4 points out a specific attack where a peer may re-send a onion packet and
+ //TODO: BOLT 4 points out a specific attack where a peer may re-send an onion packet and
//determine the state of the payment based on our response/if we forward anything/the time
//we take to respond. We should take care to avoid allowing such an attack.
//
let associated_data = Vec::new(); //TODO: What to put here?
if msg.onion_routing_packet.version != 0 {
- //TODO: Spec doesnt indicate if we should only hash hop_data here (and in other
+ //TODO: Spec doesn't indicate if we should only hash hop_data here (and in other
//sha256_of_onion error data packets), or the entire onion_routing_packet. Either way,
//the hash doesn't really serve any purpuse - in the case of hashing all data, the
//receiving node would have to brute force to figure out which version was put in the
});
}
- // Note that we could obviously respond immediately with a update_fulfill_htlc
+ // Note that we could obviously respond immediately with an update_fulfill_htlc
// message, however that would leak that we are the recipient of this payment, so
// instead we stay symmetric with the forwarding case, only responding (after a
// delay) once they've send us a commitment_signed!
/// Provides an object which can be used to send data to and which uniquely identifies a connection
/// to a remote host. You will need to be able to generate multiple of these which meet Eq and
/// implement Hash to meet the PeerManager API.
-/// For effeciency, Clone should be relatively cheap for this type.
+/// For efficiency, Clone should be relatively cheap for this type.
/// You probably want to just extend an int and put a file descriptor in a struct and implement
/// send_data.
pub trait SocketDescriptor : cmp::Eq + hash::Hash + Clone {
Ordering::Less
} else if b.0.value < a.0.value {
Ordering::Greater
- } else if a.0.script_pubkey[..] < b.0.script_pubkey[..] { //TODO: ordering of scripts shouldnt be len-based
+ } else if a.0.script_pubkey[..] < b.0.script_pubkey[..] { //TODO: ordering of scripts shouldn't be len-based
Ordering::Less
- } else if b.0.script_pubkey[..] < a.0.script_pubkey[..] { //TODO: ordering of scripts shouldnt be len-based
+ } else if b.0.script_pubkey[..] < a.0.script_pubkey[..] { //TODO: ordering of scripts shouldn't be len-based
Ordering::Greater
} else {
Ordering::Equal
projects / rust-lightning / commitdiff