Skip to content

Newsletter 95 (2020-04-29) #394

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Apr 29, 2020

Conversation

harding
Copy link
Collaborator

@harding harding commented Apr 24, 2020

  • 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

@harding harding marked this pull request as draft April 24, 2020 20:37
@harding harding changed the title 2020 04 29 newsletter Newsletter 95 (2020-04-29) Apr 25, 2020
@harding harding force-pushed the 2020-04-29-newsletter branch from 9110040 to ca4ca43 Compare April 25, 2020 10:30
@harding harding force-pushed the 2020-04-29-newsletter branch from ca4ca43 to 01611c0 Compare April 25, 2020 10:34
@harding harding marked this pull request as ready for review April 26, 2020 17:56
[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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@ariard ariard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a nice resume :)


## News

<!-- break atomicity == fission attack? -->
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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.

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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

(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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## News

<!-- break atomicity == fission attack? -->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

(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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator Author

harding commented Apr 27, 2020

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

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/than he/than when he/

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/that that/that/

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,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Despite

(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].)
Copy link
Collaborator

@jonatack jonatack Apr 27, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Hehe :)

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

(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].)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@jnewbery jnewbery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great stuff Dave. A few small suggestions inline.

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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: style as:

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

To match byline of other field reports


- **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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

[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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@harding harding mentioned this pull request Apr 28, 2020
3 tasks
@harding harding force-pushed the 2020-04-29-newsletter branch from 9738eac to abb70e8 Compare April 28, 2020 12:48
@harding
Copy link
Collaborator Author

harding commented Apr 28, 2020

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

Copy link
Contributor

@jnewbery jnewbery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- [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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

@jonatack jonatack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


- **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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • 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..."

[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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps begin a new paragraph here for the extended example.

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@bitschmidty bitschmidty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK

@harding harding force-pushed the 2020-04-29-newsletter branch from 5910db1 to 64623e5 Compare April 29, 2020 05:56
@bitschmidty bitschmidty force-pushed the 2020-04-29-newsletter branch from 64623e5 to f1373e3 Compare April 29, 2020 10:15
@bitschmidty bitschmidty merged commit 051321e into bitcoinops:master Apr 29, 2020
@bitschmidty
Copy link
Contributor

Squashed and merged.

Lots of thank yous this week!

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants