Newsletters: add 207 (2022-07-06) #802

harding · 2022-07-05T07:13:21Z

Lede, releases/RCs, topic links @harding
Bitcoin Core 24836 @glozow
Bitcoin Core 22558 @bitschmidty

glozow

This was really really informative! A few nitpicks and 1 name spelling.

glozow · 2022-07-05T08:32:56Z

_posts/en/newsletters/2022-07-06-newsletter.md

+  Rusty Russell for rate limiting [onion messages][topic onion
+  messages].  The proposal has each node store just an extra 32 bytes of
+  information for each of their peers that allows them to
+  probabalistically punish peers who send too much traffic.  The


Suggested change

probabalistically punish peers who send too much traffic. The

probabilistically punish peers who send too much traffic. The

glozow · 2022-07-05T08:34:11Z

_posts/en/newsletters/2022-07-06-newsletter.md

+  messages].  The proposal has each node store just an extra 32 bytes of
+  information for each of their peers that allows them to
+  probabalistically punish peers who send too much traffic.  The
+  suggested penalty is to just half the rate limit for a peer relaying


(I think we're supposed to use "halve" as the verb form, but very sorry if I'm just nitpicking)

Suggested change

suggested penalty is to just half the rate limit for a peer relaying

suggested penalty is to just halve the rate limit for a peer relaying

glozow · 2022-07-05T08:35:26Z

_posts/en/newsletters/2022-07-06-newsletter.md

+
+    One proposal was for nodes to simply not consider a channel closed
+    until some amount of time after its onchain closing transaction was
+    seen.  This would give time for he announcement of the new


Suggested change

seen. This would give time for he announcement of the new

seen. This would give time for the announcement of the new

glozow · 2022-07-05T08:37:28Z

_posts/en/newsletters/2022-07-06-newsletter.md

+  settle).  If a set of payments up to the total amount of a channel can
+  be sent, then a prober can learn nearly the exact balance of the
+  channel by just trying different sets of payments until all parts are
+  accepted.  But, if the set of payments which can be sent is limited to


Suggested change

accepted. But, if the set of payments which can be sent is limited to

accepted. However, if the set of payments that can be sent is limited to

glozow · 2022-07-05T08:40:43Z

_posts/en/newsletters/2022-07-06-newsletter.md

+  which also received significant [additional commentary][towns fee
+  signal] in the past week from Anthony Towns.
+
+- **Onion message rate limiting:** Bastian Teinturier


See https://github.com/t-bast/

Suggested change

- **Onion message rate limiting:** Bastian Teinturier

- **Onion message rate limiting:** Bastien Teinturier

murchandamus

Very informative. I dove a bit into the Lightning stuff this time, although I would have benefited from reading the whole newsletter first before researching. 😁

murchandamus · 2022-07-05T11:57:07Z

_posts/en/newsletters/2022-07-06-newsletter.md

+  public payment code without engaging in privacy-harming [address
+  reuse][topic output linking].  One of the problems with BIP47 is that
+  the first transaction between a spender (e.g. Bob) and Alice may leak
+  to block chain analysis organizations that Bob wants to pay Alice.


Mh, I was bothered by the last two sentences in this paragraph at first, but the more often I read it and try to phrase it, the more accurate and elegant your description starts to feel. Anyway, since I've already written all this, I'm gonna share it:

I am not super familiar with BIP47 and other related proposals, but AFAIK, BIP47 requires the receiver to provide a payment code (which can be out of band), and then each sender to create a "Notification Transaction" once before sending their first payment to the receiver. AFAIU, this notification transaction always pays to a specific "notification address" that is directly coupled to the payment code. So, while the later payments itself do not have address reuse, the notification transactions create a marked footprint, both in the address reuse of the notification address and the distinct pattern of the OP_RETURN in the notification transactions.

So, 1) perhaps it could be clarified that the problematic transaction is distinct from "the first transaction". (Although in hindsight that seems like a good simplification.) And, 2) it would mean that if a surveillant knows a payment code (e.g. as they are shared publicly per a directory), it always leaks that someone wants to start paying that specific payment code, but the prospective sender may be able to remain unknown. This is definitely not as aptly crafted as your usual writing, but only is meant to highlight where I see potential for clarification:

Suggested change

public payment code without engaging in privacy-harming [address

reuse][topic output linking]. One of the problems with BIP47 is that

the first transaction between a spender (e.g. Bob) and Alice may leak

to block chain analysis organizations that Bob wants to pay Alice.

public payment code without engaging in privacy-harming [address

reuse][topic output linking]. One of the problems with BIP47 is that

the creation of a shared secret before the first transaction between a spender (e.g. Bob) and Alice could leak

to block chain analysis organizations that a) someone wants to pay Alice, b) may leak that Bob wants to pay Alice.

murchandamus · 2022-07-05T12:07:56Z

_posts/en/newsletters/2022-07-06-newsletter.md

+    Hodler's scheme would be less likely to leak this information but it
+    would increase the amount of data a client implementing the protocol
+    would need to learn from the block chain, making it less suitable
+    for light clients.  Ruben Somsen suggested several alternatives


I read this at first as if it suggested that Ruben invented all of the following and stumbled on the comma before Robin Linus. I only grokked what I understand to be the intended meaning on the third glance. Maybe:

Suggested change

for light clients. Ruben Somsen suggested several alternatives

for light clients. Ruben Somsen indicated several alternatives

murchandamus · 2022-07-05T12:28:11Z

_posts/en/newsletters/2022-07-06-newsletter.md

+  through channels which advertise that they won't accept payments
+  larger than half the amount of money committed to the channel.  This


I first understood this to mean that the channel will limit to a total of half being in pending forwards in either direction. However, looking at the code, it seems to me that LDK discourages channels that allow a single HTLC to use half or more of the capacity. (Unless htlc_maximum_msat pertains to the total rather than a single HTLC, which doesn't seem to be the case.)

To achieve the privacy benefit you mention, it seems to me that instead max_htlc_value_in_flight_msat would have to be restricted to less than half in both directions, so I'm a bit confused. Otherwise they could just create multiple HTLCs? 🤔

From my understanding:

max_htlc_value_in_flight_msat (defined in BOLT2) is a peer-level attribute that allows Alice to tell her channel partner Bob that she won't accept more then n msats aggregated across all pending HTLCs.

htlc_maximum_msat (defined in BOLT7) is a gossiped channel attribute that must be set to less than or equal to max_htlc_value_in_flight_msat and is (as you say) that max per HTLC

A node that's pathfinding based on public gossip won't know the in_flight_msat for any channels besides its direct peers, so it can't actually use that value directly---but it may be able to use htlc_maximum_msat as a reasonable proxy. It certainly seems possible that someone could set in_flight_msat to ~100% of channel capacity but htlc_maximum_msat to 50% of capacity, but it perhaps seems more likely to LN devs that any node limiting htlc_maximum_msat to 50% or less of capacity has also limited in_flight_msat to 50% or less.

Does that make sense? If not, I suggest we drop this description from this week's newsletter until I have a chance to talk to an LDK dev for clarification.

Also, thanks so much for examining this in detail!

See also lightning/bolts#996 (comment)

Edit: and more here: ACINQ/eclair#2299

My pleasure. Just to clarify in case that got dropped under the table, the 50% is part of the penalized range. :)

I could ping an LDK dev to take a look. Lemme see if I can get a hold of someone.

The observation that max_htlc_value_in_flight_msat is not a gossiped value certainly makes evaluating htlc_maximum_msat more relatable. One of the involved devs said they'll be able to take a look later today.

Sorry for the late follow-up. I talked briefly with Matt. From what I gather, he thought that describing the htlc_maximum_msat as a proxy for max_htlc_value_in_flight_msat would be a good way of describing it. The intention is indeed for node operators to reduce max_htlc_value_in_flight_msat to get into the preferred routing selection.

Updated, thanks!

murchandamus · 2022-07-05T12:50:30Z

_posts/en/newsletters/2022-07-06-newsletter.md

+  that prints the number of satoshis the wallet is reserving in UTXOs it
+  unilaterally controls to fee bump [anchor outputs][topic anchor
+  outputs] if necessary.  An additional `--additionalChannels` parameter
+  to the RPC, which takes a integer argument, reports the number of


Suggested change

to the RPC, which takes a integer argument, reports the number of

to the RPC, which takes an integer argument, reports the number of

murchandamus · 2022-07-05T13:18:45Z

_posts/en/newsletters/2022-07-06-newsletter.md

+  that only they and Alice will know, allowing anyone to reuse the
+  public payment code without engaging in privacy-harming [address


Well, the payments don't reuse addresses, but the notification transactions do.

bitschmidty · 2022-07-05T14:11:44Z

_posts/en/newsletters/2022-07-06-newsletter.md

+  removed if the Bitcoin protocol were modified to include a perpetual
+  subsidy.  Several respondents indicated that they thought the system
+  is better off without a perpetual subsidy, while others looked for
+  alternatives or apparent equivalencies such as demurrage.


It would be nice to have a short summary of "demurrage" or helpful ML (or other) link.

bitschmidty · 2022-07-05T14:17:37Z

_posts/en/newsletters/2022-07-06-newsletter.md

+
+- [Bitcoin Core #24836][] adds a regtest-only RPC, `submitpackage` to
+  help L2 protocol and application developers who intend to use
+  package relay in the future test their transactions against the


Suggest link to /en/topics/package-relay/ topic

bitschmidty · 2022-07-05T14:21:54Z

_posts/en/newsletters/2022-07-06-newsletter.md

+- [LND #6592][] adds a new `requiredreserve` RPC to the wallet subserver
+  that prints the number of satoshis the wallet is reserving in UTXOs it
+  unilaterally controls to fee bump [anchor outputs][topic anchor
+  outputs] if necessary.  An additional `--additionalChannels` parameter


Suggesting for clarity:

An additional --additionalChannels RPC parameter, which takes a integer argument...

bitschmidty · 2022-07-05T14:27:52Z

_posts/en/newsletters/2022-07-06-newsletter.md

+  are opened.
+
+- [Rust Bitcoin #1024][] adds additional code for helping developers
+  work around the `SIGHASH_SINGLE` "bug" where the Bitcoin protocol


Could link bug to https://www.coinspect.com/capture-coins-challenge-1-sighashsingle/ or similar?

harding · 2022-07-05T20:34:37Z

Made edits for this week's excellent feedback (thanks @glozow, @xekyo, and @bitschmidty!) and reviewed contributions from @glozow and @bitschmidty (thanks!). Also added lede, LDK release note, and topic links. Thanks everyone!

bitschmidty · 2022-07-06T08:56:12Z

ACK 52346f9

bitschmidty · 2022-07-06T09:09:16Z

Squashed and merged, thank you @harding @glozow and @xekyo !

glozow reviewed Jul 5, 2022

View reviewed changes

murchandamus reviewed Jul 5, 2022

View reviewed changes

bitschmidty reviewed Jul 5, 2022

View reviewed changes

harding and others added 3 commits July 6, 2022 04:01

Newsletters: add 207 (2022-07-06)

b1685b4

news207: add n24836 summary

bf6253d

news207: add Bitcoin Core 22558

3ea1a47

bitschmidty force-pushed the 2022-07-06-newsletter branch from 52346f9 to 3ea1a47 Compare July 6, 2022 09:01

bitschmidty merged commit d9bc969 into bitcoinops:master Jul 6, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Newsletters: add 207 (2022-07-06) #802

Newsletters: add 207 (2022-07-06) #802

harding commented Jul 5, 2022 •

edited

Loading

glozow left a comment

glozow Jul 5, 2022

glozow Jul 5, 2022

glozow Jul 5, 2022

glozow Jul 5, 2022

glozow Jul 5, 2022

murchandamus left a comment

murchandamus Jul 5, 2022 •

edited

Loading

murchandamus Jul 5, 2022

murchandamus Jul 5, 2022

harding Jul 5, 2022

harding Jul 5, 2022

harding Jul 5, 2022 •

edited

Loading

murchandamus Jul 5, 2022

murchandamus Jul 5, 2022

murchandamus Jul 6, 2022

harding Jul 6, 2022

murchandamus Jul 5, 2022

murchandamus Jul 5, 2022

bitschmidty Jul 5, 2022

bitschmidty Jul 5, 2022

bitschmidty Jul 5, 2022

bitschmidty Jul 5, 2022

harding commented Jul 5, 2022

bitschmidty commented Jul 6, 2022

bitschmidty commented Jul 6, 2022

	probabalistically punish peers who send too much traffic. The
	probabilistically punish peers who send too much traffic. The

	suggested penalty is to just half the rate limit for a peer relaying
	suggested penalty is to just halve the rate limit for a peer relaying

	seen. This would give time for he announcement of the new
	seen. This would give time for the announcement of the new

	accepted. But, if the set of payments which can be sent is limited to
	accepted. However, if the set of payments that can be sent is limited to

	- Onion message rate limiting: Bastian Teinturier
	- Onion message rate limiting: Bastien Teinturier

	for light clients. Ruben Somsen suggested several alternatives
	for light clients. Ruben Somsen indicated several alternatives

		through channels which advertise that they won't accept payments
		larger than half the amount of money committed to the channel. This

	to the RPC, which takes a integer argument, reports the number of
	to the RPC, which takes an integer argument, reports the number of

		that only they and Alice will know, allowing anyone to reuse the
		public payment code without engaging in privacy-harming [address

Newsletters: add 207 (2022-07-06) #802

Newsletters: add 207 (2022-07-06) #802

Conversation

harding commented Jul 5, 2022 • edited Loading

glozow left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

murchandamus left a comment

Choose a reason for hiding this comment

murchandamus Jul 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

harding Jul 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

harding commented Jul 5, 2022

bitschmidty commented Jul 6, 2022

bitschmidty commented Jul 6, 2022

harding commented Jul 5, 2022 •

edited

Loading

murchandamus Jul 5, 2022 •

edited

Loading

harding Jul 5, 2022 •

edited

Loading