Merge pull request #2 from practicalswift/typos

Fix typos
This commit is contained in:
Matt Corallo 2018-02-28 15:09:01 -05:00 committed by GitHub
commit f2eadb0261
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 15 additions and 15 deletions

View file

@ -154,7 +154,7 @@ enum ChannelState {
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.
@ -897,7 +897,7 @@ impl 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});
@ -933,7 +933,7 @@ impl Channel {
}
//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 {
@ -1333,7 +1333,7 @@ impl Channel {
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) {
@ -1466,7 +1466,7 @@ impl Channel {
/// 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!");
@ -1694,7 +1694,7 @@ mod tests {
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);

View file

@ -297,7 +297,7 @@ impl ChannelManager {
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
@ -557,7 +557,7 @@ impl ChannelManager {
// 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 :/.
}
}
@ -737,7 +737,7 @@ impl ChannelMessageHandler for ChannelManager {
}
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 = {
@ -814,7 +814,7 @@ impl ChannelMessageHandler for ChannelManager {
}
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.
//
@ -829,7 +829,7 @@ impl ChannelMessageHandler for ChannelManager {
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
@ -919,7 +919,7 @@ impl ChannelMessageHandler for ChannelManager {
});
}
// 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!

View file

@ -20,7 +20,7 @@ pub struct MessageHandler {
/// 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 {

View file

@ -8,9 +8,9 @@ pub fn sort_outputs<T>(outputs: &mut Vec<(TxOut, T)>) { //TODO: Make static and
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