Newsletter 95 (2020-04-29) #394

harding · 2020-04-24T20:37:43Z

Action items, news, release, and any additional commits @harding
Add author info to Suredbits post and perhaps make some small edits to be reviewed by them @harding
StackExchange section @bitschmidty
Bitcoin Core #15761 @adamjonas
Bitcoin Core #17509 @dongcarl

jonatack · 2020-04-27T00:48:09Z

_posts/en/newsletters/2020-04-29-newsletter.md

+  [multi-wallet][multi-wallet] as it works on the individual wallet that
+  is specified by the RPC.
+
+- [Bitcoin Core #17509][] gui: save and load PSBT FIXME:dongcarl


Big week! Native Descriptor Wallets just made it in as well 🚀 bitcoin/bitcoin#16528

Nice! I wouldn't usually include that this week per our schedule, but if I find enough time today to go through the PR, maybe test it out, and write it up, I'll include it.

I recommend we stick to the schedule and cover it next week, since this is already a long newsletter.

ariard

That's a nice resume :)

ariard · 2020-04-27T00:16:32Z

_posts/en/newsletters/2020-04-29-newsletter.md

+
+## News
+
+<!-- break atomicity == fission attack? -->


That's a nice finding, even if consequence is effectively to break settlement atomicity, attack relies more on blinding victim node information availability.

In LN, events triggering state transition are assumed to be announced privately between parties or published globally on the blockchain. Pinning relies on depriving a honest party to commit an onchain event while blinding it to observe the reason of failure, adding a mempool-dimension between offchain and onchain.

Mempools aren't consistent, it's like in quantum mechanics, you don't have a neutral observer, locality of observation changes the phenomenon observed. But don't have a name to catch the idea :)

"Fission attack" does sound nice. It is a layer-crossing attack, the bane of abstraction: some detail in the lower layer leaks to the higher layer.

ariard · 2020-04-27T00:24:04Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    Alice (either onchain or offchain).  Or, if Bob doesn't see a
+    preimage settlement transaction, Bob can create his own refund
+    settlement transaction after 40 blocks that takes back his 1 BTC,
+    allowing him to also refund Alice her 1 BTC (again, either onchain


Dunno if refund exactly matches here, it's more "allowing him safely to cancel back Alice's offer of 1 BTC. Either cooperatively offchain (update_fail_htlc) or at Alice's initiative onchain (HTLC-timeout). Refund let think Bob had custody of Alice coin, which he doesn't without preimage knowledge.

I agree the phrase "refund" as typically used in commerce doesn't exactly match here. Perhaps the phrasing most similar to existing commerce terminology would be a "release" from a credit/debit card hold-and-release process. However, I think "refund" is the term that's been used for this concept during the historic development of payment channels:

"initial funding transaction and time-locked refund" --Jeremy Spillman, "Spillman channels", https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html

"Non-interactive time-locked refunds" --Peter Todd, BIP65 CLTV payment channels, https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#non-interactive-time-locked-refunds

"In effect, one desires to construct a payment which is contingent upon knowledge of R by the recipient within a certain timeframe. After this timeframe, the funds are refunded back to the sender." --Thaddeus Dryja & Joseph Poon, The Bitcoin Lightning Network:Scalable Off-Chain Instant Payments (version 0.5.9.2), https://lightning.network/lightning-network-paper.pdf

Okay thanks for pointers, that makes sense. In this case I would turn sentence differently, "allowing him to signal to Alice she can refund herself"?. Non-cooperative case scenario you don't need Bob to be rightfully refunded.

ariard · 2020-04-27T00:34:56Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    Several solutions were considered in the thread, but all had
+    problems or involved significant tradeoffs:
+
+    - **Require a mempool:** Bob could use a Bitcoin full node to


Note, Eclair is already watching the mempool to fetch potential preimage.

ariard · 2020-04-27T00:43:44Z

_posts/en/newsletters/2020-04-29-newsletter.md

+      only affect channels which are unilaterally closed while payments
+      are pending, which is already a situation that that can
+      significantly increase onchain costs and so is something users try
+      to avoid.  As of this writing, this appears to be the most


By forcing every HTLC to have 2-transactions for every settlement, it would increase the cost of their spending and therefore making them uneconomical, which means they would be considered as dust. And dust HTLCs relies on more trust in your counterparty...

ariard · 2020-04-27T00:49:47Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    significantly since the transaction was last signed, then the
+    commitment transaction might not confirm until after Alice is able
+    to reclaim her funds from Bob, again creating the opportunity for
+    Bob to end up both paying Mallory and giving a refund to Alice.


Maybe you should mention a deployment of package relay is reasonably needed to eradicate this class of issue. If we lockdown 2nd-stage transaction, I can broadcast my commitment now, your HTLC-timeout is only going to be valid in 2 weeks (2048 max CLTV network), and if at expiration there is a fee-spike, honest HTLC-timeout may not into mempool before CLTV delta.

Given how often it is mentioned, is work on package relay still taking place? See bitcoin/bitcoin#16401 (comment).

Yes, https://github.com/bitcoin/bitcoin/pull/18044 has some improvements that should make it easier to implement package relay, with comments about it from within the past month.

Yes, I hosted a review club session about the wtxid transaction relay PR, was an early reviewer (and I should re-review) but it is mostly orthogonal to package relay... see this and this. A few comments about package relay in that PR, like bitcoin/bitcoin#18044 (comment), give an idea of where package relay might go in the future, but on February 6, Suhas indicated that wtxid transaction relay is a blocker to further p2p work by him. I don't have more recent information.

To make package relay secure, you likely need a p2p extension, to avoid some malicious package breakage at propagation, therefore never dutifully evaluating feerate. And if we lockdown HTLC-transaction you do want multiple-parent-one-child ("one-CPFP-pay-for-all-HTLCs"), which wasn't what Suhas first version was doing.

Agreed, PR16401 (review club) was a proof of concept for the merged PR16400 ATMP refactoring and of stand-alone minimal package relay requiring no p2p protocol modification, whereas the LN use case -- and other factors like optimising network efficiency, computational complexity, policy checks on the whole package before signature validation, etc. -- likely require p2p protocol changes akin to the BIP draft. I don't know if that is being worked on currently.

ariard · 2020-04-27T00:51:23Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    (This existing issue is what developers were working on fixing when
+    the new issue was discovered.)
+
+    So far we're unaware of any real-world losses due to onchain fee


At conclusion:

if node operators feel at risk, they may increase their CLTV_delta (CL: 14, LND: 40, Eclair: 144), it would make attack harder to execute

but increasing CLTV delta increases offchain cost of liquidity, that's a tradeoff good to underlies

A sub-point is that the payer is incentivized to take routes that have a lower total cltv_delta. In C-Lightning we even impose a limit on this total CLTV delta in the built-in pay command, so that if the total cltv_delta on a route is higher than this limit then we do not even consider that route. So everyone raising their cltv_deltas is likely to also reduce payment reliability overall.

ZmnSCPxj · 2020-04-27T04:53:01Z

_posts/en/newsletters/2020-04-29-newsletter.md

+
+## News
+
+<!-- break atomicity == fission attack? -->


"Fission attack" does sound nice. It is a layer-crossing attack, the bane of abstraction: some detail in the lower layer leaks to the higher layer.

ZmnSCPxj · 2020-04-27T05:02:10Z

_posts/en/newsletters/2020-04-29-newsletter.md

+      transaction because the two transactions *conflict*, meaning they
+      both spend the same input (a UTXO created in the commitment
+      transaction).  In theory, Bob's refund settlement transaction will
+      pay a higher feerate and so can [replace][topic rbf] Mallory's


At least currently, if Bob drops its commitment transaction onchain, then Bob cannot RBF its timelocked refund settlement transaction (as it requires a signature from Mallory, which was negotiated before while setting up the HTLC). Mallory can arrange this to happen.

However this is arguably a minor detail: even with "full" RBF, due to the non-consensual state of the mempool, various pinning attacks can still be done, most notably by setting up a large chain of transactions with horrid feerate but high absolute fee, which cannot be evicted except with an even higher high absolute fee on the replacing transaction, and racing this with the victim Bob, such that miners get this large chain, but non-mining nodes cannot.

This might be more detail than you care to add though.

ZmnSCPxj · 2020-04-27T05:06:04Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    settlement transaction or getting his refund settlement transaction
+    confirmed, Alice is able to reclaim the 1 BTC she offered Bob in the
+    Alice-Bob HTLC once its 80 block timeout expires.  When Mallory's
+    preimage settlement transaction does eventually confirm, Mallory


Mallory can arrange directly with a miner, paying fees directly instead of in-transaction, e.g. https://www.viabtc.com/tools/txaccelerator/ , which prevents the fee bump from being seen in any mempool.

True. However, I don't think it's strictly necessary for Mallory to fee bump at all. As long as she can keep her transaction in miner mempools and that transaction is not being replaced, Mallory's transaction is likely to eventually confirm and so give her the money. Since it's not required for Mallory to fee bump, I've left it out of the description (that said, Mallory probably would want to use something like the viabtc thing to lock in her gains).

ZmnSCPxj · 2020-04-27T05:26:17Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    (This existing issue is what developers were working on fixing when
+    the new issue was discovered.)
+
+    So far we're unaware of any real-world losses due to onchain fee


A sub-point is that the payer is incentivized to take routes that have a lower total cltv_delta. In C-Lightning we even impose a limit on this total CLTV delta in the built-in pay command, so that if the total cltv_delta on a route is higher than this limit then we do not even consider that route. So everyone raising their cltv_deltas is likely to also reduce payment reliability overall.

harding · 2020-04-27T14:22:29Z

Pushed edits based on the suggestions of @ariard and @ZmnSCPxj (thanks for the reviews!).

jonatack · 2020-04-27T15:33:43Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    to give preimage settlement transactions more time to confirm.
+    Current defaults in popular LN nodes are [14][cl ced] for
+    C-Lightning, [40][lnd ced] for LND, [72][rl ced] for Rust-Lightning,
+    and [144][eclair ced] for Eclair.  Note that increasing the value


That's a strikingly large range of CLTV delta defaults.

jonatack · 2020-04-27T15:35:32Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    Alice-Bob HTLC once its 80 block timeout expires.  When Mallory's
+    preimage settlement transaction does eventually confirm, Mallory
+    gets the 1 BTC that Bob offered her in the Bob-Mallory HTLC.  This
+    leaves Bob 1 BTC poorer than he started.


s/than he/than when he/

jonatack · 2020-04-27T15:39:15Z

_posts/en/newsletters/2020-04-29-newsletter.md

+      This would require those transactions to be larger (increasing
+      onchain fees) and presigned (reducing flexibility).  This would
+      only directly affect channels which are unilaterally closed while payments
+      are pending, which is already a situation that that can


s/that that/that/

jonatack · 2020-04-27T15:40:01Z

_posts/en/newsletters/2020-04-29-newsletter.md

+      significantly increase onchain costs and so is something users try
+      to avoid.  However, raising the cost of onchain enforcement also
+      raises the minimum value of payments that can be sent trustlessly
+      through LN with economical enforcement.  Depsite these challenges,


jonatack · 2020-04-27T15:46:16Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    (This existing issue is what developers were working on fixing when
+    the new issue was discovered.  Its ultimate solution also depends on
+    full nodes being able to perform [package relay][Bitcoin Core
+    #14895].)


Possibly worth mentioning that discussions regarding this issue have been ongoing for some time now -- IIRC, since 1 or 2 years at a general level, and somewhat acutely the past 6 months.

I'd say acutely for at least 2 years :). In any case, it may be worth downplaying the package relay requirement a bit here - not that it isn't eventually required but that, in today's mempool, we don't see any issues here, and if lightning nodes hardcoded 2 sat/vbyte trends dont seem to indicate its a critical issue immediately.

I'd say acutely for at least 2 years :)

Hehe :)

jonatack · 2020-04-27T15:49:37Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    routes for their payments as higher values increase the worst case
+    amount of time a payment could be stuck waiting to be settled.
+
+- **Multiparty vault architecture:** Antoine "Darosior" Poinsot


Should the co-author (and original creator, iiuc), Kevin Loaec (spelling?) be named as well?

The email seems to be a request for feedback from Dariosior only, so that's the only person I mention.

Kevin Loaec and I have been working on a new multiparty vault architecture and I think it reached the point where we’d welcome some feedback. (emphasis added)

I see your point but it begins by stating both names announcing a joint work; perhaps insert "by [both names]" after "prototype"

TheBlueMatt

The lightning section is great, thanks for the writeup! I left one comment but @ariard and @ZmnSCPxj's earlier comments were great.

TheBlueMatt · 2020-04-27T17:37:56Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    (This existing issue is what developers were working on fixing when
+    the new issue was discovered.  Its ultimate solution also depends on
+    full nodes being able to perform [package relay][Bitcoin Core
+    #14895].)


I'd say acutely for at least 2 years :). In any case, it may be worth downplaying the package relay requirement a bit here - not that it isn't eventually required but that, in today's mempool, we don't see any issues here, and if lightning nodes hardcoded 2 sat/vbyte trends dont seem to indicate its a critical issue immediately.

jnewbery

Great stuff Dave. A few small suggestions inline.

Thanks too to @ariard and @ZmnSCPxj for reviewing this week!

jnewbery · 2020-04-27T18:52:04Z

_includes/articles/suredbits-enterprise-ln.md

@@ -0,0 +1,58 @@
+{:.post-meta}
+by Roman Taranchenko


nit: style as:

*by Roman Taranchenko<br>Engineer at [Suredbits][]*

To match byline of other field reports

jnewbery · 2020-04-27T18:54:04Z

_posts/en/newsletters/2020-04-29-newsletter.md

+
+- **Review the disclosure of a potential LN issue:** as explained in the
+  *news* section below, a public disclosure this week describes a new
+  method for stealing money from LN routing nodes (unaffected are


nit: "unaffected are..." sounds a bit unnatural to me. How about "endpoint nodes [...] are unaffected"?

Oh, actually, this is not true - in theory a node directly connected to an endpoint that wishes to send a payment could exploit this and potentially cause the user to send funds twice. I dont know how other nodes implement their "this payment has failed" mechanism, but if consider something failed after the timeout, the next-hop could actually claim the funds later.

Hmmm okay the issue is Alice sending a payment to Bob, Bob pins its preimage-tx, therefore Alice can't timeout HTLC, at cltv_expiry payment logic "thinks" payment has been duly timeout onchain without verification and allow a retry ?

At least this seems to assume a buggy payment logic, something which is realist today given low light on this kind of issues.

I mean yes, but also if the HTLC is marked as "expired two hours ago" I dont think it would be unreasonable for a user to re-send the payment. I suppose an alternative thing would be to say "indefinitely leaving outbound payments stuck" or so.

jnewbery · 2020-04-27T19:24:42Z

_includes/articles/suredbits-enterprise-ln.md

@@ -0,0 +1,58 @@
+{:.post-meta}


I suggest we delay this until next week. Even without this, it's a very long and ligthning-heavy issue

The field report isn't time-sensitive, so we can publish it any time.

jnewbery · 2020-04-27T19:28:22Z

_posts/en/newsletters/2020-04-29-newsletter.md

+  [multi-wallet][multi-wallet] as it works on the individual wallet that
+  is specified by the RPC.
+
+- [Bitcoin Core #17509][] gui: save and load PSBT FIXME:dongcarl


I recommend we stick to the schedule and cover it next week, since this is already a long newsletter.

jnewbery · 2020-04-27T19:32:44Z

_includes/articles/suredbits-enterprise-ln.md

@@ -0,0 +1,58 @@
+{:.post-meta}


Perhaps we could ask Suredbits for an image to go with the field report? Chris's slide here: https://youtu.be/tbwy9mJIrZE?t=2929 for example?

Ping @Christewart

harding · 2020-04-28T12:56:46Z

Pushed edits for (hopefully) all comments to date, including bumping the Suredbits article and descriptor wallets merge summary to next week, moving details about package relay to a footnote, and removing the claim that non-routing nodes are unaffected (with a footnote to describe the details). Thanks @jonatack, @ariard, @jnewbery, and @TheBlueMatt! (In addition to @ZmnSCPxj again for his previous feedback.) Also made a few edits of my own to improve flow.

Made a tiny edit to the StackExchange section, otherwise ACK to that section (thanks @bitschmidty!)

jnewbery

ACK, with one minor nit.

I've only lightly reviewed the lightning attack write-up. I assume that with the combined review of ariard, Zmn, and Matt, it's probably technically correct.

jnewbery · 2020-04-28T17:13:40Z

_posts/en/newsletters/2020-04-29-newsletter.md

+- [What is meant by DEFAULT_ANCESTOR_LIMIT in child pays for parent?]({{bse}}95473)
+  User anu asks about Bitcoin Core's [DEFAULT_ANCESTOR_LIMIT][bitcoin core default ancestor limit]
+  regarding the [Child-Pays-For-Parent (CPFP)][topic cpfp] fee bumping
+  technique. Murch goes on to explain that this default policy helps prevent spam


nit: "goes on to" doesn't seem quite right here without Murch having done something earlier. I think just "Murch explains" is better.

jonatack

Looking like an excellent issue. A few final suggestions follow.

jonatack · 2020-04-28T16:44:28Z

_posts/en/newsletters/2020-04-29-newsletter.md

+
+- **Review the disclosure of a potential LN issue:** as explained in the
+  *news* section below, a public disclosure this week describes a new
+  method for stealing money from LN nodes.  The issue partly overlaps with a previous well-known


perhaps "previously discussed", "existing", or "another" rather than "previous" as the issue is still outstanding

and perhaps name or describe the issue, as it isn't discussed until 120 lines further down: "another known issue related to fee management in onchain LN transactions. The existing issue described in Newsletter 78..."

jonatack · 2020-04-28T16:48:11Z

_posts/en/newsletters/2020-04-29-newsletter.md

+  [Bitcoin-Dev][corallo thread bd] mailing lists disclosing an attack
+  discovered during a [discussion][BOLTs #688] about allowing LN
+  commitment transactions to be [CPFP][topic cpfp] fee bumped via
+  [anchor outputs][topic anchor outputs].  We'll describe the attack


Perhaps begin a new paragraph here for the extended example.

jonatack · 2020-04-28T17:13:52Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    routes for their payments as higher values increase the worst case
+    amount of time a payment could be stuck waiting to be settled.
+
+- **Multiparty vault architecture:** Antoine "Darosior" Poinsot


I see your point but it begins by stating both names announcing a joint work; perhaps insert "by [both names]" after "prototype"

jonatack · 2020-04-28T17:22:59Z

_posts/en/newsletters/2020-04-29-newsletter.md

+    The ultimate solution to deal with arbitrary feerates in LN also
+    depends on Bitcoin full nodes being able to perform [package
+    relay][Bitcoin Core #14895], a feature that's long been discussed
+    but never satisfactorily implemented.  For now, LN commitment


suggest s/never satisfactorily/not yet|not yet fully/ as per comment

bitschmidty

ACK

_posts/en/newsletters/2020-04-29-newsletter.md

bitschmidty · 2020-04-29T10:45:22Z

Squashed and merged.

Lots of thank yous this week!

Authors: @harding, @adamjonas
Reviewers: @jonatack, @ariard, @ZmnSCPxj, @TheBlueMatt, @jnewbery

harding marked this pull request as draft April 24, 2020 20:37

harding changed the title ~~2020 04 29 newsletter~~ Newsletter 95 (2020-04-29) Apr 25, 2020

harding force-pushed the 2020-04-29-newsletter branch from 9110040 to ca4ca43 Compare April 25, 2020 10:30

Newsletters: add 95 (2020-04-29)

4c99ca8

harding force-pushed the 2020-04-29-newsletter branch from ca4ca43 to 01611c0 Compare April 25, 2020 10:34

harding marked this pull request as ready for review April 26, 2020 17:56

jonatack reviewed Apr 27, 2020

View reviewed changes

ariard reviewed Apr 27, 2020

View reviewed changes

ZmnSCPxj approved these changes Apr 27, 2020

View reviewed changes

jonatack reviewed Apr 27, 2020

View reviewed changes

TheBlueMatt reviewed Apr 27, 2020

View reviewed changes

jnewbery reviewed Apr 27, 2020

View reviewed changes

harding mentioned this pull request Apr 28, 2020

Newsletter 96 (2020-05-06) #395

Merged

3 tasks

add Bitcoin Core 15761

1f4205b

harding force-pushed the 2020-04-29-newsletter branch from 9738eac to abb70e8 Compare April 28, 2020 12:48

jnewbery reviewed Apr 28, 2020

View reviewed changes

jonatack reviewed Apr 28, 2020

View reviewed changes

bitschmidty reviewed Apr 28, 2020

View reviewed changes

_posts/en/newsletters/2020-04-29-newsletter.md Show resolved Hide resolved

harding force-pushed the 2020-04-29-newsletter branch from 5910db1 to 64623e5 Compare April 29, 2020 05:56

harding and others added 3 commits April 29, 2020 05:09

News95: add lede, action items, news, RCs, and notable commits note

eb7f80e

News95: add stack exchange

1b37626

News96: add description of Bitcoin Core PR17509

f1373e3

bitschmidty force-pushed the 2020-04-29-newsletter branch from 64623e5 to f1373e3 Compare April 29, 2020 10:15

bitschmidty merged commit 051321e into bitcoinops:master Apr 29, 2020

Newsletter 95 (2020-04-29) #394

Newsletter 95 (2020-04-29) #394

Uh oh!

Conversation

harding commented Apr 24, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

ariard 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!

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!

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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

harding commented Apr 27, 2020

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!

jonatack Apr 27, 2020 • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

harding commented Apr 24, 2020 •

edited

Loading

jonatack Apr 27, 2020 •

edited

Loading