Eclipse Attacks #17
Eclipse Attacks #17
Conversation
| @@ -1,606 +1,105 @@ | |||
| \newpage | |||
There was a problem hiding this comment.
I struggled a bit with positioning "you" the reader as the attacker or victim based on the scenario described. Maybe it would be less confusing. to have them be one or the other but not "shift" this point of view throughout? But maybe it's not so confusing. What do you think? Can you let me know if it's hard to follow or if the switching isn't so problematic?
There was a problem hiding this comment.
We could stick to "you" being the user, and the potential victim. I've already changed this in most places.
|
|
||
| Sjors: | ||
| So an eclipse attack is when your node is only seeing your enemy, basically. Your attacker. Your node has connections that it makes to the outside world and there are people who connect to your node. | ||
| Then, it turns out this person is actually sending you that transaction over the wire, but to the outside world, they're sending a very different transaction. And so then a new block arrives, but you're not going to see that block because the user is sending a conflicting transaction — most likely coins to themselves. |
There was a problem hiding this comment.
I don't really understand what this is doing here. Is there a clearer way to write it, or an image that can illustrate it? Is what they're doing called a zero confirmation transaction? And in the last paragraph where it says "you," we mean the hypothetical attacker and not the person being attacked, correct?
"Then, it turns out this person is actually sending you that transaction over the wire, but to the outside world, they're sending a very different transaction. And so then a new block arrives, but you're not going to see that block because the user is sending a conflicting transaction — most likely coins to themselves.
Nowadays, people know that accepting zero confirmation transactions is a bad idea for various reasons, but this is the easiest thing you can do when you can basically hide what's happening: You can tell this person one thing that you paid them and tell other people another thing."
There was a problem hiding this comment.
I rewrote this in 158228c and it's hopefully more clear now. I explained in more detail what a double-spend actually is. Indeed this is a zero confirmation transaction, but worse still, it's a different (mutually incompatible) zero confirmation transaction for you vs. the rest of the world.
|
|
||
| Sjors: | ||
| And if all those connections are to some evil person, then you think you're talking to the whole world, but you're actually only talking to one person so that person is eclipsing your view of the world. | ||
| If you do wait for a confirmation, they can still attack you using an eclipse attack, but it's going to get a lot more expensive, so they'll have to produce a valid block. |
There was a problem hiding this comment.
Are they doing an eclipse attack in both situations (or rather, is it possible with unconfirmed and confirmed transactions)?
"If you do wait for a confirmation, they can still attack you using an eclipse attack, but it's going to get a lot more expensive, so they'll have to produce a valid block."
There was a problem hiding this comment.
Yes. First we explain what an eclipse attack can do using just unconfirmed transactions. And then we level up to confirmed transactions (producing alternative blocks).
I renamed the section to "Why an Eclipse Attack Hurts" because here we just take as a given that it's possible and show the consequences. In the next section we explain how to eclipse a node.
(although the first paragraph does briefly explain what being eclipsed looks like, but again not how it's done)
|
|
||
| Aaron: | ||
| Exactly. Yeah. Bitcoin is a peer-to-peer network so it consists of peers that talk with each other and I think an average, regular nodes connects to how many peers? | ||
| When they give you that block, it includes the transaction, so you think it's confirmed. However, the outside world of normal miners is also producing blocks, and the attacker is hiding those normal blocks from you. And for the normal miners, your transaction never happened, because there's a longer chain that's not paying you. Instead, you've just accepted the one block or maybe multiple blocks. And the attack gets more expensive as they have to produce more blocks. |
There was a problem hiding this comment.
There was also some confusion in here who they/them was but I think I have it correct. Please let me know or change it if it's wrong.
The part I'm hung up on is from "one block or...." to the end. So you've accepted the one block or multiple blocks that are.... fake? Or how would you describe them?
Furthermore, I don't quite get who is producing more blocks and why, and how that makes it more expensive? The attacker is making more blocks and it's more expensive for them? Why? In what way? Data consumption? Actual money?
"When they give you that block, it includes the transaction, so you think it's confirmed. However, the outside world of normal miners is also producing blocks, and the attacker is hiding those normal blocks from you. And for the normal miners, your transaction never happened, because there's a longer chain that's not paying you. Instead, you've just accepted the one block or maybe multiple blocks. And the attack gets more expensive as they have to produce more blocks."
There was a problem hiding this comment.
The they/them bit is correct, but I still changed this paragraph a bit, to clarify how this attack works.
So you've accepted the one block or multiple blocks that are.... fake? Or how would you describe them?
Hopefully it's more clear now. The blocks are not fake. They are real, but they are not part of the longest chain / branch. I moved the footnote about stale blocks from the Taproot chapter here, because this concept is important.
There was a problem hiding this comment.
who is producing more blocks and why, and how that makes it more expensive
Producing a block costs money (mainly for equipment and electricity). Normally a miner recoups this by selling the coins created in the coinbase transaction. This includes a fixed subsidy (currently 6.25 BTC and halving every 4 years) and all the fees paid by transactions in the block. This coinbase transaction creates coins "out of nowhere" (but subject to the before mentioned limit) and sends it to wherever the miner wants (usually an address managed by a mining pool, which then redistributes it).
Normally a miner produces a block that builds on top of the most recently mined block that they're aware of. The coinbase transaction coins are locked up by the protocol rules until they have 100 confirmations, i.e. until there are 100 blocks built on top of it.
The attacker here does not do this. They instead try to create a block on top of whatever the last block is that their victim saw. And they don't broadcast this block to the world, so no other miners will mine on top of it. This means the coinbase transactions never reach 100 confirmations so the costs of producing the block can't be recouped. It makes no economic sense for a miner to do this, unless they benefit from the attack in some other way (or unless they're duped, as we explain below).
There was a problem hiding this comment.
I added this clarification in c7f2e3c
|
|
||
| Sjors: | ||
| Yeah to himself probably. | ||
| One very simple solution for avoiding an attack like this is to have more buckets. Another is to remove the bias toward selecting more recent peers and discarding the old ones. However, the tradeoff is you don't want to prioritize old IP addresses, because they might not be there any longer. |
There was a problem hiding this comment.
I don't know if "avoid" is the correct word here. It's what I used, but is something else (maybe circumvent?) a better word?
"One very simple solution for avoiding an attack like this is to have more buckets."
There was a problem hiding this comment.
"mitigate"
"avoid" suggest that an attack is always prevented, whereas "mitigate" makes it clear that it reduces the odds. But not everyone knows the word, so we should point this out explicitly. It's all about making the attack more difficult and more expensive (but there are always trade-offs).
|
|
||
| Sjors: | ||
| And so you think you've got this unconfirmed transaction and it's going towards you and you're not seeing any new blocks, but you think, okay, I guess, this is good. It's mine. | ||
| A couple years ago, what was merged is something where every now and then, Bitcoin Core looks at a bucket, quickly connects to a node, sees if it's real, and remembers that and then disconnects. This is a way of prioritizing all the addresses in a more intelligent way. |
There was a problem hiding this comment.
Do we have a link to this, what was merged?
"A couple years ago, what was merged is something where every now and then, Bitcoin Core looks at a bucket, quickly connects to a node, sees if it's real, and remembers that and then disconnects. This is a way of prioritizing all the addresses in a more intelligent way."
There was a problem hiding this comment.
I'll sprinkle in some links to various (merged) pull requests.
|
|
||
| Aaron: | ||
| I wouldn't think that Sjors. | ||
| Bitcoin Core 0.21.0 was released in January 2021, and it included a new method to prevent eclipse attacks that was suggested in the 2015 paper.^[To give you an idea about the speed of Bitcoin development, a person can write a paper in 2015, and improvements based on that paper can happen gradually for the next five or more years.] What happens is that when you restart, you try to remember some of the last connections you had. Your node remembers the two connections that it only exchanges blocks with, and it tries to reconnect to those — but not too often, because it's not a good idea to always try to reconnect to the same nodes again when you restart, as, for all you know, the reason you crashed in the first place is because one of those nodes was evil. And in that case, if you connect to the last connect and it goes wrong again, then you don't try reconnecting again. |
There was a problem hiding this comment.
This two numbers feels arbitrary. Why two? Or was this a randomly chosen number? Or just two of the potential X amount of connections?
"Your node remembers the two connections that it only exchanges blocks with, and it tries to reconnect to those"
There was a problem hiding this comment.
I highly suspect it's indeed arbitrary. Maybe the pull request discusses some trade-offs. There are 8 outbound connections, so two is a quarter of that. We generally don't want to make radical changes to how the p2p network behaves, because that can cause huge problems, including accidentally partitioning the network, which would totally defeat the purpose of preventing eclipse attacks (as different partitions might end up with different mempools and different blocks, unintentionally). One the other hand, only 1 might not be enough because if that node can't be reached anymore... so 2 is a nice number. There might really not be more to it.
|
|
||
| Sjors: | ||
| So if you do wait for a confirmation, they can still attack you using an eclipse attack, but it's going to get a lot more expensive. So they'll have to produce a block basically. | ||
| That said, there are some new proposals for reducing the bandwidth needed for these mempool synchronizations that would allow more connections — so there's an incentive to make this data exchange more efficient. |
There was a problem hiding this comment.
I didn't do much with this section yet (this paragraph until the next head) until I'm sure what it's saying. These are proposals beyond what solutions already exist, correct? Should it be in a new section with a new heading?
"That said, there are some new proposals for reducing the bandwidth needed for these mempool synchronizations that would allow more connections — so there's an incentive to make this data exchange more efficient.
Plus, there's the solution that some of the connections you connect to, you don't share mempool stuff with; instead, you only connect to blocks.
One of the ways to have the upside of more connections without the downside of more bandwidth is to only exchange blocks with those extra connections, because that happens much less frequently. This still costs a little bit of an extra bandwidth, but much less.
This. reminds us that you need to wait for confirmations because those extra connections will tell you about new blocks. They won't tell you about new stuff in a Mempool, but that's fine if you wait for confirmations.
Well, I mean, you can always use the block stream satellite or something like that as another source of data. Of course that's not a universal solution, but it is a really-
Sjors:
But there is an incentive for Bitcoin blocks to be broadcast in general, over satellite or AM, or for multiple sources so it's more difficult to eclipse someone because you'd have to eclipse the whole planet, right? If the signal is coming from a satellite, you want to eclipse somebody who's listening to that satellite and you either have to blow up the satellite connection to them or blow up the satellite itself, which everybody would notice and it'd be in the news and you'd say, "Hey, there's probably something going on here."
Aaron:
I like your [inaudible 00:18:00] mindset though, that you do recognize that that's actually a risk that someone blows up the satellite.
Sjors:
Well, I mean, you don't actually physically have to blow it up, I guess. You can just tell people to stop broadcasting to it. One more solution is to have more nodes, basically, that other people don't know are yours. So if you have multiple nodes that you're using for-... your, whatever your services and you make sure that the outside world doesn't know all of them, and they might try to eclipse one of them, but they forgot to eclipse the other ones."
There was a problem hiding this comment.
These are proposals beyond what solutions already exist, correct? Should it be in a new section with a new heading?
It may indeed make sense to add a separate section, e.g. "Indirect Defenses"
This includes 2 projects, that are not themselves a solution to eclipse attacks, but they have that affect indirectly.
The first is Erlay ("some new proposals for reducing the bandwidth needed for these mempool synchronizations that would allow more connections") (it's just 1 proposal)
Erlay reduces the cost (bandwidth) per connection. A lower cost per connection allows nodes to have more connections. Having more connections makes any eclipse attack scheme more difficult. We should just mention that by name. I was planning to include the episode on that in the first edition, but for now it's referenced in @sec:more_eps.
The second is the Blockstream Satellite. It makes it easier to keep up with the blockchain if you're in the middle of nowhere with a slow internet connection. But it can also offer protection against an eclipse attack, if you node receives the satellite signal, even if all inbound and outbound connections are taken over by an attacker, you'll still learn about new blocks. The same would apply to an AM broadcast.
One of the ways to have the upside of more connections without the downside of more bandwidth is to only exchange blocks with those extra connections, because that happens much less frequently. This still costs a little bit of an extra bandwidth, but much less.
This bit is out of place here, we should move it up. It's a specific defense against eclipse attacks, but not mentioned in the paper.
bitcoin/bitcoin#15759
There was a problem hiding this comment.
I ended up dividing this in a somewhat different way, in What Else Can Be Done. See 8831343
|
|
||
| Recent versions Bitcoin Core therefore include an optional feature — ASMAP — to counter these types of Eclipse Attacks. The episode explains how mapping of the internet has allowed Bitcoin Core contributors to create a tool which ensures that Bitcoin nodes not only connect to various Autonomous Systems, but also ensures that they avoid being trapped behind said bottlenecks. | ||
| Recent versions of Bitcoin Core include an optional feature — ASMAP — to counter these types of eclipse attacks. The episode explains how mapping of the internet has allowed Bitcoin Core contributors to create a tool which ensures that Bitcoin nodes not only connect to various Autonomous Systems, but also ensures that they avoid being trapped behind said bottlenecks. |
There was a problem hiding this comment.
Is there a transcript we want to have for this episode, or just share this bit as an added extra and say generally that the mapping allowed for this tool to be created but then not elaborate more in the text?
"The episode explains how mapping of the internet has allowed Bitcoin Core contributors to create a tool which ensures that Bitcoin nodes not only connect to various Autonomous Systems, but also ensures that they avoid being trapped behind said bottlenecks."
There was a problem hiding this comment.
I don't have a transcript for it. I might add a few more sentences, a link to the paper and a link to the implemented solution (ASMAP), but ultimately the reader will just have to listen to the episode.
|
I already made some improvements, but I'll continue tomorrow. Left some replies in the mean time, but those might be outdated by Monday. |
|
Back to you! |
No description provided.