-
Notifications
You must be signed in to change notification settings - Fork 137
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
Conversation
9110040
to
ca4ca43
Compare
ca4ca43
to
01611c0
Compare
[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.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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? --> |
There was a problem hiding this 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 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.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
-
"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.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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_delta
s is likely to also reduce payment reliability overall.
|
||
## News | ||
|
||
<!-- break atomicity == fission attack? --> |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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_delta
s 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.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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].) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(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.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -0,0 +1,58 @@ | |||
{:.post-meta} | |||
by Roman Taranchenko |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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} |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping @Christewart
9738eac
to
abb70e8
Compare
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!) |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this 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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK
5910db1
to
64623e5
Compare
64623e5
to
f1373e3
Compare
Squashed and merged. Lots of thank yous this week! Authors: @harding, @adamjonas |
Bitcoin Core #15761
@adamjonasBitcoin Core #17509
@dongcarl