Merge pull request #301 from rex4539/fix-typos

Fix typos

Author: TheBlueMatt

.editorconfig

@@ -1,4 +1,4 @@
-# see https://editorconfig.org for more options, and setup instructions for yours editor
+# see https://editorconfig.org for more options, and setup instructions for your editor
 
 [*]
 indent_style = tab

src/chain/chaininterface.rs

@@ -2,7 +2,7 @@
 //! blockchain.
 //!
 //! Includes traits for monitoring and receiving notifications of new blocks and block
-//! disconnections, transactio broadcasting, and feerate information requests.
+//! disconnections, transaction broadcasting, and feerate information requests.
 
 use bitcoin::blockdata::block::{Block, BlockHeader};
 use bitcoin::blockdata::transaction::Transaction;
@@ -143,7 +143,7 @@ impl ChainWatchedUtil {
 		}
 		#[cfg(not(test))]
 		{
-			let _tx_unused = txid; // Its used in cfg(test), though
+			let _tx_unused = txid; // It's used in cfg(test), though
 			self.watched_txn.insert(script_pub_key.clone())
 		}
 	}
@@ -155,7 +155,7 @@ impl ChainWatchedUtil {
 		self.watched_outpoints.insert(outpoint)
 	}
 
-	/// Sets us to match all transactions, returning true if this is a new setting anf false if
+	/// Sets us to match all transactions, returning true if this is a new setting and false if
 	/// we'd already been set to match everything.
 	pub fn watch_all(&mut self) -> bool {
 		if self.watch_all { return false; }

src/lib.rs

@@ -4,7 +4,7 @@
 //!
 //! A full-featured but also flexible lightning implementation, in library form. This allows the
 //! user (you) to decide how they wish to use it instead of being a fully self-contained daemon.
-//! This means there is no built-in threading/execution environment and its up to the user to
+//! This means there is no built-in threading/execution environment and it's up to the user to
 //! figure out how best to make networking happen/timers fire/things get written to disk/keys get
 //! generated/etc. This makes it a good candidate for tight integration into an existing wallet
 //! instead of having a rather-separate lightning appendage to a wallet.

src/ln/channel.rs

@@ -93,14 +93,14 @@ enum OutboundHTLCState {
 	/// Added by us and included in a commitment_signed (if we were AwaitingRemoteRevoke when we
 	/// created it we would have put it in the holding cell instead). When they next revoke_and_ack
 	/// we will promote to Committed (note that they may not accept it until the next time we
-	/// revoke, but we dont really care about that:
+	/// revoke, but we don't really care about that:
 	///  * they've revoked, so worst case we can announce an old state and get our (option on)
-	///    money back (though we wont), and,
+	///    money back (though we won't), and,
 	///  * we'll send them a revoke when they send a commitment_signed, and since only they're
 	///    allowed to remove it, the "can only be removed once committed on both sides" requirement
-	///    doesn't matter to us and its up to them to enforce it, worst-case they jump ahead but
+	///    doesn't matter to us and it's up to them to enforce it, worst-case they jump ahead but
 	///    we'll never get out of sync).
-	/// Note that we Box the OnionPacket as its rather large and we don't want to blow up
+	/// Note that we Box the OnionPacket as it's rather large and we don't want to blow up
 	/// OutboundHTLCOutput's size just for a temporary bit
 	LocalAnnounced(Box<msgs::OnionPacket>),
 	Committed,
@@ -292,7 +292,7 @@ pub(super) struct Channel {
 	last_sent_closing_fee: Option<(u64, u64)>, // (feerate, fee)
 
 	/// The hash of the block in which the funding transaction reached our CONF_TARGET. We use this
-	/// to detect unconfirmation after a serialize-unserialize roudtrip where we may not see a full
+	/// to detect unconfirmation after a serialize-unserialize roundtrip where we may not see a full
 	/// series of block_connected/block_disconnected calls. Obviously this is not a guarantee as we
 	/// could miss the funding_tx_confirmed_in block as well, but it serves as a useful fallback.
 	funding_tx_confirmed_in: Option<Sha256dHash>,
@@ -551,7 +551,7 @@ impl Channel {
 			return Err(ChannelError::Close("Bogus; channel reserve is less than dust limit"));
 		}
 		if msg.htlc_minimum_msat >= (msg.funding_satoshis - msg.channel_reserve_satoshis) * 1000 {
-			return Err(ChannelError::Close("Miminum htlc value is full channel value"));
+			return Err(ChannelError::Close("Minimum htlc value is full channel value"));
 		}
 		Channel::check_remote_fee(fee_estimator, msg.feerate_per_kw)?;
 
@@ -1113,7 +1113,7 @@ impl Channel {
 	}
 
 	/// Signs a transaction created by build_htlc_transaction. If the transaction is an
-	/// HTLC-Success transaction (ie htlc.offered is false), preimate must be set!
+	/// HTLC-Success transaction (ie htlc.offered is false), preimage must be set!
 	fn sign_htlc_transaction(&self, tx: &mut Transaction, their_sig: &Signature, preimage: &Option<PaymentPreimage>, htlc: &HTLCOutputInCommitment, keys: &TxCreationKeys) -> Result<Signature, ChannelError> {
 		if tx.input.len() != 1 {
 			panic!("Tried to sign HTLC transaction that had input count != 1!");
@@ -1151,7 +1151,7 @@ impl Channel {
 	/// In such cases we debug_assert!(false) and return an IgnoreError. Thus, will always return
 	/// Ok(_) if debug assertions are turned on and preconditions are met.
 	fn get_update_fulfill_htlc(&mut self, htlc_id_arg: u64, payment_preimage_arg: PaymentPreimage) -> Result<(Option<msgs::UpdateFulfillHTLC>, Option<ChannelMonitor>), ChannelError> {
-		// Either ChannelFunded got set (which means it wont bet unset) or there is no way any
+		// Either ChannelFunded got set (which means it won't be unset) or there is no way any
 		// caller thought we could have something claimed (cause we wouldn't have accepted in an
 		// incoming HTLC anyway). If we got to ShutdownComplete, callers aren't allowed to call us,
 		// either.
@@ -1274,7 +1274,7 @@ impl Channel {
 					},
 					_ => {
 						debug_assert!(false, "Have an inbound HTLC we tried to claim before it was fully committed to");
-						return Err(ChannelError::Ignore("Unable to find a pending HTLC which matchd the given HTLC ID"));
+						return Err(ChannelError::Ignore("Unable to find a pending HTLC which matched the given HTLC ID"));
 					}
 				}
 				pending_idx = idx;
@@ -1352,10 +1352,10 @@ impl Channel {
 			return Err(ChannelError::Close("They wanted our payments to be delayed by a needlessly long period"));
 		}
 		if msg.max_accepted_htlcs < 1 {
-			return Err(ChannelError::Close("0 max_accpted_htlcs makes for a useless channel"));
+			return Err(ChannelError::Close("0 max_accepted_htlcs makes for a useless channel"));
 		}
 		if msg.max_accepted_htlcs > 483 {
-			return Err(ChannelError::Close("max_accpted_htlcs > 483"));
+			return Err(ChannelError::Close("max_accepted_htlcs > 483"));
 		}
 
 		// Now check against optional parameters as set by config...
@@ -1433,7 +1433,7 @@ impl Channel {
 		}
 		if self.channel_state != (ChannelState::OurInitSent as u32 | ChannelState::TheirInitSent as u32) {
 			// BOLT 2 says that if we disconnect before we send funding_signed we SHOULD NOT
-			// remember the channel, so its safe to just send an error_message here and drop the
+			// remember the channel, so it's safe to just send an error_message here and drop the
 			// channel.
 			return Err(ChannelError::Close("Received funding_created after we got the channel!"));
 		}
@@ -1826,8 +1826,8 @@ impl Channel {
 			for htlc_update in htlc_updates.drain(..) {
 				// Note that this *can* fail, though it should be due to rather-rare conditions on
 				// fee races with adding too many outputs which push our total payments just over
-				// the limit. In case its less rare than I anticipate, we may want to revisit
-				// handling this case better and maybe fufilling some of the HTLCs while attempting
+				// the limit. In case it's less rare than I anticipate, we may want to revisit
+				// handling this case better and maybe fulfilling some of the HTLCs while attempting
 				// to rebalance channels.
 				if err.is_some() { // We're back to AwaitingRemoteRevoke (or are about to fail the channel)
 					self.holding_cell_htlc_updates.push(htlc_update);
@@ -1869,8 +1869,8 @@ impl Channel {
 					}
 				}
 			}
-			//TODO: Need to examine the type of err - if its a fee issue or similar we may want to
-			//fail it back the route, if its a temporary issue we can ignore it...
+			//TODO: Need to examine the type of err - if it's a fee issue or similar we may want to
+			//fail it back the route, if it's a temporary issue we can ignore it...
 			match err {
 				None => {
 					if update_add_htlcs.is_empty() && update_fulfill_htlcs.is_empty() && update_fail_htlcs.is_empty() && self.holding_cell_update_fee.is_none() {
@@ -2022,7 +2022,7 @@ impl Channel {
 			}
 		} else {
 			if let Some(feerate) = self.pending_update_fee {
-				// Because a node cannot send two commitment_signed's in a row without getting a
+				// Because a node cannot send two commitment_signeds in a row without getting a
 				// revoke_and_ack from us (as it would otherwise not know the per_commitment_point
 				// it should use to create keys with) and because a node can't send a
 				// commitment_signed without changes, checking if the feerate is equal to the
@@ -2479,7 +2479,7 @@ impl Channel {
 		assert_eq!(self.channel_state & ChannelState::ShutdownComplete as u32, 0);
 
 		// BOLT 2 says we must only send a scriptpubkey of certain standard forms, which are up to
-		// 34 bytes in length, so dont let the remote peer feed us some super fee-heavy script.
+		// 34 bytes in length, so don't let the remote peer feed us some super fee-heavy script.
 		if self.channel_outbound && msg.scriptpubkey.len() > 34 {
 			return Err(ChannelError::Close("Got shutdown_scriptpubkey of absurd length from remote peer"));
 		}
@@ -3119,7 +3119,7 @@ impl Channel {
 	/// waiting on the remote peer to send us a revoke_and_ack during which time we cannot add new
 	/// HTLCs on the wire or we wouldn't be able to determine what they actually ACK'ed.
 	/// You MUST call send_commitment prior to any other calls on this Channel
-	/// If an Err is returned, its a ChannelError::Ignore!
+	/// If an Err is returned, it's a ChannelError::Ignore!
 	pub fn send_htlc(&mut self, amount_msat: u64, payment_hash: PaymentHash, cltv_expiry: u32, source: HTLCSource, onion_routing_packet: msgs::OnionPacket) -> Result<Option<msgs::UpdateAddHTLC>, ChannelError> {
 		if (self.channel_state & (ChannelState::ChannelFunded as u32 | BOTH_SIDES_SHUTDOWN_MASK)) != (ChannelState::ChannelFunded as u32) {
 			return Err(ChannelError::Ignore("Cannot send HTLC until channel is fully established and we haven't started shutting down"));
@@ -3376,7 +3376,7 @@ impl Channel {
 		}, dropped_outbound_htlcs))
 	}
 
-	/// Gets the latest commitment transaction and any dependant transactions for relay (forcing
+	/// Gets the latest commitment transaction and any dependent transactions for relay (forcing
 	/// shutdown of this channel - no more calls into this Channel may be made afterwards except
 	/// those explicitly stated to be allowed after shutdown completes, eg some simple getters).
 	/// Also returns the list of payment_hashes for channels which we can safely fail backwards
@@ -3930,7 +3930,7 @@ mod tests {
 	#[test]
 	fn test_max_funding_satoshis() {
 		assert!(MAX_FUNDING_SATOSHIS <= 21_000_000 * 100_000_000,
-		        "MAX_FUNDING_SATOSHIS is greater than all satoshis on existence");
+		        "MAX_FUNDING_SATOSHIS is greater than all satoshis in existence");
 	}
 
 	struct Keys {

src/ln/channelmanager.rs

@@ -249,7 +249,7 @@ pub(super) struct ChannelHolder {
 	pub(super) next_forward: Instant,
 	/// short channel id -> forward infos. Key of 0 means payments received
 	/// Note that while this is held in the same mutex as the channels themselves, no consistency
-	/// guarantees are made about there existing a channel with the short id here, nor the short
+	/// guarantees are made about the existence of a channel with the short id here, nor the short
 	/// ids in the PendingForwardHTLCInfo!
 	pub(super) forward_htlcs: HashMap<u64, Vec<HTLCForwardInfo>>,
 	/// Note that while this is held in the same mutex as the channels themselves, no consistency
@@ -344,7 +344,7 @@ pub struct ChannelManager {
 /// HTLC's CLTV. This should always be a few blocks greater than channelmonitor::CLTV_CLAIM_BUFFER,
 /// ie the node we forwarded the payment on to should always have enough room to reliably time out
 /// the HTLC via a full update_fail_htlc/commitment_signed dance before we hit the
-/// CLTV_CLAIM_BUFFER point (we static assert that its at least 3 blocks more).
+/// CLTV_CLAIM_BUFFER point (we static assert that it's at least 3 blocks more).
 const CLTV_EXPIRY_DELTA: u16 = 6 * 12; //TODO?
 pub(super) const CLTV_FAR_FAR_AWAY: u32 = 6 * 24 * 7; //TODO?
 
@@ -744,7 +744,7 @@ impl ChannelManager {
 		if msg.onion_routing_packet.version != 0 {
 			//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
+			//the hash doesn't really serve any purpose - in the case of hashing all data, the
 			//receiving node would have to brute force to figure out which version was put in the
 			//packet by the node that send us the message, in the case of hashing the hop_data, the
 			//node knows the HMAC matched, so they already know what is there...
@@ -1146,7 +1146,7 @@ impl ChannelManager {
 
 	/// Processes HTLCs which are pending waiting on random forward delay.
 	///
-	/// Should only really ever be called in response to an PendingHTLCsForwardable event.
+	/// Should only really ever be called in response to a PendingHTLCsForwardable event.
 	/// Will likely generate further events.
 	pub fn process_pending_htlc_forwards(&self) {
 		let _ = self.total_consistency_lock.read().unwrap();
@@ -1251,7 +1251,7 @@ impl ChannelManager {
 										// messages when we can.
 										// We don't need any kind of timer here as they should fail
 										// the channel onto the chain if they can't get our
-										// update_fail_htlc in time, its not our problem.
+										// update_fail_htlc in time, it's not our problem.
 									}
 								}
 							},
@@ -1480,7 +1480,7 @@ impl ChannelManager {
 					None => {
 						// TODO: There is probably a channel manager somewhere that needs to
 						// learn the preimage as the channel already hit the chain and that's
-						// why its missing.
+						// why it's missing.
 						return
 					}
 				};
@@ -1490,7 +1490,7 @@ impl ChannelManager {
 					Ok((msgs, monitor_option)) => {
 						if let Some(chan_monitor) = monitor_option {
 							if let Err(_e) = self.monitor.add_update_monitor(chan_monitor.get_funding_txo().unwrap(), chan_monitor) {
-								unimplemented!();// but def dont push the event...
+								unimplemented!();// but def don't push the event...
 							}
 						}
 						if let Some((msg, commitment_signed)) = msgs {
@@ -1548,7 +1548,7 @@ impl ChannelManager {
 								// knowledge of those gets moved into the appropriate in-memory
 								// ChannelMonitor and they get failed backwards once we get
 								// on-chain confirmations.
-								// Note I think #198 addresses this, so once its merged a test
+								// Note I think #198 addresses this, so once it's merged a test
 								// should be written.
 								if let Some(short_id) = channel.get_short_channel_id() {
 									short_to_id.remove(&short_id);
@@ -1848,7 +1848,7 @@ impl ChannelManager {
 		//
 		//TODO: There exists a further attack where a node may garble the onion data, forward it to
 		//us repeatedly garbled in different ways, and compare our error messages, which are
-		//encrypted with the same key. Its not immediately obvious how to usefully exploit that,
+		//encrypted with the same key. It's not immediately obvious how to usefully exploit that,
 		//but we should prevent it anyway.
 
 		let (mut pending_forward_info, mut channel_state_lock) = self.decode_update_add_htlc_onion(msg);
@@ -2272,7 +2272,7 @@ impl ChannelManager {
 
 impl events::MessageSendEventsProvider for ChannelManager {
 	fn get_and_clear_pending_msg_events(&self) -> Vec<events::MessageSendEvent> {
-		// TODO: Event release to users and serialization is currently race-y: its very easy for a
+		// TODO: Event release to users and serialization is currently race-y: it's very easy for a
 		// user to serialize a ChannelManager with pending events in it and lose those events on
 		// restart. This is doubly true for the fail/fulfill-backs from monitor events!
 		{
@@ -2297,7 +2297,7 @@ impl events::MessageSendEventsProvider for ChannelManager {
 
 impl events::EventsProvider for ChannelManager {
 	fn get_and_clear_pending_events(&self) -> Vec<events::Event> {
-		// TODO: Event release to users and serialization is currently race-y: its very easy for a
+		// TODO: Event release to users and serialization is currently race-y: it's very easy for a
 		// user to serialize a ChannelManager with pending events in it and lose those events on
 		// restart. This is doubly true for the fail/fulfill-backs from monitor events!
 		{
@@ -2897,7 +2897,7 @@ pub struct ChannelManagerReadArgs<'a> {
 	/// value.get_funding_txo() should be the key).
 	///
 	/// If a monitor is inconsistent with the channel state during deserialization the channel will
-	/// be force-closed using the data in the channelmonitor and the Channel will be dropped. This
+	/// be force-closed using the data in the ChannelMonitor and the channel will be dropped. This
 	/// is true for missing channels as well. If there is a monitor missing for which we find
 	/// channel data Err(DecodeError::InvalidValue) will be returned.
 	///