Add config support for 'their_channel_reserve_proportional_millionths' [#1498] #1619

G8XSU · 2022-07-15T04:46:24Z

Add configuration support for 'their_channel_reserve_satoshis' [#1498] while channel open/accept

`their_channel_reserve_satoshis` is the minimum amount that the other node is to keep as a direct payment.
This ensures that if our counterparty broadcasts a revoked state, we can punish them by
claiming at least this value on chain.

`their_channel_reserve_proportion_millionth` is for us to configure counterparty's channel reserve
for both outgoing and incoming channels.

channel_reserve values greater than 30% could be considered highly unreasonable, since that
amount can never be used for payments.
Also, if our selected channel_reserve for counterparty and counterparty's selected channel_reserve
for us, sum upto or greater than channel_value, channel negotiations will fail.

`their_channel_reserve_proportion_millionth` is millionths of a channel_value to use as `their_channel_reserve_satoshis`.

Default Value is 1% of channel_value, configured as 10,000 millionth
Lower Bound on `their_channel_reserve_satoshis` is 1000 sats provided as safe implementation limit.
Max `their_channel_reserve_satoshis` can be equal to channel_value i.e 1000,000 millionth
but negotiations will fail in that case.

Closes #1498
Closes #1619

codecov-commenter · 2022-07-15T05:17:48Z

Codecov Report

Merging #1619 (e0fd959) into main (f75b6cb) will decrease coverage by 0.05%.
The diff coverage is 98.27%.

❗ Current head e0fd959 differs from pull request most recent head 092d1c1. Consider uploading reports for the commit 092d1c1 to get more accurate results

@@            Coverage Diff             @@
##             main    #1619      +/-   ##
==========================================
- Coverage   90.84%   90.78%   -0.06%     
==========================================
  Files          80       80              
  Lines       44675    44690      +15     
  Branches    44675    44690      +15     
==========================================
- Hits        40583    40571      -12     
- Misses       4092     4119      +27

Impacted Files	Coverage Δ
lightning-background-processor/src/lib.rs	`95.20% <ø> (ø)`
lightning/src/util/config.rs	`66.66% <0.00%> (-0.78%)`	⬇️
lightning/src/ln/channel.rs	`88.93% <100.00%> (+0.14%)`	⬆️
lightning/src/ln/functional_tests.rs	`96.87% <100.00%> (-0.07%)`	⬇️
lightning/src/ln/functional_test_utils.rs	`93.51% <0.00%> (-1.74%)`	⬇️
lightning/src/ln/payment_tests.rs	`98.57% <0.00%> (-0.32%)`	⬇️
lightning-net-tokio/src/lib.rs	`76.85% <0.00%> (-0.31%)`	⬇️
lightning/src/routing/router.rs	`92.44% <0.00%> (-0.09%)`	⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f75b6cb...092d1c1. Read the comment docs.

ViktorTigerstrom

Nice, generally the code looks good :)! I've yet to review the tests though.
I've left a few suggestions of improvements below.

ViktorTigerstrom · 2022-07-15T11:29:25Z

lightning/src/ln/channel.rs

@@ -795,6 +796,8 @@ pub const MAX_CHAN_DUST_LIMIT_SATOSHIS: u64 = MAX_STD_OUTPUT_DUST_LIMIT_SATOSHIS
 /// See https://github.com/lightning/bolts/issues/905 for more details.
 pub const MIN_CHAN_DUST_LIMIT_SATOSHIS: u64 = 354;

+pub const MIN_THEIR_CHAN_RESERVE_SATOSHIS: u64 = 1000;


This should have some docs, including explaining why 1000 was chosen.

I don't have an exact answer for this, current minimum was 1000, i just extracted it to constant and made it bit more explicit.
I think its just a reasonable value greater than dust limit.

lightning/src/ln/channel.rs

ViktorTigerstrom · 2022-07-15T11:35:53Z

lightning/src/ln/channel.rs

+	/// This is used both for outgoing and incoming channels and has lower bound of `MIN_THEIR_CHAN_RESERVE_SATOSHIS`
+	pub(crate) fn get_holder_selected_channel_reserve_satoshis(channel_value_satoshis: u64, config: &UserConfig) -> u64 {
+		let their_channel_reserve_proportion = (config.channel_handshake_config.their_channel_reserve_proportion_millionth as f64) / 1000_000.0;
+		let calculated_reserve = their_channel_reserve_proportion.mul(channel_value_satoshis as f64) as u64;


As pointed out by CI, I recommend using * instead of the mul function, and simply doing something like:

Suggested change

let calculated_reserve = their_channel_reserve_proportion.mul(channel_value_satoshis as f64) as u64;

let calculated_reserve = their_channel_reserve_proportion * channel_value_satoshis as f64;

cmp::min(channel_value_satoshis, cmp::max(calculated_reserve as u64, MIN_THEIR_CHAN_RESERVE_SATOSHIS))`

will be using

let calculated_reserve = channel_value_satoshis.saturating_mul(config.channel_handshake_config.their_channel_reserve_proportion_millionth as u64) / 1000_000;

to avoid floating point arithmetic.

lightning/src/ln/channel.rs

lightning/src/util/config.rs

ViktorTigerstrom · 2022-07-15T12:31:02Z

lightning/src/util/config.rs

+	///
+	/// Default Value is 1% of channel_value, configured as 10,000 millionth
+	/// Lower Bound on `their_channel_reserve_satoshis` is 1000 sats provided as safe implementation limit.
+	/// Max `their_channel_reserve_satoshis` can be equal to channel_value i.e 1000,000 millionth


I find it very strange that the range is upper bound to value that is guaranteed to fail. If that's the case, then why is it even upper bound at all?
If we want to have an upper bound, wouldn't we at least want make the bound a value that's more likely to succeed?

yes the idea was to handle unreasonable reserve configs by docs, because technically even a 99.99% reserve might work. and 60-30 channel_reserve b/w parties is unreasonable but valid.

Ok I still find it a bit strange to bound the value to an upper bound that's guaranteed to fail, instead of just not having any bound at all and just let the channel negotiations fail if the user sets a too high value. But if others are ok with it, I am as well :).

lightning/src/util/config.rs

lightning/src/ln/channel.rs

TheBlueMatt

Thanks for tackling this!

lightning/src/ln/channel.rs

TheBlueMatt

LGTM. some grammar and style nits, but code looks right.

lightning/src/util/config.rs

ViktorTigerstrom

Tests looks good!
LGTM except a few nits.

lightning/src/util/config.rs

lightning/src/ln/channel.rs

TheBlueMatt

LGTM, mod one existing bug that we might as well fix here. Please also keep your commit messages to 70-80 chars long, including the title (I know, gotta get good at the twitter-style summaries that lose context for titles...)

TheBlueMatt · 2022-07-19T01:24:41Z

lightning/src/util/config.rs

+	/// channel_reserve values greater than 30% could be considered highly unreasonable, since that
+	/// amount can never be used for payments.
+	/// Also, if our selected channel_reserve for counterparty and counterparty's selected
+	/// channel_reserve for us, sum upto or greater than channel_value, channel negotiations will fail.


Oops, looks like this isn't actually true for outbound channels lol. Should probably fix that - the full_channel_value test in new_from_req should just be copied into accept_channel.

the check is already present in accept_channel which behaves similarly, channel.rs:2022

if msg.channel_reserve_satoshis > self.channel_value_satoshis - self.holder_selected_channel_reserve_satoshis { return Err(ChannelError::Close(format!("Bogus channel_reserve_satoshis ({}). Must not be greater than channel value minus our reserve ({})", msg.channel_reserve_satoshis, self.channel_value_satoshis - self.holder_selected_channel_reserve_satoshis))); }

tnull

Some doc nits and suggestions.

lightning/src/util/config.rs

tnull · 2022-07-20T13:27:31Z

lightning/src/util/config.rs

+	/// Default value: is 1% of channel_value, configured as 10,000 millionths
+	/// Minimum value: If calculated proportional value is < 1000 sats, will be treated as 1000 sats
+	///    				instead, 1000 sats is just a safe implementation-specific lower bound.
+	/// Maximum value: 1,000,000, any values larger than 1Million will be treated as 1Million (or 100%)


Suggested change

/// Maximum value: 1,000,000, any values larger than 1Million will be treated as 1Million (or 100%)

/// Maximum value: 1,000,000, i.e., 100% of the channel value,

i think there is information loss in this, will be keeping current version.
As for other nits, i have addressed most of them which seemed legible.
And I don't think using grammar check on PR is legal :P

I guarantee no grammar checker was harmed in making of this review. :P

lightning/src/util/config.rs

lightning/src/ln/channel.rs

TheBlueMatt · 2022-07-20T22:12:31Z

Can you rewrite the commit message to stay under 80 chars wide? Looks like its currently wrapped at 90?

G8XSU · 2022-07-20T22:36:47Z

Can you rewrite the commit message to stay under 80 chars wide? Looks like its currently wrapped at 90?

Done

ViktorTigerstrom

Some final docs nits before I'm ACK, thanks for bearing with us :)!

lightning/src/ln/channel.rs

ViktorTigerstrom · 2022-07-21T17:56:11Z

lightning/src/ln/channel.rs

-	/// for channels serialized before we included our selected reserve value in the serialized
-	/// data explicitly.
-	pub(crate) fn get_holder_selected_channel_reserve_satoshis(channel_value_satoshis: u64) -> u64 {
+	/// This is used both for outbound and inbound channels and has lower bound of `MIN_THEIR_CHAN_RESERVE_SATOSHIS`


Suggested change

/// This is used both for outbound and inbound channels and has lower bound of `MIN_THEIR_CHAN_RESERVE_SATOSHIS`

/// This is used both for outbound and inbound channels and has a lower bound of `MIN_THEIR_CHAN_RESERVE_SATOSHIS`

Missing article before countable noun is treated as optional and acceptable grammar in most IDE's for code documentation. (default:disabled in intellij)

Same with period before paragraph end (default:disabled in intellij)

Same for ',' after e.g or i.e (default:disabled in intellij)

I am currently using default Intellij grammar for "English(USA)" and it relaxes for these conditions by default.
I guess it could vary a little based on keyboard selection of user.

We are really discussing these IDE settings in PR's, which i don't think is worth our time in PR.
We can standardize them, if we want.
Either we stick to default acceptable grammar or we can decide to just enable those optional validation checks.

At the same time, we don't want to discard all grammar and write illegible docs. We should work towards having acceptable grammar and legible docs.

We are really discussing these IDE settings in PR's, which i don't think is worth our time in PR.
We can standardize them, if we want.
Either we stick to default acceptable grammar or we can decide to just enable those optional validation checks.

I tend to disagree. There are best practices to write documentation in full, grammatically correct sentences, and we should do our best to follow these. I think whether a particular IDE picks up on some of the details doesn't matter all too much.

I also think discussing subtleties of wording, grammar etc. is time well spent in a PR, since it can make or break a good documentation and most importantly the process itself can reveal diverging understandings of the subject at hand.

Given that the rest of the docs in the codebase is mixed with how strict the we are with period before paragraphs ends and similar, I can agree on letting it slip :).
Though I also tend to agree with @tnull here. I don't see why we shouldn't make our best efforts with the grammar in new PRs if it's quick to fix and doesn't take much time, given that suggested grammar is more correct. IMO when it tends to just be a waste of time and be too nit picky is when time is spent on discussing specific words or sentences that are equally correct, and the suggested wording brings no extra clarity.

Its not about whether IDE picks it up or not, it has the functionality but the chosen default:disabled means these rules are considered flexible and acceptable.
I am up for discussing any subtleties, wordings or grammar. But for grammar, saying that only "British English" official rules are "correct" is far from reality.

And I doubt adding a comma after "e.g." makes or breaks a doc. We are not writing a book here. We need to be practical and subjectively decide how strict we are. Specifically when it adds no additional value in understanding.

Mh, I think we're discussing two different things here. Should there be a considerable amount of time spent on splitting hairs regarding individual commas and/or missing articles? No, probably not.

But, I still think reviewers should point anything out that they think would improve the quality of the PR, even if it wouldn't warrant having a long discussion about it. Speaking for myself, most of the nits are really meant as suggestions and/or questions, which, at the end of the day, the author may or may not choose to consider.

ViktorTigerstrom · 2022-07-21T18:43:52Z

lightning/src/ln/channel.rs

+	}
+
+	/// This is for legacy reasons, present for forward-compatibility. LDK versions older than " < 0.0.104"
+	/// don't know how read/handle values other than default from storage. Hence we use this function


Hmmm this is a bit confusing:
LDK versions prior to 0.0.104 never persisted any value for holder_selected_channel_reserve_satoshis at all to storage, and just used the default 1% (with the upper channel value bound, and the lower 1000 sats bound). Such versions never read any holder_selected_channel_reserve_satoshis value from storage either, not even the default.

LDK versions 0.0.104 and later persists a value for holder_selected_channel_reserve_satoshis if it differs from the legacy implementation, and uses that value instead.

This function is used to track what the default implementation of the holder_selected_channel_reserve_satoshis was, before it was configurable, not for the purpose of "not persisting default values".
I actually lean towards not mentioning how the value was actually persisted previously in the docs for this function at all, as it feels a bit misplaced, and should be mentioned in the read/write logic instead if needed as that's where it's of interest. But I'll let you decide if it fits here :)!

I'd therefore change the docs for this function to something like:
Returns the value holder_selected_channel_reserve_satoshis used to be set to, prior to when it was made configurable.
If you want to include something about serialization, you can also add something like:
The value was made configurable in LDK 0.0.110, although LDK 0.0.104 and later enabled serialization of channels with a value for holder_selected_channel_reserve_satoshis that differed from the default.

I mean but we wouldn't have this at all if it weren't for the serialization logic/change, so I think this function needs to specify that its really all about serialization in some way or another. I don't think phrasing it in terms of "when we started writing values other than the default" (as you suggest) is really correct, either, as versions between 104 and 110 dont ever write values at all, they just know how to read values other than the default. I'm open to changes here but I think the comment as it lies is clearer than your suggestion.

Yeah fair enough :)! I agree on that my suggestion isn't correct either.

What I specifically find confusing is the sentence:
"LDK versions older than " < 0.0.104" don't know how read/handle values other than default from storage.",
as those versions under no circumstances read the value from the storage at all, not even the default value. But, given the discussion about being too nit picky above, maybe that applies to me here as well 😁.

If @G8XSU thinks changing the wording here would clarify the docs, feel free to change this. Either way, I'm ok with the current wording here as well :)!

Main purpose: Its present for forward-compatibility, so that we don't persist default values for channels created by older versions. This is for the case when we have to roll-back to previous version, we have at-least those old channels operational.

If in future, we decide to remove forward compat with <104, we can get rid of this function/logic.
I think this information is conveyed.
Didn't want to make it anymore complex than that.

lightning/src/ln/channel.rs

lightning/src/util/config.rs

tnull

Generally looks good, just one more nit and a few minor suggestions.

tnull · 2022-07-22T09:19:46Z

lightning/src/util/config.rs

+	///					 as 1000 sats instead, which is a safe implementation-specific lower bound.
+	/// Maximum value: 1,000,000, any values larger than 1 Million will be treated as 1 Million (or 100%)
+	///    			    instead, although channel negotiations will fail in that case.
+	pub their_channel_reserve_proportion_millionth: u32


nit: For the sake of consistency with other similarly named variables, this should probably be proportional_millionths.

Suggested change

pub their_channel_reserve_proportion_millionth: u32

pub their_channel_reserve_proportional_millionths: u32

Oh, i think matt mentioned it earlier as well. I might have misunderstood, i thought its for comments only. Will pluralize field name as well.

lightning/src/ln/channelmanager.rs

lightning/src/ln/channel.rs

lightning/src/ln/functional_tests.rs

lightning/src/ln/channel.rs

TheBlueMatt · 2022-07-26T19:51:15Z

lightning/src/ln/channelmanager.rs

@@ -1635,7 +1635,7 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana
 		}
 	}

-	/// Gets the current configuration applied to all new channels,  as
+	/// Gets the current configuration applied to all new channels


While this is trivial so kinda nbd, in general more PRs good - if something is trivial we can land the PR in 5 minutes, so best not to bundle things too much (I can be guilty of it too), just a general note for the future.

ViktorTigerstrom

ACK eb62099

Edit: Scratch my comment about the new name of the config field.

However, please update the commit message for the config field as that's currently still using their_channel_reserve_proportion_millionth and not the updated name.

ViktorTigerstrom · 2022-07-31T15:10:15Z

lightning/src/ln/channel.rs

+		// Test that `new_outbound` and `new_from_req` creates a channel with the correct value set
+		// for `their_channel_reserve_proportion`, when configured with a valid percentage value.


I was trying to convey in my previous suggestion #1619 (comment) that I think this comment is a bit confusing, but I realize that I probably wasn't wasn't very clear :) :
The test asserts that the channel_reserves are set to the correct value when the config value is configured with a valid value, and I think it would make more sense to word the comment to covey that instead of referring to that the config value itself has a correct value set. The test asserts the channel_reserve values, and doesn't explicitly assert that the config value itself is correct, although that is of course implicitly correct as well.

This isn't a big of a deal, but feel free to change this if you'd like. Either way I'm ok :).

I am not sure if i understand this correctly,
We shouldn't be testing the setters anyways(its trivial), we should test the functionality resulting from config.
I will clarify the comment.

Thanks, your clarification addressed exactly what I found confusing :)!

tnull · 2022-08-01T08:54:58Z

Edit: Scratch my comment about the new name of the config field.

However, please update the commit message for the config field as that's currently still using their_channel_reserve_proportion_millionth and not the updated name.

Okay, now I'm confused by the discussion: as of 7c90ee3, it's still their_channel_reserve_proportion_millionths? Is this intentional or did it slip back in somehow? I still have a preference for proportional, but would also be fine if it was left as is to make some progress here.

Other than that, LGTM.

G8XSU · 2022-08-01T16:50:01Z

Edit: Scratch my comment about the new name of the config field.
However, please update the commit message for the config field as that's currently still using their_channel_reserve_proportion_millionth and not the updated name.

Okay, now I'm confused by the discussion: as of 7c90ee3, it's still their_channel_reserve_proportion_millionths? Is this intentional or did it slip back in somehow? I still have a preference for proportional, but would also be fine if it was left as is to make some progress here.

Other than that, LGTM.

Fixed it

ViktorTigerstrom

ACK 93ccd7f

Absolute final nits:
Use ` chars around their_channel_reserve_proportional_millionths in the commit message header instead of ' chars, so that it's displayed as their_channel_reserve_proportional_millionths instead of 'their_channel_reserve_proportional_millionths'.

The first sentence in the commit message body is also a bit hard to understand, and has been updated in the config docs since it was written. If you want to, update it to something like the first sentence in the config flag docs i.e.:
Configures the counterparty's channel reserve proportional to the channel value , i.e., their_channel_reserve_satoshis for both outbound and inbound channels.

Though these are absolutely not requirements, so feel free to merge this without changing this.

G8XSU · 2022-08-01T22:23:58Z

ACK 93ccd7f

Absolute final nits: Use chars around their_channel_reserve_proportional_millionths in the commit message header instead of ' chars, so that it's displayed astheir_channel_reserve_proportional_millionths` instead of 'their_channel_reserve_proportional_millionths'.

The first sentence in the commit message body is also a bit hard to understand, and has been updated in the config docs since it was written. If you want to, update it something like the first sentence in the config flag docs i.e.: Configures the counterparty's channel reserve proportional to the channel value , i.e., their_channel_reserve_satoshis for both outbound and inbound channels.

Though these are absolutely not requirements, so feel free to merge this without changing this.

Git cli wasnt allowing for that char, was omitting the field altogether.
Regarding commit description, its same as docs, i think its fine as it is.

ViktorTigerstrom · 2022-08-01T22:28:45Z

Git cli wasnt allowing for that char, was omitting the field altogether. Regarding commit description, its same as docs, i think its fine as it is.

Ok fair enough :)

tnull

LGTM.

TheBlueMatt

Oops, we shouldn't check in lightning/ldk-net_graph-v0.0.15-2021-05-31.bin. Can you remove that and then we can land this (maybe add it to gitignore, I guess?)

lightning/src/ln/channel.rs

ViktorTigerstrom

ACK f509398

I've left a comment regarding incorrect text alignment, which I thought was fixed in previous commit. Though it's just a minor issue, so feel free to merge this without the fix if you want to land this.

ViktorTigerstrom · 2022-08-02T20:44:04Z

lightning/src/util/config.rs

+	///
+	/// Default value: 1% of channel value, i.e., configured as 10,000 millionths.
+	/// Minimum value: If the calculated proportional value is less than 1000 sats, it will be treated
+	///    			   as 1000 sats instead, which is a safe implementation-specific lower bound.


I'm a bit confused, but I'm not sure when the mix between tabs and spaces after the /// got added again? I thought that they were addressed previously. Text alignment should be done with spaces only (and not tabs which is confusing as the rest of the code base uses tabs for indentation).

had fixed it, idk how it got added again, maybe due to my habit.

lightningdevkit#1498] It is proportion of the channel value to configure as the `their_channel_reserve_satoshis` for both outbound and inbound channels. It decides the minimum balance that the other node has to maintain on their side, at all times.

ViktorTigerstrom reviewed Jul 15, 2022

View reviewed changes

TheBlueMatt reviewed Jul 15, 2022

View reviewed changes

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

G8XSU force-pushed the main branch 3 times, most recently from 074d9e2 to a6674c7 Compare July 16, 2022 19:39

TheBlueMatt previously approved these changes Jul 17, 2022

View reviewed changes

lightning/src/util/config.rs Outdated Show resolved Hide resolved

lightning/src/util/config.rs Outdated Show resolved Hide resolved

lightning/src/util/config.rs Outdated Show resolved Hide resolved

ViktorTigerstrom previously approved these changes Jul 18, 2022

View reviewed changes

lightning/src/util/config.rs Outdated Show resolved Hide resolved

lightning/src/util/config.rs Outdated Show resolved Hide resolved

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

G8XSU dismissed stale reviews from ViktorTigerstrom and TheBlueMatt via 991bf5f July 18, 2022 23:28

G8XSU force-pushed the main branch 3 times, most recently from 0187274 to 17b4d31 Compare July 18, 2022 23:41

G8XSU closed this Jul 18, 2022

G8XSU force-pushed the main branch from 11705b3 to f75b6cb Compare July 18, 2022 23:54

G8XSU reopened this Jul 19, 2022

G8XSU requested a review from TheBlueMatt July 19, 2022 00:03

TheBlueMatt reviewed Jul 19, 2022

View reviewed changes

TheBlueMatt added the Seeking Code Review label Jul 19, 2022

tnull reviewed Jul 20, 2022

View reviewed changes

valentinewallace removed the Seeking Code Review label Jul 20, 2022

G8XSU force-pushed the main branch 2 times, most recently from 6c5d0ba to 457b135 Compare July 20, 2022 21:04

TheBlueMatt assigned tnull and TheBlueMatt Jul 20, 2022

G8XSU force-pushed the main branch from 457b135 to a96edaf Compare July 20, 2022 22:30

ViktorTigerstrom reviewed Jul 21, 2022

View reviewed changes

tnull reviewed Jul 22, 2022

View reviewed changes

tnull linked an issue Jul 26, 2022 that may be closed by this pull request

Fix ChannelManager::get_current_default_configuration docs #1606

Closed

TheBlueMatt reviewed Jul 26, 2022

View reviewed changes

G8XSU force-pushed the main branch 2 times, most recently from 0fd574c to eb62099 Compare July 29, 2022 17:52

ViktorTigerstrom previously approved these changes Jul 31, 2022

View reviewed changes

G8XSU dismissed ViktorTigerstrom’s stale review via 7c90ee3 August 1, 2022 01:46

G8XSU force-pushed the main branch from eb62099 to 7c90ee3 Compare August 1, 2022 01:46

G8XSU force-pushed the main branch from 7c90ee3 to 93ccd7f Compare August 1, 2022 16:48

G8XSU changed the title ~~Add configuration support for 'their_channel_reserve_satoshis' [#1498]~~ Add config support for 'their_channel_reserve_proportional_millionths' [#1498] Aug 1, 2022

ViktorTigerstrom previously approved these changes Aug 1, 2022

View reviewed changes

tnull previously approved these changes Aug 2, 2022

View reviewed changes

TheBlueMatt reviewed Aug 2, 2022

View reviewed changes

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

G8XSU dismissed stale reviews from tnull and ViktorTigerstrom via f509398 August 2, 2022 18:26

G8XSU force-pushed the main branch from 93ccd7f to f509398 Compare August 2, 2022 18:26

TheBlueMatt previously approved these changes Aug 2, 2022

View reviewed changes

ViktorTigerstrom previously approved these changes Aug 2, 2022

View reviewed changes

G8XSU dismissed stale reviews from ViktorTigerstrom and TheBlueMatt via 092d1c1 August 2, 2022 21:36

G8XSU force-pushed the main branch from f509398 to 092d1c1 Compare August 2, 2022 21:36

TheBlueMatt approved these changes Aug 3, 2022

View reviewed changes

ViktorTigerstrom approved these changes Aug 3, 2022

View reviewed changes

tnull approved these changes Aug 3, 2022

View reviewed changes

TheBlueMatt merged commit 736c0b9 into lightningdevkit:main Aug 3, 2022

G8XSU mentioned this pull request Oct 27, 2022

Support 0 counterparty channel reserve #1801

Open

	let calculated_reserve = their_channel_reserve_proportion.mul(channel_value_satoshis as f64) as u64;
	let calculated_reserve = their_channel_reserve_proportion * channel_value_satoshis as f64;
	cmp::min(channel_value_satoshis, cmp::max(calculated_reserve as u64, MIN_THEIR_CHAN_RESERVE_SATOSHIS))`

	/// Maximum value: 1,000,000, any values larger than 1Million will be treated as 1Million (or 100%)
	/// Maximum value: 1,000,000, i.e., 100% of the channel value,

	/// This is used both for outbound and inbound channels and has lower bound of `MIN_THEIR_CHAN_RESERVE_SATOSHIS`
	/// This is used both for outbound and inbound channels and has a lower bound of `MIN_THEIR_CHAN_RESERVE_SATOSHIS`

	pub their_channel_reserve_proportion_millionth: u32
	pub their_channel_reserve_proportional_millionths: u32

		// Test that `new_outbound` and `new_from_req` creates a channel with the correct value set
		// for `their_channel_reserve_proportion`, when configured with a valid percentage value.

Add config support for 'their_channel_reserve_proportional_millionths' [#1498] #1619

Add config support for 'their_channel_reserve_proportional_millionths' [#1498] #1619

Uh oh!

Conversation

G8XSU commented Jul 15, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov-commenter commented Jul 15, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

ViktorTigerstrom left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ViktorTigerstrom Jul 15, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ViktorTigerstrom left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt commented Jul 20, 2022

G8XSU commented Jul 15, 2022 •

edited

Loading

codecov-commenter commented Jul 15, 2022 •

edited

Loading

ViktorTigerstrom Jul 15, 2022 •

edited

Loading

ViktorTigerstrom Jul 21, 2022 •

edited

Loading

tnull Jul 26, 2022 •

edited

Loading

ViktorTigerstrom Jul 26, 2022 •

edited

Loading

ViktorTigerstrom Jul 21, 2022 •

edited

Loading