BitCoin Deanonymization

[DavinciJ15]

I'm going to sound like the guy you see on TV that's portrayed to be crazy on TV because of his fear of government.  Well ever since I learned how our monetary system worked and researched the truth about governments I personally know without a doubt that deanonymization is a bad thing.

Just my 2 bit cents that I don't believe anyone will listen to just like when I started telling all my friends and family how the monetary system works.  They are slowly starting to listen as things get worse and worse.  So why go down a path that has been historically BAD!

[1714929781]

1714929781

[1714929781]

1714929781

[1714929781]

1714929781

[1714929781]

1714929781

[jgarzik]

The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks.  Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background.  The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.

[Steve]

The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks.  Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background.  The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.

Yeah, but what makes me nervous is that someone with that kind of power could lay in wait for an indefinite period of time...spending whatever it takes to remain substantially ahead of the network...waiting for the most opportune time to reveal themselves and completely undermine bitcoin.

[jgarzik]

The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks.  Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background.  The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.

Yeah, but what makes me nervous is that someone with that kind of power could lay in wait for an indefinite period of time...spending whatever it takes to remain substantially ahead of the network...waiting for the most opportune time to reveal themselves and completely undermine bitcoin.

That is one of the reasons why the Satoshi Client includes hardcoded block chain checkpoints.

[bcearl]

The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks.  Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background.  The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.

Yeah, but what makes me nervous is that someone with that kind of power could lay in wait for an indefinite period of time...spending whatever it takes to remain substantially ahead of the network...waiting for the most opportune time to reveal themselves and completely undermine bitcoin.

That could cause a pretty big chaos, but is no real danger of cheating.

[Steve]

The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks.  Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background.  The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.

Yeah, but what makes me nervous is that someone with that kind of power could lay in wait for an indefinite period of time...spending whatever it takes to remain substantially ahead of the network...waiting for the most opportune time to reveal themselves and completely undermine bitcoin.

That is one of the reasons why the Satoshi Client includes hardcoded block chain checkpoints.

That is a simple, practical solution that effectively accomplishes the same result.  What about doing something less manual and less sporadic though?  I've often wondered whether it would make sense to simply not allow reorgs beyond a certain depth at all (which is practically speaking what the exponentially more difficult reorg proposal does).  If you happen to get stuck on a dead branch, you would need to take manual steps to force your client to recognize the chain that the rest of the network recognizes.  Most normal splits/reorgs occur when a couple blocks are generated at nearly the same time.  If the network is well maintained and clients have a handful of well connected nodes they can reliably connect with (and those are well connected to each other), it should be an extremely remote situation where a reorg goes more than a couple blocks deep.  I wonder if you could even be as aggressive as not allowing any reorg of more than 6 blocks deep.

[error]

The longest reorg I'm aware of was 25 blocks. Someone correct me if I missed one.

[theymos]

The longest reorg I'm aware of was 25 blocks. Someone correct me if I missed one.

The one after the overflow bug was 54 blocks. If all old clients had ignored the longer chain because the split was too far back, then lots of damage could have been done by the attacker.

[error]

The longest reorg I'm aware of was 25 blocks. Someone correct me if I missed one.

The one after the overflow bug was 54 blocks. If all old clients had ignored the longer chain because the split was too far back, then lots of damage could have been done by the attacker.

In that case, I wouldn't really be comfortable with automatically locking the chain at less than, say, 5000 blocks.

[kjj]

The longest reorg I'm aware of was 25 blocks. Someone correct me if I missed one.

The one after the overflow bug was 54 blocks. If all old clients had ignored the longer chain because the split was too far back, then lots of damage could have been done by the attacker.

I'm not sure that is a good argument here.

While the current reorg logic was certainly a boon in that situation, and future situations like it are easy to imagine, we should recognize that we are overloading that operation to do something that it wasn't intended to do.

Maybe we should think of a proper mechanism to deal with nodes that are known to have critical bugs, and allow the block chain logic to concentrate on protecting the chain.

[Steve]

The longest reorg I'm aware of was 25 blocks. Someone correct me if I missed one.

The one after the overflow bug was 54 blocks. If all old clients had ignored the longer chain because the split was too far back, then lots of damage could have been done by the attacker.

I'm not sure that is a good argument here.

While the current reorg logic was certainly a boon in that situation, and future situations like it are easy to imagine, we should recognize that we are overloading that operation to do something that it wasn't intended to do.

Maybe we should think of a proper mechanism to deal with nodes that are known to have critical bugs, and allow the block chain logic to concentrate on protecting the chain.

I'm not familiar with what happened with that bug...but in such a circumstance, couldn't you issue an update to the client that fixed the bug as well as fixated on the known good chain?  You then have to convince everyone to start running that new version of the client (and other clients would need updating as well).  But in the case of a serious bug, that has to happen anyway.  To me, there doesn't seem to be any legitimate reason to allow deep reorgs to happen.  About the only thing I could think of is when a large section of the network is cutoff for an extended period of time, but how likely is that to happen?  And if it did, isn't some manual intervention a good idea anyway (you could have features in the client that let you see when there are other chains that would cause a deep reorg and let the user choose to take it or not)?

[theymos]

It would be a good idea for the client to enter safe mode when it sees a deep reorg, but it still must switch chains. Otherwise the network can become permanently segmented, and an attacker that gets control for some time can keep control much more easily. Keep in mind that it is not impossibly expensive to take control of the network for several weeks.

[kjj]

My first thought was an alert message.  Presumably Satoshi had the exact same idea years ago.

The maintainers could generate a key pair for each release, with the public key embedded in each client.  If a critical bug is found in some client, the maintainer signs a message telling the node to notify the operator.  If the message is informational only, and has some anti-spam provisions (embed the message in a transaction sig?), it should be pretty widely accepted by the community.  Each node operator then has the choice of how they want to handle the message.

If I was running a store, and the devs found a critical bug that made my client unreliable, I would set up a handler that disabled my store first, and paged me second.  Operators that ignored the messages would do so at their peril.  Having a deep reorg trigger the same exception handler would be good too.

Theymos is right that having a higher barrier for deep reorgs would allow an attacker to maintain control over some nodes for a longer time (or forever), but under my scenario, those are the nodes with careless operators, which is their own fault.  I'm all in favor of protecting all nodes, even those with careless operators, when it happens for free.  But I'd throw half of the network under the bus if it made the remaining half twice as secure.  Hell, I'm almost at the point where I'd be willing to do it just to stop all of the "51%" threads here.

[Steve]

It would be a good idea for the client to enter safe mode when it sees a deep reorg, but it still must switch chains. Otherwise the network can become permanently segmented, and an attacker that gets control for some time can keep control much more easily. Keep in mind that it is not impossibly expensive to take control of the network for several weeks.

I don't understand this argument...if an attacker successfully generated a few blocks in succession, one of their blocks would indeed become old enough that it is permanently embedded...but so what?  Even if the attacker had 70 or 80% of the processing power, they could only force reorgs say 6 blocks deep...or ~1 hour into the past...and blocks from other miners would still beat out the attacker on occasion (rendering ineffective an attack where legitimate transactions were being ignored).  If this was pervasively happening for some period of time, people could simply start waiting a full 6 (assuming 6 is the point where reorgs are only allowed manually) transactions when dealing with untrusted people (but you could still safely accept transactions immediately when dealing with a counterparty that is trusted).

[Gavin Andresen]

Alternative algorithms for accepting deep block-chain re-orgs sound like a research project to me. Before changing something that critical I would like to see simulations of how different re-org policies behave under different attack scenarios, and non-attack "what if there is a bug that causes an inadvertent block chain split" scenarios.

And I'd like to see a whitepaper that lays out the issues and summarizes simulation results.  And lots of extra credit if it gets peer-reviewed and published in one of the IEEE or ACM journals.