Bitcoin Forum
December 04, 2016, 02:15:18 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: BitCoin Deanonymization  (Read 10423 times)
DavinciJ15
Hero Member
*****
Offline Offline

Activity: 750


Bitcoin - helping to end bankster enslavement.


View Profile WWW
August 05, 2011, 08:30:18 PM
 #21

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!
1480860918
Hero Member
*
Offline Offline

Posts: 1480860918

View Profile Personal Message (Offline)

Ignore
1480860918
Reply with quote  #2

1480860918
Report to moderator
1480860918
Hero Member
*
Offline Offline

Posts: 1480860918

View Profile Personal Message (Offline)

Ignore
1480860918
Reply with quote  #2

1480860918
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
August 05, 2011, 10:12:54 PM
 #22


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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
August 06, 2011, 01:10:35 AM
 #23

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.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
August 06, 2011, 04:59:56 AM
 #24

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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
bcearl
Full Member
***
Offline Offline

Activity: 168



View Profile
August 06, 2011, 12:00:04 PM
 #25

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.

Misspelling protects against dictionary attacks NOT
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
August 07, 2011, 01:53:16 AM
 #26

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.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
August 07, 2011, 02:46:44 AM
 #27

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

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
August 07, 2011, 02:56:21 AM
 #28

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
August 07, 2011, 03:08:52 AM
 #29

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.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
August 07, 2011, 04:26:30 AM
 #30

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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
August 07, 2011, 05:24:38 AM
 #31

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)?

(gasteve on IRC) Does your website accept cash? https://bitpay.com
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
August 07, 2011, 06:03:35 AM
 #32

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
August 07, 2011, 08:03:47 AM
 #33

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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
August 07, 2011, 12:33:12 PM
 #34

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).

(gasteve on IRC) Does your website accept cash? https://bitpay.com
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 07, 2011, 03:30:04 PM
 #35

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.

How often do you get the chance to work on a potentially world-changing project?
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!