Newsletter 95 (2020-04-29) #394
Conversation
| [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 |
There was a problem hiding this comment.
Big week! Native Descriptor Wallets just made it in as well
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I recommend we stick to the schedule and cover it next week, since this is already a long newsletter.
|
|
||
| ## News | ||
|
|
||
| <!-- break atomicity == fission attack? --> |
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
"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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Given how often it is mentioned, is work on package relay still taking place? See bitcoin/bitcoin#16401 (comment).
There was a problem hiding this 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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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? --> |
There was a problem hiding this comment.
"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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
| 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 |
There was a problem hiding this comment.
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. |
| 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 |
| 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, |
| (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].) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Should the co-author (and original creator, iiuc), Kevin Loaec (spelling?) be named as well?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
I see your point but it begins by stating both names announcing a joint work; perhaps insert "by [both names]" after "prototype"
| (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].) |
There was a problem hiding this comment.
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.
| @@ -0,0 +1,58 @@ | |||
| {:.post-meta} | |||
| by Roman Taranchenko | |||
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
nit: "unaffected are..." sounds a bit unnatural to me. How about "endpoint nodes [...] are unaffected"?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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} | |||
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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} | |||
There was a problem hiding this comment.
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?
|
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!) |
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 |
There was a problem hiding this comment.
nit: "goes on to" doesn't seem quite right here without Murch having done something earlier. I think just "Murch explains" is better.
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 |
There was a problem hiding this comment.
-
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
suggest s/never satisfactorily/not yet|not yet fully/ as per comment
bitschmidty
force-pushed
the
2020-04-29-newsletter
branch
from
64623e5
to
f1373e3
Compare
|
Squashed and merged. Lots of thank yous this week! Authors: @harding, @adamjonas |
Bitcoin Core #15761@adamjonasBitcoin Core #17509@dongcarl