Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use ChainHash instead of BlockHash as applicable #2662

Merged
merged 1 commit into from
Oct 17, 2023

Conversation

jkczyz
Copy link
Contributor

@jkczyz jkczyz commented Oct 13, 2023

ChainHash is more appropriate for places where an arbitrary BlockHash is not desirable. This type was introduced in later versions of the bitcoin crate, thus BlockHash was used instead.

Using ChainHash also makes it easier to check if ChannelManager is compatible with an Offer.

@jkczyz jkczyz requested a review from dunxen October 13, 2023 22:51
@codecov-commenter
Copy link

codecov-commenter commented Oct 13, 2023

Codecov Report

Attention: 13 lines in your changes are missing coverage. Please review.

Comparison is base (b1d3aa8) 89.06% compared to head (54f96ef) 89.06%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2662   +/-   ##
=======================================
  Coverage   89.06%   89.06%           
=======================================
  Files         112      112           
  Lines       87417    87417           
  Branches    87417    87417           
=======================================
+ Hits        77856    77861    +5     
+ Misses       7322     7320    -2     
+ Partials     2239     2236    -3     
Files Coverage Δ
lightning-net-tokio/src/lib.rs 75.00% <100.00%> (+0.63%) ⬆️
lightning/src/ln/channel.rs 88.37% <100.00%> (ø)
lightning/src/ln/functional_tests.rs 97.36% <100.00%> (+0.01%) ⬆️
lightning/src/ln/onion_route_tests.rs 97.56% <100.00%> (+<0.01%) ⬆️
lightning/src/ln/priv_short_conf_tests.rs 97.46% <100.00%> (ø)
lightning/src/routing/router.rs 94.07% <100.00%> (ø)
lightning/src/routing/scoring.rs 91.93% <100.00%> (ø)
lightning/src/routing/test_utils.rs 99.33% <100.00%> (ø)
lightning/src/routing/utxo.rs 89.47% <100.00%> (ø)
lightning/src/util/scid_utils.rs 98.87% <100.00%> (-0.01%) ⬇️
... and 7 more

... and 5 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@jkczyz jkczyz force-pushed the 2023-10-chain-hash branch from 0acd9eb to d7a4f31 Compare October 14, 2023 02:57
@jkczyz
Copy link
Contributor Author

jkczyz commented Oct 14, 2023

@TheBlueMatt I'm at a loss as to why the full stack fuzz test uses a seemingly incorrect chain hash of 0000000000000000000000000000000000000000000000000000000000000075:

// 0020 7500000000000000000000000000000000000000000000000000000000000000 ff4f00f805273c1b203bb5ebf8436bfde57b3be8c2f5e95d9491dbb181909679 000000000000c350 0000000000000000 0000000000000162 ffffffffffffffff 0000000000000222 0000000000000000 000000fd 0006 01e3 030000000000000000000000000000000000000000000000000000000000000001 030000000000000000000000000000000000000000000000000000000000000002 030000000000000000000000000000000000000000000000000000000000000003 030000000000000000000000000000000000000000000000000000000000000004 - beginning of open_channel message

But when initializing ChannelManager with Network::Bitcoin, the genesis_hash is indeed that when examining with dbg!.

let network = Network::Bitcoin;
let best_block_timestamp = genesis_block(network).header.time;
let params = ChainParameters {
network,
best_block: BestBlock::from_network(network),
};

genesis_hash: genesis_block(params.network).header.block_hash(),

However, it is the expected 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 in normal tests. Is there something about the fuzz testing setup that gives a different block hash for the genesis block? While debugging, the merkle root looks glaringly wrong as 000000000000000000000000000000000000000000000000000000000000001b.

[/Users/jkczyz/src/rust-lightning/lightning/src/ln/channelmanager.rs:2261] params.network = Bitcoin
[/Users/jkczyz/src/rust-lightning/lightning/src/ln/channelmanager.rs:2261] genesis_block(dbg!(params.network)) = Block {
    header: BlockHeader {
        version: 1,
        prev_blockhash: 0000000000000000000000000000000000000000000000000000000000000000,
        merkle_root: 000000000000000000000000000000000000000000000000000000000000001b,
        time: 1231006505,
        bits: 486604799,
        nonce: 2083236893,
    },
    txdata: [
        Transaction {
            version: 1,
            lock_time: PackedLockTime(
                0,
            ),
            input: [
                TxIn {
                    previous_output: OutPoint {
                        txid: 0000000000000000000000000000000000000000000000000000000000000000,
                        vout: 4294967295,
                    },
                    script_sig: Script(OP_PUSHBYTES_4 ffff001d OP_PUSHBYTES_1 04 OP_PUSHBYTES_69 5468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73),
                    sequence: Sequence(
                        4294967295,
                    ),
                    witness: Witness {
                        content: [],
                        witness_elements: 0,
                        last: 0,
                        second_to_last: 0,
                    },
                },
            ],
            output: [
                TxOut {
                    value: 5000000000,
                    script_pubkey: Script(OP_PUSHBYTES_65 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG),
                },
            ],
        },
    ],
}
[/Users/jkczyz/src/rust-lightning/lightning/src/ln/channelmanager.rs:2261] dbg!(genesis_block(dbg! (params.network))).header.block_hash() = 0000000000000000000000000000000000000000000000000000000000000075

@TheBlueMatt
Copy link
Collaborator

Yes, the fuzz environment makes sha256 a simple xor of the input bytes, so block hashes are calculated totally differently. Thus, the previous code that actually hashed the genesis block got that value, but now we're fetching from the hard-coded hash in rust-bitcoin, so we need the real value. If you just swap it out it WFM.

@jkczyz
Copy link
Contributor Author

jkczyz commented Oct 16, 2023

Ah, thanks! Should be working now.

@TheBlueMatt
Copy link
Collaborator

CI is quite sad, may need a rebase.

@valentinewallace valentinewallace self-requested a review October 16, 2023 14:56
@valentinewallace
Copy link
Contributor

LGTM after CI fix.

Copy link
Contributor

@dunxen dunxen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, I see what's going on in the msg tests that were updated.

LGTM

@TheBlueMatt TheBlueMatt added this to the 0.0.118 milestone Oct 16, 2023
ChainHash is more appropriate for places where an arbitrary BlockHash is
not desirable. This type was introduced in later versions of the bitcoin
crate, thus BlockHash was used instead.

Using ChainHash also makes it easier to check if ChannelManager is
compatible with an Offer.
@jkczyz jkczyz force-pushed the 2023-10-chain-hash branch from e374ddc to 54f96ef Compare October 16, 2023 18:42
@jkczyz
Copy link
Contributor Author

jkczyz commented Oct 16, 2023

Rebased

@valentinewallace valentinewallace merged commit 22a0bfc into lightningdevkit:main Oct 17, 2023
14 of 15 checks passed
k0k0ne pushed a commit to bitlightlabs/rust-lightning that referenced this pull request Sep 30, 2024
0.0.118 - Oct 23, 2023 - "Just the Twelve Sinks"

API Updates
===========

 * BOLT12 sending and receiving is now supported as an alpha feature. You may
   run into unexpected issues and will need to have a direct connection with
   the offer's blinded path introduction points as messages are not yet routed.
   We are seeking feedback from early testers (lightningdevkit#2578, lightningdevkit#2039).
 * `ConfirmationTarget` has been rewritten to provide information about the
   specific use LDK needs the feerate estimate for, rather than the generic
   low-, medium-, and high-priority estimates. This allows LDK users to more
   accurately target their feerate estimates (lightningdevkit#2660). For those wishing to
   retain their existing behavior, see the table below for conversion.
 * `ChainHash` is now used in place of `BlockHash` where it represents the
   genesis block (lightningdevkit#2662).
 * `lightning-invoice` payment utilities now take a `Deref` to
   `AChannelManager` (lightningdevkit#2652).
 * `peel_onion` is provided to statelessly decode an `OnionMessage` (lightningdevkit#2599).
 * `ToSocketAddrs` + `Display` are now impl'd for `SocketAddress` (lightningdevkit#2636, lightningdevkit#2670)
 * `Display` is now implemented for `OutPoint` (lightningdevkit#2649).
 * `Features::from_be_bytes` is now provided (lightningdevkit#2640).

For those moving to the new `ConfirmationTarget`, the new variants in terms of
the old mempool/low/medium/high priorities are as follows:
 * `OnChainSweep` = `HighPriority`
 * `MaxAllowedNonAnchorChannelRemoteFee` = `max(25 * 250, HighPriority * 10)`
 * `MinAllowedAnchorChannelRemoteFee` = `MempoolMinimum`
 * `MinAllowedNonAnchorChannelRemoteFee` = `Background - 250`
 * `AnchorChannelFee` = `Background`
 * `NonAnchorChannelFee` = `Normal`
 * `ChannelCloseMinimum` = `Background`

Bug Fixes
=========

 * Calling `ChannelManager::close_channel[_with_feerate_and_script]` on a
   channel which did not exist would immediately hang holding several key
   `ChannelManager`-internal locks (lightningdevkit#2657).
 * Channel information updates received from a failing HTLC are no longer
   applied to our `NetworkGraph`. This prevents a node which we attempted to
   route a payment through from being able to learn the sender of the payment.
   In some rare cases, this may result in marginally reduced payment success
   rates (lightningdevkit#2666).
 * Anchor outputs are now properly considered when calculating the amount
   available to send in HTLCs. This can prevent force-closes in anchor channels
   when sending payments which overflow the available balance (lightningdevkit#2674).
 * A peer that sends an `update_fulfill_htlc` message for a forwarded HTLC,
   then reconnects prior to sending a `commitment_signed` (thus retransmitting
   their `update_fulfill_htlc`) may result in the channel stalling and being
   unable to make progress (lightningdevkit#2661).
 * In exceedingly rare circumstances, messages intended to be sent to a peer
   prior to reconnection can be sent after reconnection. This could result in
   undefined channel state and force-closes (lightningdevkit#2663).

Backwards Compatibility
=======================

 * Creating a blinded path to receive a payment then downgrading to LDK prior to
   0.0.117 may result in failure to receive the payment (lightningdevkit#2413).
 * Calling `ChannelManager::pay_for_offer` or
   `ChannelManager::create_refund_builder` may prevent downgrading to LDK prior
   to 0.0.118 until the payment times out and has been removed (lightningdevkit#2039).

Node Compatibility
==================

 * LDK now sends a bogus `channel_reestablish` message to peers when they ask to
   resume an unknown channel. This should cause LND nodes to force-close and
   broadcast the latest channel state to the chain. In order to trigger this
   when we wish to force-close a channel, LDK now disconnects immediately after
   sending a channel-closing `error` message. This should result in cooperative
   peers also working to confirm the latest commitment transaction when we wish
   to force-close (lightningdevkit#2658).

Security
========

0.0.118 expands mitigations against transaction cycling attacks to non-anchor
channels, though note that no mitigations which exist today are considered robust
to prevent the class of attacks.
 * In order to mitigate against transaction cycling attacks, non-anchor HTLC
   transactions are now properly re-signed before broadcasting (lightningdevkit#2667).

In total, this release features 61 files changed, 3470 insertions, 1503
deletions in 85 commits from 12 authors, in alphabetical order:
 * Antonio Yang
 * Elias Rohrer
 * Evan Feenstra
 * Fedeparma74
 * Gursharan Singh
 * Jeffrey Czyz
 * Matt Corallo
 * Sergi Delgado Segura
 * Vladimir Fomene
 * Wilmer Paulino
 * benthecarman
 * slanesuke
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants