Newsletters: add 101 (2020-06-10) #417
Conversation
| processes allow using Trezor devices to spend segwit inputs, check | ||
| whether your system remains compatible with [Trezor's latest firmware | ||
| update][trezor update]. Other hardware wallets may release similar | ||
| updates in the future, contact the manufacturers for more information |
| - **Time dilation attacks against LN:** Gleb Naumenko and Antoine Riard | ||
| [posted][naumenko td] to the Bitcoin-Dev mailing list a summary of a | ||
| [blog post][td blog] they wrote that itself summarizes a [paper][td | ||
| paper] they wrote about using [eclipse attacks][topic eclipse attacks] |
There was a problem hiding this comment.
perhaps s/wrote/authored/ to avoid "they wrote" twice
|
|
||
| - **Fee overpayment attack on multi-input segwit transactions:** The | ||
| transaction fee for a Bitcoin transaction is the difference between | ||
| the amounts of all the UTXOs that transaction spends and the amounts |
There was a problem hiding this comment.
perhaps s/that/the/
or "the difference between the amounts of the UTXOs that the transaction spends and the amounts of the UTXOs that it creates."
| insufficient. In 2017, Greg Sanders [described][sanders attack] how | ||
| an attacker could send two versions of the same transaction with two | ||
| segwit UTXOs to a hardware wallet. In the first case, the attacker | ||
| would understate the amount of one of the UTXOs being spent; the |
| Unfortunately, signing a single UTXO's amount turned out to be | ||
| insufficient. In 2017, Greg Sanders [described][sanders attack] how | ||
| an attacker could send two versions of the same transaction with two | ||
| segwit UTXOs to a hardware wallet. In the first case, the attacker |
There was a problem hiding this comment.
maybe s/case/one/ here and in the next line
| is the addition of an `asmap` configuration setting that allows | ||
| using a separately-downloaded database to increase Bitcoin Core's | ||
| ability to avoid connecting to too many peers all running on a | ||
| network owned by the same group, increasing it's resistance to |
There was a problem hiding this comment.
Just checking that you meant so say "its" here (no trailing apostrophe)?
There was a problem hiding this comment.
Indeed; quite the unfortunate typo. s/it's/its/
| using a separately-downloaded database to increase Bitcoin Core's | ||
| ability to avoid connecting to too many peers all running on a | ||
| network owned by the same group, increasing it's resistance to | ||
| [eclipse attacks][topic eclipse attacks] (see [Newsletter |
There was a problem hiding this comment.
s/eclipe/erebus/ (EREBUS, per the authors of the paper)
One resource on this is https://bitcoincore.reviews/16702 (disclosure: I wrote it, so I'm biased 😄 )
| - [Eclair #1440][] Accept multiple channels for some API FIXME:adamjonas | ||
|
|
||
| - [Eclair #1141][] adds support for `option_static_remotekey` channels. | ||
| In the case of data loss on your end, this feature allows your channel |
There was a problem hiding this comment.
Note: There are two places where the 3rd-person user is switched to 2nd-person "you" -- this paragraph, and the "Check hardware wallet compatibility" paragraph in Action Items.
There was a problem hiding this comment.
I'm changing this paragraph to third person, but the Action Items section is definitely meant to refer directly to the reader.
| fake1_in_mine -> fake1_out_other; | ||
| fake1_in_other -> fake1_out_mine; | ||
|
|
||
| label = "Perceieved transaction 1\nCalculated fee: 0.0001 BTC"; |
There was a problem hiding this comment.
"Perceived" here and line 34 below (and in the generated svg)
Great work on the diagram!
| through [HWI][topic hwi]. In cases where wallets have full copies | ||
| of the previous transactions or are able to obtain them, restoring | ||
| compatibility should just be a matter of updating the wallet code. | ||
| In other cases where wallets may not store copies of full previous |
There was a problem hiding this comment.
| In other cases where wallets may not store copies of full previous | |
| In other cases where wallets may not store copies of previous full |
There was a problem hiding this comment.
Changing to "full copies of previous transactions", which sounds better to me and matches the phrasing used in the previous sentence.
|
|
||
| A long-term solution to the attack is to change the transaction | ||
| digest so that each signature in a transaction commits to the value | ||
| of all UTXOs being spent in that transaction, making the signature |
There was a problem hiding this comment.
It is a dense sentence. Suggest breaking up.
| of all UTXOs being spent in that transaction, making the signature | |
| of all UTXOs being spent in that transaction. This makes the signature |
There was a problem hiding this comment.
With this proposed change, we'd have two sentences in a row that start with "This". I'll make a slightly more invasive rephrasing to avoid that.
|  | ||
|
|
||
| Similar to the other attack described in Sander's 2017 email (see | ||
| [Newsletter #97][news97 spk commit]), this attack only affects |
There was a problem hiding this comment.
OOC what was newly revealed this week vs. Sander's 2017 email? Why wasn't this discussed more and addressed 3 years ago?
There was a problem hiding this comment.
I don't know what "OOC" means, but as far as I know nothing new has been revealed this week. I think it was discussed a bit more back then (e.g. on IRC) and this summary describes the attempts to resolve it at the protocol layer (e.g. Lau's SIGHASH2 proposal in 2018 and bip-taproot in 2019, both of which we summarized in Optech newsletters).
It appears from Trezor's description that they just learned about this attack when Rashid reported it and I'm guessing that that's also when other hardware wallets learned about it (or through Trezor's own disclosure, as it appears Rashid didn't contact Coinkite (ColdCard) or some other hardware wallet vendors). I've been aware of this attack since shortly after Sander's published his description (I think I first heard about it on IRC) and it never occurred to me that it wasn't known to vendors.
I have a pet theory that Trezor didn't see Sanders's post because it occurred in a thread about PSBT and Trezor has historically been opposed to hardware wallet interface standardization, Ledger has never been really involved in Bitcoin protocol development, and CoinKite hadn't started work on ColdCard at that point.
As to why nobody else worked on it, comments in #bitcoin-core-dev IRC indicate that nobody who knew about the attack for the past three years thought it was particularly urgent. I'll update to sprinkle a few more links through the text. My own personal take on it is that it isn't that severe of an issue but that probably all hardware wallet manufacturers will end up doing the same thing Trezor does just to prevent FUD from other HW manufacturers and to cover their asses against people claiming to lose money due to this vulnerability (whether legitimate or illegitimate---if you're a miner or know a trusted miner, it's easy to fake being a victim of this attack).
There was a problem hiding this comment.
@harding Well said. This is my understanding as well, from the various IRC discussions of the past week.
There was a problem hiding this comment.
At the last wallet meeting Friday, people weren't immediately convinced it was worth patching: http://www.erisian.com.au/bitcoin-core-dev/log-2020-06-05.html#l-346
| spending twice attack, which is an issue with the stateless design | ||
| of most hardware wallets that prevents them from internally tracking | ||
| their own transaction history. | ||
|
|
There was a problem hiding this comment.
Should we also call out the software that is now broken such as BTCPay server and Wasabi if a user upgrades to the latest Trezor firmware? That is another drawback/tradeoff.
There was a problem hiding this comment.
We do this, we just don't explictly name the software that's broken.
This has broken compatibility with several wallets that interface with Trezor devices, either directly or through HWI.
|
Made suggested edits (thanks @jonatack and @adamjonas!), added some links to the recent #bitcoin-core-dev discussion about the fee overpayment attack, and added some additional info about its effect on PSBTs. |
| UTXO to perform the fee calculation. Since legacy transactions can | ||
| be almost as large as one megabyte and it's possible for a spending | ||
| transaction to reference thousands of previous transactions, this | ||
| process can require the processing of gigabytes of data by |
There was a problem hiding this comment.
I think it's important to clarify that this is worst case, and is a somewhat pathological edge-case. Most transactions will only have a small number of inputs, and most of those inputs will only be a few hundred bytes. As worded, this gives the impression that it's common for a transaction's inputs to be gigabytes.
| UTXOs, the hardware wallet would under-calculate the fee by that | ||
| same understated amount. A user would authorize signing the first | ||
| transaction based on its understated fee. The attacker would then | ||
| claim there was some minor problem and the user needs to sign the |
There was a problem hiding this comment.
nit: would claim that there was .... and that the user?
| transaction based on its understated fee. The attacker would then | ||
| claim there was some minor problem and the user needs to sign the | ||
| same transaction again, but would instead get the user to sign the | ||
| second transaction (which would look identical to the user). |
There was a problem hiding this comment.
"would look identical to the user" is confusing since the transactions are not identical. How about "which would appear to be the same to the user since they pay the same outputs and same fee"
| same transaction again, but would instead get the user to sign the | ||
| second transaction (which would look identical to the user). | ||
| Although both transactions produced are individually invalid because | ||
| they each contain one signature that commits to a wrong amount, each |
There was a problem hiding this comment.
I'd remove the part about the invalid signature. The attacker doesn't need to provide a signature at all.
There was a problem hiding this comment.
I don't understand this comment.
There was a problem hiding this comment.
Oh, I misunderstood. I didn't understand that both UTXOs are owned by the victim. Perhaps that needs to be explicitly stated for slow people like me?
| benefits] and [hardware wallets][palatinus inpatient] believed would | ||
| allow signers to safely accept amounts from untrusted programs. | ||
|
|
||
| Unfortunately, signing a single UTXO's amount turned out to be |
There was a problem hiding this comment.
I'd emphasize that the 'attacker' is not able to directly steal any funds from the victim, simply make him burn bitcoin in fees.
| #11][news11 sighash]) and has been included in the [BIP341][] | ||
| specification of [taproot][topic taproot] since its earliest public | ||
| drafts (see [Newsletter #46][news46 digest changes]). If taproot is | ||
| adopted, then it should become perfectly safe for stateless signers |
There was a problem hiding this comment.
Drop "perfectly". Claiming perfection is always dangerous!
| [Bitcoin Improvement Proposals (BIPs)][bips repo], and [Lightning | ||
| BOLTs][bolts repo].* | ||
|
|
||
| - [Eclair #1440][] allows for updating multiple channels via the API. Proposed |
There was a problem hiding this comment.
"allows for updating" sounds a little odd to me (the primary definition of "allow for" is to plan for something that might or might not happen (https://www.merriam-webster.com/dictionary/allow%20for). How about "adds support for updating" or "allows multiple channels to be updated"
| The paper describes an attack that can steal from lightweight | ||
| clients in as little as two hours. For attacks against LN nodes | ||
| backed by a local Bitcoin full verification node, their shortest | ||
| duration attack requires eclipsing the victim for at least 24 hours. |
There was a problem hiding this comment.
In fact that's few hours, depending on implementation time-locks (see Table 1 : Default timelock (in blocks), timeout policy).
You can also note, due to the lack of hardened eclipse protection in lightweight client and low-number of deployed lightweight servers, this attack is practical with high-chances of success today, assuming you have a channel with the victim.
| duration attack requires eclipsing the victim for at least 24 hours. | ||
| The authors note that the attacks probably apply to other | ||
| time-sensitive contract protocols and that the best solutions to the | ||
| problem all involve improving eclipse attack resistance. |
There was a problem hiding this comment.
The AltNet prroposal (bitcoin/bitcoin#18988) has been quite motivated by this research. The current base layer p2p assumptions are limited with regards to LN security model.
There was a problem hiding this comment.
Blog post invite future research on inter-layer mapping or native-LN attacks. For more context, see IRC logs of LN dev meeting of today, which is about relevance of those topics.
|
Pushed two commits for the fee overpayment section. One commit adds info about Ledger's response (and so makes some of the previous Trezor-focused text more generic); the other commit makes the changes suggested by @jnewbery. The paragraph that contained the actual attack description is almost completely rewritten (and now two paragraphs), so re-review there would be appreciated. @jnewbery's and @ariard's comments for other sections of the newsletter haven't been addressed yet. I'm heading out to breakfast now, but I'll get to them within a few hours. |
|
Review club writeup in #419. |
| Ledger has made a similar change, although their [support | ||
| article][ledger update] says they only display a warning when | ||
| spending segwit UTXOs without full copies of their previous | ||
| transactions. Although requiring previous transactions does |
There was a problem hiding this comment.
Maybe avoid "although" back to back. "Requiring...attack. Nevertheless, there are also arguments..."
There was a problem hiding this comment.
I think you missed a golden opportunity to start your comment by saying: "Although all those althoughs..." :-)
| spending segwit UTXOs without full copies of their previous | ||
| transactions. Although requiring previous transactions does | ||
| maximize user safety against this attack, there are also arguments | ||
| for allowing hardware wallets to optionally continue to use segwit's |
There was a problem hiding this comment.
perhaps s/to use/using/ to align with "rather than breaking"
There was a problem hiding this comment.
Bitcoin Core PR opened yesterday on this by Andrew Chow: bitcoin/bitcoin#19215
As well as in HWI: bitcoin-core/HWI#340
| order to eliminate bugs, enhance security, and prepare for future | ||
| changes. One forward-looking change that's attracted some attention | ||
| is the addition of an `asmap` configuration setting that allows | ||
| using a separately-downloaded database to improve Bitcoin Core's |
| - [LND #4251][] brings its REST interface's list of supported non-streaming | ||
| messages to parity with that of its gRPC interface. Previously, only a subset | ||
| of these messages (specifically those of the `Lightning` subserver) were | ||
| available via the REST interface. This is PR will be followed by [LND |
| print a warning when processing segwit inputs received from | ||
| non-updated software. Other hardware wallets may release similar | ||
| updates in the future; contact the manufacturers for more information | ||
| about their plans. See the *news* item below about the fee |
| ability to avoid connecting to too many peers all running on a | ||
| network owned by the same group, increasing its resistance to | ||
| [eclipse attacks][topic eclipse attacks] such as the [Erebus | ||
| attack][] (see [Newsletter #83][news83 asmap]). However, one of the |
There was a problem hiding this comment.
Likely depends on who one talks to, but I'm not sure the terminology and description is ideal:
-
The asmap feature and discussion specifically targeted Erebus: see p2p: supplying and using asmap to improve IP bucketing in addrman bitcoin/bitcoin#16702 and ASN-based bucketing of the network nodes bitcoin/bitcoin#16599.
-
The researchers may be biased but do describe Erebus as a separate, third partitioning attack (see https://erebus-attack.comp.nus.edu.sg, section "How is the Erebus attack different from previous partitioning attacks?"): There are two previous partitioning attacks, i.e., the Bitcoin hijacking (by Apostolaski et al., IEEE SP'17) and the Eclipse attack (by Heilman et al., USENIX Sec'15), followed by a table that details the distinguishing characteristics.
There was a problem hiding this comment.
Perhaps the question is whether "eclipse attacks" has become a generic term for partitioning attacks, separate from the Eclipse attack (2015).
There was a problem hiding this comment.
@jonatack Eclipse Attack is a term that predates Bitcoin. Here's a paper from 2006: https://homepage.divms.uiowa.edu/~ghosh/eclipse.pdf . I don't claim to be an expert, but I think eclipse attack is the generic name for isolating a node from any honest peer so that you can feed it misinformation. Heilman's paper describe several methods for eclipsing a Bitcoin node, and the Erebus attack describes another method. In short, I think the Erebus attack is a type of eclipse attack (and I previously updated the text to say that).
There was a problem hiding this comment.
@jonatack Eclipse Attack is a term that predates Bitcoin. Here's a paper from 2006
TIL - thanks! Will read.
|
Pushed edits for review feedback (thanks everyone!), plus a few small edits of mine to @jonatack's Bitcoin Core PR Review Club section. ACK @adamjonas @dongcarl and @jonatack contributions (thanks!) |
|
Thanks for the review club review/edits, @harding! |
| of the UTXOs they create, but the amounts of the UTXOs they spend can | ||
| only be found by looking at the previous transactions that created | ||
| those UTXOs. The spending transaction simply commits to the txid and | ||
| location of the UTXOs it wants to spend, requiring other software that |
There was a problem hiding this comment.
Location is ok, but perhaps 'output index (vout)'?
There was a problem hiding this comment.
Changing s/location/position/. "Output index (vout)" is exactly the phrasing I'd use if I wanted to be precise, but in this case I just want to explain that the hardware wallet needs the full previous transaction (sans witness) in order to calculate the txid.
| wallet to store that data plus require rescanning the block chain | ||
| for past wallet transactions. Software that creates or updates | ||
| [Partially Signed Bitcoin Transactions][topic psbt] (PSBTs) will | ||
| need to be [upgraded][Bitcoin Core #12915] to include the full copies |
There was a problem hiding this comment.
Seems to be the wrong link
There was a problem hiding this comment.
Transposition 🤦 Thanks!
| [news97 spk commit]: /en/newsletters/2020/05/13/#request-for-an-additional-taproot-signature-commitment | ||
| [trezor post]: https://blog.trezor.io/details-of-firmware-updates-for-trezor-one-version-1-9-1-and-trezor-model-t-version-2-3-1-1eba8f60f2dd | ||
| [bip341 all amounts]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-17 | ||
| [news96 qr]: https://bitcoinops.org/en/newsletters/2020/05/06/#qr-codes-for-large-transactions |
There was a problem hiding this comment.
s/
https://bitcoinops.org/en/newsletters/2020/05/06/#qr-codes-for-large-transactions
/en/newsletters/2020/05/06/#qr-codes-for-large-transactions
| [hw security]: https://en.bitcoin.it/wiki/Hardware_wallet#Security_risks | ||
| [towns benefits]: https://bitcoincore.org/en/2016/01/26/segwit-benefits/#signing-of-input-values | ||
| [palatinus inpatient]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013248.html | ||
| [news11 sighash]: https://bitcoinops.org/en/newsletters/2018/09/04/#proposed-sighash-updates |
There was a problem hiding this comment.
s/
https://bitcoinops.org/en/newsletters/2018/09/04/#proposed-sighash-updates
/en/newsletters/2018/09/04/#proposed-sighash-updates
| `sortedmulti` addition to the [output script descriptor][topic | ||
| descriptors] language that can make it easier to watch multisig | ||
| addresses generated from lexicographically sorted keys, such as those | ||
| used with ColdCard's native multisig support ([#68][news68 |
|
ACK dec3b0b edits. |
| commits to an incorrect UTXO amount. The compromised software then | ||
| claims that there was some minor problem that prevented the | ||
| transaction from being broadcast and tells the user they need to | ||
| re-sign the transaction, but the wallet doesn't re-send the first |
There was a problem hiding this comment.
s/wallet/software/. You've distinguished between 'hardware wallet' and 'compromised software' up to this point. Using the word wallet here is confusing.
|
ACK 7e9828f 🏋️ |
bitschmidty
force-pushed
the
2020-06-10-newsletter
branch
from
7e9828f
to
1ed516b
Compare
|
Great newsletter, great teamwork! |
Eclair #1440@adamjonasLND #4251@dongcarl