paymod: Scale presplit amounts to support larger payments while maintaining size buckets for privacy #3986
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Huge payment + presplit modifier = too many HTLCs...
This is the simplest possible fix: increase the target amount until we get the desired number of parts, while still bucketizing payments together that are in approximately the same size. The current logic puts all payments that are in the range x < amount <= 16*x in the same bucket, making them harder to distinguish. Changelog-Fixed: pay: The `presplit` modifier now supports large payments without exhausting the available HTLCs.
rustyrussell
approved these changes
Aug 27, 2020
| target.millisatoshis = p->amount.millisatoshis / htlcs; /* Raw: division */ | ||
| else | ||
| target = AMOUNT_MSAT(MPP_TARGET_SIZE); | ||
| target.millisatoshis = target_amount; /* Raw: init */ |
There was a problem hiding this comment.
Simpler as amount_msat(target_amount)
| @@ -2888,10 +2903,10 @@ static void presplit_cb(struct presplit_mod_data *d, struct payment *p) | |||
| return payment_fail( | |||
| p, "Cannot attempt payment, we have no channel to " | |||
| "which we can add an HTLC"); | |||
| } else if (p->amount.millisatoshis / MPP_TARGET_SIZE > htlcs) /* Raw: division */ | |||
| } else if (p->amount.millisatoshis / target_amount > htlcs) /* Raw: division */ | |||
| target.millisatoshis = p->amount.millisatoshis / htlcs; /* Raw: division */ | |||
There was a problem hiding this comment.
target = amount_msat_div(p->amount, htlcs);
|
Minor cleanups only, will push post. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This proposal is a simple solution to #3926 and an alternative to
#3942/#3951. It is very much in the spirit of the original
presplitpaymentmodifier in that it will create parts with a fixed size (not considering the
amount fuzzing to obfuscate the remainder), mostly independently of the total
amount. I think this is import to make it harder for observers to invert the
split and derive the original amount.
The change consists in adjusting the target amount for the individual parts
upwards should the current split result in too many parts. We use powers of 16
as a step size between buckets, resulting in at most 16 parts, and all
payments whose total amount is in the range of
x < amount <= 16*xresult inthe same part amount.
Why 16 as the upper limit of parts? Because it is approximately 1/2 of the
HTLCs available to a single channel, giving us some room to use adaptively
split should that be necessary. At the same time it is large enough such that
the resulting partial amounts are not too specific to the total amount, and
it's a power of two which means after log2(16) adaptive splits the amounts of
the parts mix with the a smaller payment's parts again. This is mostly in
preparation for PTLCs which give us decorrelation, but I think we can already
expect a benefit in amounts snapping to buckets.
Notice that none of the parameters are set in stone, and I'm happy to adjust
should better parameters be found.
Closes #3951
Closes #3942
Fixes #3926