adds `fundmax` flag to `openchannel` by bjarnemagnussen · Pull Request #4029 · lightningnetwork/lnd

bjarnemagnussen · 2020-02-25T13:44:54Z

Related to PR #4024, but reopened as a new PR as this feature has undergone major changes.

Description

This PR introduces a new flag fundall for openchannel, which when opening a new channel uses the whole available wallet balance for the channel capacity up to the allowed maximum funding limit (currently ~0.16 btc).

Motivation

Implementation

A new coin select function CoinSelectUpToAmount has been introduced, which selects coins up to the requested amount, or below if there are not sufficient funds available. Fees and dust amounts are added or subtracted from this amount or the change output depending on the available funds, see also the new test cases.

Considerations

This implementation should be concurrent safe, becuase it locks the coins prior to selecting them, as currently done by the wallet assembler for the coin select subroutine.

Pull Request Checklist

rpcserver.go

lnwallet/chanfunding/coin_select.go

halseth · 2020-02-25T15:03:26Z

The wallet/fundingmanager already has a subtractFees flag that can be used for this purpose:

lnd/lnwallet/wallet.go

Line 69 in 3aca9d2

SubtractFees bool

It should significantly reduce the complexity of this PR I think.

bjarnemagnussen · 2020-02-25T15:21:23Z

The wallet/fundingmanager already has a subtractFees flag that can be used for this purpose:

lnd/lnwallet/wallet.go

Line 69 in 3aca9d2

SubtractFees bool

It should significantly reduce the complexity of this PR I think.

I was trying to use this flag, but since the maximum funding amount is limited to the constant lnd.MaxFundingAmount, we don't always want to use it. It is only if the balance is less than lnd.MaxFundingAmount, and in special cases where the balance is just slightly greater than lnd.MaxFundingAmount but not enough to cover the fees. Then we actually will subtract the fee from the total balance which will give a funding amount a little less than this constant.

But I did use the CoinSelectSubtractFee function for inspiration a lot, and it may be that I should try to combine the new CoinSelectUpToAmount with it?

I saw there may also be an open TODO in that regard for the excess fee. Furthermore, CoinSelect does not make correct fee calculation if change amount is dust, which is solved by CoinSelectSubtractFee and CoinSelectUpToAmount.

halseth · 2020-02-28T17:42:47Z

@bjarnemagnussen I'm not sure I understand the limitation of the current API. If you do a regular channel opening with the MaxFundingAmt value, it will open that channel if the balance is available for that channel size + the fee. If the balance is not available, one can use the subtractFees flag, wit a value set to the remaining wallet balance. Wouldn't this work?

bjarnemagnussen · 2020-02-29T15:18:51Z

@halseth This works well, and I have added a commit to do as you suggest! :) Hopefully this is something along the line of what you were thinking?

Mismatch between coin select functions

There is this little mismatch between CoinSelect and CoinSelectSubtractFees that probably should be considered.

The CoinSelect function always uses a fixed fee calculation for one input and one change output. Let's assume the balance is one satoshi greater than the sum of MaxFundingAmt and a fee for one input and no change output. Then the CoinSelect function will return an error for insufficient funds, and the CoinSelectSubtractFees function takes over.

Inside CoinSelectSubtractFees we use the whole balance but the smaller fee calculation for one input and no change output. The final output amount returned from CoinSelectSubtractFees will therefore be the smaller fee subtracted from the total balance, which will result in an amount one satoshi greater than the MaxFundingAmt.

An easy fix is to use a sanity check that simply makes sure that we do not return an amount greater than what we asked for. Any difference should be small (fee difference between one and no change output) and can directly go towards the fee.

Test cases

I have for now added a test case "WIP: mismatch of fee calculation between functions" that will pass due to the added sanity check explained above, but otherwise would give rise to an output amount greater than the specified maximum.

There is also an oddity regarding testing for dust change, as it depends on which branch inside CoinSelectUpToAmount is used. Since CoinSelectUpToAmount now makes use of CoinSelect and CoinSelectSubtractFees it depends on their different ways of handling dust change. I have removed testing for dust change as those should be handled by the other coin select functions. I have therefore also removed the test case "no amount to pay fee for change".

halseth

This looks pretty good! Could an alternative way to communicate our intention to use all our funds to the wallet be a fundUpTo bool? That way we would reuse the localAmt field for our maximum channels size, but communicate with the boolean that we allow creating a smaller channel if the funds are not available.

We could also take this a step further and create a chanSizeType enum that would have values SubtractFees, FundUpTo and ExactChanSize.

cmd/lncli/commands.go

rpcserver.go

fundingmanager.go

bjarnemagnussen

Thanks @halseth for your review and the helpful inputs!

Could an alternative way to communicate our intention to use all our funds to the wallet be a fundUpTo bool? That way we would reuse the localAmt field for our maximum channels size, but communicate with the boolean that we allow creating a smaller channel if the funds are not available.

I have been considering this. But there were a few things I fell over:

There is the minimum channel funding limit minChanFundingSize defined in lnd that we always want to exceed. And we may therefore want to be able to define a minimum value at the channel funding when fundAll is set.
When called from the RPC it must also be assured that the funding amount is at least the amount we will afterwards try to push to the remote (see comment with the code).
With a minimum channel funding limit set inside localAmt we keep the behaviour that the channel opening will fail with funds less than what is set with the localAmt.

I am therefore not sure if we can work around this in another way?

We could also take this a step further and create a chanSizeType enum that would have values SubtractFees, FundUpTo and ExactChanSize.

I like your idea of defining a chanSizeType enum for the different cases! But how it will look probably depends on if the minimum amount is needed or not from the discussion above.

rpcserver.go

cmd/lncli/commands.go

fundingmanager.go

bjarnemagnussen · 2020-04-07T16:24:59Z

I am still not sure how to handle both the MaxFundingAmount and the minChanFundingSize better with the fundall flag. Any other idea on how to streamline this?

guggero · 2020-04-24T14:11:04Z

Could you rebase the PR please? I'm going to take over the review for @halseth.

I am still not sure how to handle both the MaxFundingAmount and the minChanFundingSize better with the fundall flag. Any other idea on how to streamline this?

Didn't read through all comments yet, but couldn't we just check the walletbalance from the command line and if it's higher than MaxFundingAmount we just say "wallet balance exceeds minimum channel size, --fundall flag cannot be used, please specify exact amount" or something?

bjarnemagnussen · 2020-04-27T17:44:17Z

I have rebased to the current v0.10.0-beta.rc5 master commit.

Just to make sure we expect the same behaviour I am listing some cases how the fundall flag should open channels:

In general if balance < minChanFundingSize: Fail just as is current behaviour for openchannel.
If balance < MaxFundingAmount + open-tx-fee: Open a channel by maxing out the capacity resulting in no change, equivalent to opening a channel using the whole balance with SubtractFees set.
If balance >= MaxFundingAmount + open-tx-fee: Open a channel using MaxFundingAmount with a change amount to the wallet.

Remark: In the current implementation an edge case can raise a bug resulting in a channel capacity greater than MaxFundingAmount. This is caught with a sanity check, see #4029 (comment) above.

guggero

I looked at the PR now in more detail. I do see how it would be useful to just create a maximum channel, no matter how much is in the wallet. But perhaps it would then be better to call the flag --fundmax?

What does make this PR a bit more complicated is the handling of the push amount (initial remote balance). Maybe we should just disallow the combination of flags/parameters? Or work with a percent margin.

I'm going to test this a bit more tomorrow, so far I've only looked at the code.

cmd/lncli/cmd_open_channel.go

rpcserver.go

lnwallet/wallet.go

bjarnemagnussen · 2020-05-06T16:01:25Z

I commented above before committing, so sorry for that!

I have renamed fundall to fundmax and added comments in the code to explain a bit more what is going on.

guggero · 2020-05-07T06:34:07Z

No worries. I'll have a look at it today and test it more thoroughly.

bjarnemagnussen · 2020-05-07T09:20:28Z

Let me just one more time mention #4029 (comment) for when you find the time to test this more thoroughly.

I am not particularly happy about this edge case and how it is currently resolved. I think this should be solved by aligning the fee calculation of the two coin-selection functions (CoinSelect and CoinSelectSubtractFees). But I am not sure if there are concrete plans to do this in the near future, since TODOs already exist in the code of the CoinSelect function.

If needed, I could take a look at the TODO inside CoinSelect to make coinSelect not estimate change output for dust change, which is already correctly handled by ´CoinSelectSubtractFee`.

bjarnemagnussen · 2021-12-23T11:33:23Z

I have rebased this PR and added two commits to respect the reserve wallet balance in case of anchor channels.

One thing to consider is regarding the different commit types. Should the integration test also check the "lease" commit type, and should there be an integration test that fails whenever a new type is introduced that is not tested for to be sure the behaviour is always correct?

saubyk · 2022-01-27T00:21:54Z

@guggero waiting eagerly for this feature.

guggero · 2022-01-27T12:27:26Z

Okay cool. Feel free to test and leave a review to make sure this works as expected for your use case(s). Will try to pick it up this week too.

guggero

We're getting pretty close, I think. The added complexity with the reserve balance does make everything a bit harder. I hope you understand why this PR undergoes so much scrutiny since it touches the core funding logic, where (as you've probably noticed) a lot of things can have an influence.

The integration tests look really good now, though! I don't think we need to also add a test with the new commitment type, since fee wise they look just like anchor channels.

guggero · 2022-01-28T13:18:05Z

funding/manager_test.go

+		}
+
+		// Inputs should be all funds in the wallet.
+		if len(fundingTx.TxIn) != len(test.coins) {


Should we add a test case with multiple inputs so this check actually does make sense?

done here: 5e7d875#diff-97a234788862027c261c89226cdc9a681e96f8803888e57cdddfef9aad229da1R3409

guggero · 2022-01-28T13:19:58Z

lntest/itest/lnd_channel-funding_fund_max_test.go

+	runTestCase := func(carol, dave *lntest.HarnessNode,
+		testCase *chanFundMaxTestCase) func(t *testing.T) {
+
+		return func(t *testing.T) {


To avoid this nesting and the code within reaching over the 80 character limit, we shouldn't return a function here, but instead just define a function that takes t, carol, dave, testCase and then call it in the test case loop below.

Has been covered here: https://github.com/lightningnetwork/lnd/pull/6903/files#diff-583407cd98e4e423efd8a6afe4acb5b67395da6ae79927b11f9e3b989f822313R153

guggero · 2022-01-28T13:20:31Z

lntest/itest/lnd_channel-funding_fund_max_test.go

+			amount: 37000,
+			// The transaction fee to open the channel must be subtracted from
+			// Carol's balance (since wallet balance < max-chan-size).
+			carolBalance: btcutil.Amount(37000) - fundingFee(1, false),


We should add a test with a low balance and the anchor reserve, just to make sure the interplay here is correct.

Was added by @bjarnemagnussen, to be reviewed here: f851139#diff-583407cd98e4e423efd8a6afe4acb5b67395da6ae79927b11f9e3b989f822313R142

guggero · 2022-01-28T13:21:05Z

cmd/lncli/cmd_open_channel.go

 			Usage: "(optional) if set, the wallet will attempt to " +
-				"commit the maximum possible local amount to the channel. " +
-				"Should not be set together with local_amt",
+				"commit the maximum possible local amount to " +


This whole commit should be squashed with the respective commits where the initial changes were introduced.

Done here b8e351e and here 7915d0d

guggero · 2022-01-28T13:23:39Z

rpcserver.go

-		if remoteInitialBalance >= funding.MinChanFundingSize {
+		// As default value for the minimum local amount use the larger
+		// of the amount to be pushed to the remote or the allowed
+		// minimum channel size.


To be honest, these comments don't really help me to understand why something is done. They just describe the code below in words. We should add the context from the discussions in this PR instead. Otherwise someone looking at this in a year or so won't know what was discussed.

Tried to make it clearer here: 58bc9bd#diff-674c79ba02b6e9c45a994388392689814f3538800351b2fd43fb3ade21e1effbR1916

guggero · 2022-01-28T13:28:13Z

lnwallet/chanfunding/coin_select.go

 	selectedCoins, changeAmt, err := CoinSelect(
 		feeRate, maxAmt, dustLimit, coins,
 	)
+	if err == nil {


This whole method is very hard to grasp without staring at it for a long time. Since this selects coins, it makes me very nervous.

So here two suggestions to streamline the code in this area.

Use one switch statement:

switch { case err == nil: case err.(type) == *ErrInsufficientFunds: default: }

Instead of setting the err to errReservedValueInvalidated, do the actual call to CoinSelectSubtractFees directly.

Covered here: 60ddaa7#diff-40ac2ca08026898bb3f9c383bb3ddf7c232b5d2a46c31c8673a80c17c87cf037R277

guggero · 2022-01-28T13:28:51Z

lntest/itest/lnd_channel-funding_fund_max_test.go

 			}
+
+			if commitTypeHasAnchors(testCase.commitmentType) {
+				err = checkWalletBalance(carol, lnwallet.ReservedValue(1))


guggero · 2022-01-28T13:32:40Z

lnwallet/wallet.go


 	localFundingAmt := req.LocalFundingAmt
 	remoteFundingAmt := req.RemoteFundingAmt
+	hasAnchors := req.CommitType.HasAnchors()


These changes to the wallet probably deserve their own commit.

sputn1ck · 2022-05-26T05:44:10Z

cmd/lncli/cmd_open_channel.go

 	}

+	// Note:
+	// The fundmax flag is NOT allowed to be combiend with local_amt above.


typo (combiend -> combined)

done here 5e7d875#diff-81f87a9144ebe01ee1916dad1a5d76287e7c76ced4fd2ae553a8e9ea5a17c190R332

ziggie1984 · 2022-05-26T08:54:54Z

I was wondering why the author commit dates are not in a chronological order ? (does it come from rebasing single commits ?)

Bjarne Magnussen: 6d3de89b3: 5 months ago
Bjarne Magnussen: 1a9f2807b: 5 months ago
Bjarne Magnussen: 3ac041fcc: 1 year, 1 month ago
Bjarne Magnussen: 827685603: 5 months ago
Bjarne Magnussen: 2a2d6ca9c: 1 year, 1 month ago
Bjarne Magnussen: e9a0c1478: 1 year, 1 month ago
Bjarne Magnussen: 87b957a8b: 1 year, 1 month ago
Bjarne Magnussen: bb4013440: 1 year, 1 month ago

ziggie1984 · 2022-05-26T16:14:36Z

funding/manager_test.go

+		updateChan := make(chan *lnrpc.OpenStatusUpdate)
+
+		// Initiate a fund channel, and inspect the funding tx.
+		pushAmt := btcutil.Amount(0)


should we also test a pushamt greater than the MinChanFundingSize?

done here 5e7d875#diff-97a234788862027c261c89226cdc9a681e96f8803888e57cdddfef9aad229da1R3459

ziggie1984 · 2022-05-26T16:18:45Z

will this PR also allow for --fundmax with wumbo channels, meaning that the UpperLimit is adjusted when wumbo channels are active ? (As far as I understood the code, its capped at the 2^24-1 limit)

ziggie1984 · 2022-05-26T16:52:51Z

will this PR also allow for --fundmax with wumbo channels, meaning that the UpperLimit is adjusted when wumbo channels are active ? (As far as I understood the code, its capped at the 2^24-1 limit)

Justed tested it with wumbo channels works nice 👍

hsjoberg · 2022-05-27T18:53:45Z

lntest/itest/lnd_channel-funding_fund_max_test.go

+	"fmt"
+	"testing"
+
+	"github.com/btcsuite/btcutil"


Erroneous import:

Suggested change

"github.com/btcsuite/btcutil"

"github.com/btcsuite/btcd/btcutil"

Also I'm no go expert but other test files contain //go:build xxx in the top:

+//go:build !rpctest // +build !rpctest

Fixed in the continuation of this PR, here: #6903

hsjoberg · 2022-05-27T19:36:04Z

lnwallet/wallet.go

+			RemoteAmt:      req.RemoteFundingAmt,
+			LocalAmt:       req.LocalFundingAmt,
+			FundUpToMaxAmt: req.FundUpToMaxAmt,
+			ReservedAmt:    ReservedValue(numAnchorChans),


This will lead to inconsistent behavior.
For private channels (i.e mobile wallets), we do not right now reserve any sats for anchor outputs.
If you specify the amount when opening a private channel, you'll be able to use all funds (no sats will be reserved).
Related commit: 8e1087d

Also related topic: #6574

Possible fix:

+isPublic := req.Flags&lnwire.FFAnnounceChannel != 0 [...] -if req.FundUpToMaxAmt > 0 { +if req.FundUpToMaxAmt > 0 && isPublic { numAnchorChans, err = l.currentNumAnchorChans() if err != nil { req.err <- err req.resp <- nil return } if hasAnchors { numAnchorChans++ } }

Addressed and described here with comments from the related commit 8e1087d: 60ddaa7#diff-3ebebe355b386e69fdd9742a8d6ed60cb3b2377a9c10a3d3b831650e47c7d258R779

Roasbeef · 2022-08-24T20:20:34Z

@bjarnemagnussen hey this is on the milestone for our next release, do you have time to resume work on it so it can finally land?

hieblmi · 2022-09-05T14:58:21Z

@saubyk @Roasbeef I see this is up for grabs and it looks like there's a lot to learn about the lnd code base so I'd like to take a stab at this issue but I assume it'll take me some time to delve into it. Continued PR here: #6903

saubyk · 2022-09-05T16:55:05Z

@hieblmi keen on making progress on this PR, so it would be great if you can pick it up and run with it. We are hoping this issue can make it in release 16. Happy to work with you to make progress on this. You may want to reach out to @bjarnemagnussen if he can provide any assistance on this.

hieblmi · 2022-09-13T19:43:35Z

lnwallet/chanfunding/coin_select.go

 }

+// errReservedValueInvalidated is an error used internally for the coin select
+// algorithm to determine that


incomplete comment.

hieblmi · 2022-09-22T18:30:03Z

I have rebased this PR and added two commits to respect the reserve wallet balance in case of anchor channels.

One thing to consider is regarding the different commit types. Should the integration test also check the "lease" commit type, and should there be an integration test that fails whenever a new type is introduced that is not tested for to be sure the behaviour is always correct?

I've added a test in this commit: 1301bde

lightninglabs-deploy · 2022-09-29T19:17:17Z

@bjarnemagnussen, remember to re-request review from reviewers when ready

guggero · 2022-10-04T07:49:53Z

It looks like all comments were addressed in the replacement PR #6903, so I'm going to close this one.
And I haven't heard any protest from @bjarnemagnussen against it being taken over, so I assume that's okay.
Thanks a lot for getting this started!

bjarnemagnussen requested review from Roasbeef, cfromknecht and halseth as code owners February 25, 2020 13:44

bjarnemagnussen commented Feb 25, 2020

View reviewed changes

rpcserver.go Outdated Show resolved Hide resolved

Roasbeef requested changes Feb 25, 2020

View reviewed changes

lnwallet/chanfunding/coin_select.go Outdated Show resolved Hide resolved

andrerfneves mentioned this pull request Mar 3, 2020

[WIP] Add post for socratic 102 BitDevsNYC/BitDevsNYC.github.io#50

Merged

halseth suggested changes Mar 4, 2020

View reviewed changes

cmd/lncli/commands.go Outdated Show resolved Hide resolved

rpcserver.go Outdated Show resolved Hide resolved

fundingmanager.go Outdated Show resolved Hide resolved

bjarnemagnussen commented Mar 4, 2020

View reviewed changes

rpcserver.go Outdated Show resolved Hide resolved

cmd/lncli/commands.go Outdated Show resolved Hide resolved

fundingmanager.go Outdated Show resolved Hide resolved

Roasbeef added this to the 0.11.0 milestone Apr 14, 2020

Roasbeef added v0.11 enhancement Improvements to existing features / behaviour funding Related to the opening of new channels with funding transactions on the blockchain labels Apr 14, 2020

Roasbeef requested review from guggero and removed request for cfromknecht April 23, 2020 00:50

bjarnemagnussen force-pushed the fundall-flag branch from 57b80a3 to f7b419f Compare April 27, 2020 17:41

bjarnemagnussen force-pushed the fundall-flag branch from f7b419f to bed6742 Compare April 27, 2020 20:40

guggero reviewed Apr 29, 2020

View reviewed changes

cmd/lncli/cmd_open_channel.go Outdated Show resolved Hide resolved

rpcserver.go Outdated Show resolved Hide resolved

lnwallet/wallet.go Outdated Show resolved Hide resolved

carlaKC self-requested a review May 3, 2020 12:19

guggero self-requested a review May 6, 2020 15:01

bjarnemagnussen force-pushed the fundall-flag branch from bed6742 to d14e12f Compare May 6, 2020 16:01

lnwallet: respect the reserved wallet balance when using fundmax

6d3de89

bjarnemagnussen force-pushed the fundall-flag branch from 810d331 to 6d3de89 Compare December 22, 2021 12:17

bjarnemagnussen requested a review from guggero December 23, 2021 11:33

hsjoberg mentioned this pull request Jan 12, 2022

Improvements for OpenChannel screen smolcars/blixt-wallet#389

Open

3 tasks

guggero reviewed Jan 28, 2022

View reviewed changes

Roasbeef modified the milestones: v0.15.0, v0.16.0 Mar 23, 2022

sputn1ck reviewed May 26, 2022

View reviewed changes

ziggie1984 reviewed May 26, 2022

View reviewed changes

hsjoberg suggested changes May 27, 2022

View reviewed changes

hsjoberg reviewed May 27, 2022

View reviewed changes

saubyk removed this from the v0.16.0 milestone Aug 27, 2022

Roasbeef added the up for grabs PRs which have been abandoned by their original authors and can be taken up by someone else label Aug 31, 2022

saubyk mentioned this pull request Sep 5, 2022

Select specific UTXOs when opening a new channel Ride-The-Lightning/RTL#712

Open

hieblmi mentioned this pull request Sep 8, 2022

funding: add fundmax flag to OpenChannelRequest #6903

Merged

hieblmi reviewed Sep 13, 2022

View reviewed changes

guggero closed this Oct 4, 2022

saubyk removed a link to an issue Jan 25, 2023

[Request] sendcoins all / openchannel all #619

Closed

	"github.com/btcsuite/btcutil"
	"github.com/btcsuite/btcd/btcutil"

Conversation

bjarnemagnussen commented Feb 25, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Motivation

Implementation

Considerations

Pull Request Checklist

Uh oh!

Uh oh!

Uh oh!

halseth commented Feb 25, 2020

Uh oh!

bjarnemagnussen commented Feb 25, 2020

Uh oh!

halseth commented Feb 28, 2020

Uh oh!

bjarnemagnussen commented Feb 29, 2020

Mismatch between coin select functions

Test cases

Uh oh!

halseth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bjarnemagnussen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bjarnemagnussen commented Apr 7, 2020

Uh oh!

guggero commented Apr 24, 2020

Uh oh!

bjarnemagnussen commented Apr 27, 2020

Uh oh!

guggero left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bjarnemagnussen commented May 6, 2020

Uh oh!

guggero commented May 7, 2020

Uh oh!

bjarnemagnussen commented May 7, 2020

Uh oh!

bjarnemagnussen commented Dec 23, 2021

Uh oh!

saubyk commented Jan 27, 2022

Uh oh!

guggero commented Jan 27, 2022

Uh oh!

guggero left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hieblmi Sep 13, 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!

hieblmi Sep 17, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hieblmi Sep 13, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

bjarnemagnussen commented Feb 25, 2020 •

edited

Loading

hieblmi Sep 13, 2022 •

edited

Loading

hieblmi Sep 17, 2022 •

edited

Loading

hieblmi Sep 13, 2022 •

edited

Loading

hieblmi Sep 13, 2022 •

edited

Loading

ziggie1984 commented May 26, 2022 •

edited

Loading

hieblmi Sep 13, 2022 •

edited

Loading

hsjoberg May 27, 2022 •

edited

Loading

hsjoberg May 27, 2022 •

edited

Loading

hieblmi Sep 21, 2022 •

edited

Loading