Skip to content

Commit

Permalink
Fix typos
Browse files Browse the repository at this point in the history
  • Loading branch information
@rex4539
rex4539 committed Jan 24, 2019
1 parent e79b98d commit ab10b05
Show file tree
Hide file tree
Showing 13 changed files with 81 additions and 81 deletions.
2 changes: 1 addition & 1 deletion .editorconfig
View file
Original file line number Diff line number Diff line change
@@ -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
6 changes: 3 additions & 3 deletions src/chain/chaininterface.rs
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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;
Expand Down Expand Up @@ -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())
}
}
Expand All @@ -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; }
Expand Down
2 changes: 1 addition & 1 deletion src/lib.rs
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
42 changes: 21 additions & 21 deletions src/ln/channel.rs
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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,
Expand Down Expand Up @@ -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>,
Expand Down Expand Up @@ -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)?;

Expand Down Expand Up @@ -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!");
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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;
Expand Down Expand Up @@ -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...
Expand Down Expand Up @@ -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!"));
}
Expand Down Expand Up @@ -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);
Expand Down Expand Up @@ -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() {
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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"));
}
Expand Down Expand Up @@ -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"));
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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 {
Expand Down
24 changes: 12 additions & 12 deletions src/ln/channelmanager.rs
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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?

Expand Down Expand Up @@ -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...
Expand Down Expand Up @@ -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();
Expand Down Expand Up @@ -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.
}
}
},
Expand Down Expand Up @@ -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
}
};
Expand All @@ -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 {
Expand Down Expand Up @@ -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);
Expand Down Expand Up @@ -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);
Expand Down Expand Up @@ -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!
{
Expand All @@ -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!
{
Expand Down Expand Up @@ -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.
///
Expand Down
Loading

0 comments on commit ab10b05

Please sign in to comment.