Bitcoin Forum
October 23, 2016, 11:54:28 PM *
News: Latest stable version of Bitcoin Core: 0.13.0  [Torrent].
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
Author Topic: "Differentiate Protocol version from client version" - denied?  (Read 7082 times)
Mike Hearn
Offline Offline

Activity: 1526

View Profile
June 10, 2011, 08:21:46 PM

Isn't this why we need client diversity? Bad blocks will not be accepted by other clients, having 1/3 of client A, 1/3 of client B and 1/3 of client C will guarantee that no one client will fork the chain.

No, unless all three clients are precisely synchronized in every last detail to Satoshis code it guarantees spurious chain forks. The worst possible configuration is a 55/45 type split between two clients, but A/B/C is also not great - assuming the clients have subtle bugs. If none of the implementations are buggy, no problems.

I assume you mean that the C++ knowledge is needed in order to understand the current client, right?

Sure, but I mean you need to be aware of differences like uint32 vs int32 and so on.

For me it may be a more ideological standpoint that if the developers do not want to merge such a trivial change that will greatly enhance the community by the looks of the discussions - then they do not appear to want 3:rd party developers. The protocol is the heart of a P2P - can you blame people for wanting it somewhat fixed?

Real world protocols have uglyness that isn't worth fixing. My browser identifies itself as Mozilla, Gecko, Safari and Chrome simultaneously. It speaks HTTP/1.1 with extensions that never resulted in a version number bump and HTML "5" that has an ever shifting feature set.

Usually, there are more important problems to solve. I agree it'd have been better to have separate version numbers from the start, but it wasn't done.

That's FUD and bullshit. Seriously, a wrongly implemented client? "fork the blockchain"? "split the economy"?

You might want to read the code of conduct thread in the project development forum. Anyway, consider the worst case scenario. Two clients, A and B. A is Satoshis code and B is from somebody else. They have roughly equal usage.

During the implementation of B, by mistake the third condition in CheckBlock wasn't copied:

    if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
        return error("CheckBlock() : block timestamp too far in the future");

Things work just fine for months, then one of two things happens. A miner whose clock is set wrong finds a block using client B and broadcasts it. Or, somebody notices the bug and decides to exploit it by deliberately mining a block with a far future timestamp.

Once this bad block is broadcast, the chain splits in two because client A refuses to accept it and the miners keep working on the existing block. But client B accepts it and begins building on top of it. The bogus chain B is now ahead of chain A ensuring the bad clients keep building on it.

This situation is pretty disastrous. Things will seem to work at first, because the same transactions will be accepted by both chains, but it has halved the network speed/security. Worse, double spending is now easily possible because the network can be turned against itself.

If you notice the split has happened, or were expecting it, you can broadcast a tx that sends the contents of your wallet to a new address you control. The tx has an nLockTime set to the current height of chain B and a low sequence number. It is immediately considered final and included by clients on chain B because their chain is one block ahead of chain A, but clients on chain A will wait a block before including it. After a block including your tx is broadcast on chain B, you broadcast a replacement tx changing the destination address to another new address you control. Clients on B ignore it because it's a double spend, but clients on chain A accept it because that tx wasn't finalized yet.

Congratulations, you just doubled your money - temporarily. You can now find merchants who are on chain B and spend your wealth with them to get whatever you want, safe in the knowledge that when the chains re-merge those spends will all be undone. Whilst you're doing this, the Bitcoin devs are running around like crazy trying to find/contact miners on chain B to get them to stop mining so A can overtake it. But, there's no central registration point for miners or even an announcements mailing list, so this will take a while. There will also need to be a crash upgrade of miners using client B to avoid the same bug being exploited over and over again.

Once the split occurs, there is less than 24 hours available to re-merge the chains before newly minted coins mature, become spendable and causing even more rolled back transactions.

Such an event would cause chaos and seriously undermine confidence in the whole Bitcoin system. Worse, if you have one such bug, it's a reasonable inference you weren't thorough enough, so attackers will immediately start looking for more.

This is why it's absolutely critical that re-implementations match the behavior of Satoshis code in every last detail, including features that aren't being used today. There are a lot of details in Bitcoin, so that's not easy to do, and the costs of failure could be very high if you client becomes popular.
         ▄▄██▀▀▀               ▀▀▄▄
      ▄▄█▀                         ▀▀▄
    ▄█▀                        ▄▄▀▀▀▀▀█
  ▄██                     ▄▄█▀▀     ▄▀
 ██▀                 ▄▄██████▄    ▄▀
███               ▄▄██████████▄  ▀
██             ▄▄█████████████▀
██          ▄▄█████████████▀
██        ▄ ▀██████████████
██▄    ▄██▀▀  ▀▀████████▀
 ██   ██▀        ▀▀████▀
  ██ █▀
  █▄ ▀▄
 ▄▀    ▀▄





           ▄▄▄▄█  ▄█     ▀▀▀▀▄▄▄▄
▄▄▀▀▀▀▀▀▀▀▀   █  ▀ █            ▀▀▀▀▄
█  █▄        ▄▀                    ▄▀
▀▄ █ ▀       █         ▄           █
 █          █        ▄██▄         ▄▀
 █         ▄▀     ▄██████▄       ▄▀
 ▀▄        █    ▄█████████▄      █
  █       █      ██████████▄    ▄▀
  █      ▄▀        ▀████████   ▄▀
  ▀▄     █        ▄████▀▀▀▀    █
   █    █          ▀▀▀█       ▄▀
   █   ▄▀                    ▄▀
   ▀▄  █                     █
    █  ▀▄▄              █ ▄ ▄▀
    █     ▀▀▀▀▄▄▄       █▀ ▄▀

▄▀▄           █           ▄▀▄
█   █         ▄█▄         █   █
█     █        ███        █     █
█       █       ███       █       █
█         █     █████     █         █
█           █    █████    █           █
█             █   █████   █             █
█▄▄▄▄▄▄▄▄▄▄▄▄▄█   █████   █▄▄▄▄▄▄▄▄▄▄▄▄▄█
▀███████████▀    █████    ▀███████████▀
▀▀▀▀▀▀▀▀▀       ███       ▀▀▀▀▀▀▀▀▀






Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Offline Offline

Activity: 1358


View Profile WWW
June 10, 2011, 09:06:38 PM

Your example only works in the very specific context of two clients with roughly 50% hashing power each.

The attack/bug you describe is absolutely impossible with more than two equally distributed implementations.

The moment you introduce a C client that has 33% of the network power, a bug in client B will have no other consequences than to trigger a couple of chain reorgs for B miners before someone notices something is wrong in the B client implementation. End of story.

That's why I think and maintain that the point you spread is pure FUD.

Hero Member
Offline Offline

Activity: 504

View Profile
June 10, 2011, 11:00:08 PM

...and if the client version were allowed somewhere an honest but buggy alternate implementation could have detected that it had diverged from the satoshi code and disabled itself.

Alternate umplementers are unlikely to want to break things, but it's made hard for them to be helpful without this sort of extra information being allowed. Seriously, how hard would it be to redesignate the (now unused) subversionnum field as clienr version? It could be done now while there are no alternates and allowed to propagate for a few official versions, but the devs are denying it.  Oh well.

Gavin Andresen
Offline Offline

Activity: 1652

Chief Scientist

View Profile WWW
June 11, 2011, 05:11:41 AM

Busy... very busy...

How often do you get the chance to work on a potentially world-changing project?
Offline Offline

Activity: 1470

View Profile
June 15, 2011, 06:10:42 AM

Several mini-proposals related to protocol version were just posted to the bitcoin-development list.

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

Activity: 98

View Profile
June 15, 2011, 06:54:15 AM

Would be nice if there was one downloadable document containing the complete Bitcoin specification. Would be nice if the specification were set up in a way that it wouldn't have to change anymore. Would be nice that if it had to change, all the community would have a vote in it. Whole lotta woulds, I know...

Those are all systemic changes that can be sufficiently provisioned by voting with your feet. I think there's potential for your ideas but they are firmly biased toward top down management. I can't hide the fact that it sets off all sorts of triggers.

What would help is libxcwallet, libxcpolicy, libxcinterface. xc stands for any coin. We will want to interoperate with bitcoin competitors as well.

Means: Code, donations, and brutal criticism. I've got a thick skin. 1Gc3xCHAzwvTDnyMW3evBBr5qNRDN3DRpq
Full Member
Offline Offline

Activity: 142

Security Enthusiast

View Profile WWW
June 24, 2011, 08:39:39 PM

I like the idea of including the protocol version.

I'm not quite sure how we managed to get onto the topic of different clients implementing the protocol differently, but I personally can't see how adding an extra field (particularly while most people use the most recent version of the original bitcoin client) could cause any harm.  Assuming the protocol remains backwards compatible and miners accept blocks with the new field.

If I am missing something though, feel free to try to explain it in somewhat different words.

Security Enthusiast
PHP Coder

Not that I expect anyone to, but should you like my post, please donate:
Donate: 1BRbfqii6Sm9tEUE8A16H7QeDmYFjyBZ7V
Offline Offline

Activity: 70

View Profile
June 26, 2011, 04:01:17 PM

What would the goal be for multiple implementations of the core logic?  Different languages or something?
Pages: « 1 [2]  All
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!