I've been able to get around all of those, I'm actually stuck at the DB4.7 stuff. I build it directly from the source and during the compile I get an error: db_cxx.h:1083: error: expected class-name before ‘{’ token
I checked the header file, I think there is a syntax error, but not sure. Any suggestions? This is the block of code it stalls at, the class is defined at the top of the file, so I'm not sure why it hangs at that error without digging through all the Berkeley DB code. I don't want to go to a newer version of the DB if it's going to mess with everyone's BitCoin database that uses this build. // Almost any error in the DB library throws a DbException.
// Every exception should be considered an abnormality
// (e.g. bug, misuse of DB, file system error).
//
class _exported DbException : public __DB_STD(exception)
{
public:
virtual ~DbException() throw();
DbException(int err);
DbException(const char *description);
DbException(const char *description, int err);
DbException(const char *prefix, const char *description, int err);
int get_errno() const;
virtual const char *what() const throw();
DbEnv *get_env() const;
void set_env(DbEnv *dbenv);
DbException(const DbException &);
DbException &operator = (const DbException &);
private:
void describe(const char *prefix, const char *description);
char *what_;
int err_; // errno
DbEnv *dbenv_;
};
|
|
|
|
|
Ok, got around the encryption issue (guess it's never going to be part of the Cent OS library since they don't use that part of openssl), legal issues aside, just left with the DB issues during compile, so I'll need to compile a db4.7 version and hopefully we'll have a test build here soon.
|
|
|
|
Apparently, even after copying over the header file; those libraries are disabled, grrrr. Guess I'll have to hack one together  |
|
|
|
|
My first obstacle is the missing ecdsa.h (Elliptic Curve Digital Signature Algorithm) file. It's listed in the man pages for CentOS, but missing from the package, WTF?
Anyway, I guess I can copy it from somewhere else, hopefully I'll have some binaries for us all soon.
|
|
|
|
Looks like "best block chain" does not simply mean "longest chain of blocks" but "highest sum of difficulty". check main.cpp CBlock::AddToBlockIndex pindexNew->bnChainWork = (pindexNew->pprev ? pindexNew->pprev->bnChainWork : 0) + pindexNew->GetBlockWork()
...
if (pindexNew->bnChainWork > bnBestChainWork)
...
now, what does GetBlockWork() do? main.h CBigNum GetBlockWork() const
{
return (CBigNum(1)<<256) / (CBigNum().SetCompact(nBits)+1);
}
So a single block of the real chain at 200 difficulty is "worth" 200 blocks of your 1.0 chain... Cool, actually a double-wham to the attack then because it's worth is better defined by how much CPU time it took to create it, thanks for pointing that out. |
|
|
|
I'm not quite sure how this attack can work because it has the following pre-requisites:
1) that you can generate blocks faster than the rest of the network
2) that you can do so without being subject to the same target modification rules
As I see it, assuming you have so much processing power that you can outpace the network, when you are doing your block generation, you will still have to adjust the target using the same algorithm or when you start posting your blocks to the network, they're going to get rejected because you weren't obeying the target value rules, therefore, I don't see how you could actually permit yourself to generate blocks more cheaply by not announcing them.
Connect two PC together with the -connect=XXX.XXX.XXX.XXX command line to both machines with a fresh install, and both will start generating blocks from the genesis block and start building up the network again. Get enough PC going, you'll be able to keep the 1 per 10 minutes generation up to a constant level since the difficulty will always be a 1.000 After a while, you would have a perfect block chain from to finish in which those two PCs own all the coin and with the constant generation rate, overtake the flux rates that are seen out in the public network (where one block takes 8,000 seconds to find sometimes, your little network is doing a constant block every 300 seconds, eventually it would catch up and surpass the real chain) |
|
|
|
Cool, we could both use a build then  |
|
|
|
Does anyone have the binary?
Which version? I haven't tried to build any yet, but after building on a few different distro so far, kind of got the process down pat. I've got a CentOS 5.5 machine I could experiment with. |
|
|
|
Why can't you start working from the lockin? Ah, because you don't get the difficult set back to 1 that way.
Exactly, you start at 244 for example and a few machines won't ever generate enough blocks to overtake the correct chain since it's being powered by thousands of clients now. |
|
|
|
That's what I was looking for. It's locked along the way with hard-coded hash values, that makes this vector of attack null.
Just because I'm lazy and don't have the code on this machine... You're saying the hash recorded independently by each node outside the block chain? Where is the check-point hash stored and how often? It's located in the code like this. Basically, a block is picked (in this case, the last one was 70567) and the client checks against that point forward. So if you attempt to modify the chain along the way (as what I was doing) at some point, it wouldn't match up properly and the current clients would reject it as fake. The only attack would be to generate from the last snap-shop, but with the difficulty so high from that point, CPU time becomes too expensive. // Check that the block chain matches the known block chain up to a checkpoint
if (pindexPrev->nHeight+1 == 11111 && hash != uint256("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
return error("AcceptBlock() : rejected by checkpoint lockin at 11111");
if (pindexPrev->nHeight+1 == 33333 && hash != uint256("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
return error("AcceptBlock() : rejected by checkpoint lockin at 33333");
if (pindexPrev->nHeight+1 == 68555 && hash != uint256("0x00000000001e1b4903550a0b96e9a9405c8a95f387162e4944e8d9fbe501cd6a"))
return error("AcceptBlock() : rejected by checkpoint lockin at 68555");
if (pindexPrev->nHeight+1 == 70567 && hash != uint256("0x00000000006a49b14bcf27462068f1264c961f11fa2e0eddd2be0791e1d4124a"))
return error("AcceptBlock() : rejected by checkpoint lockin at 70567");
|
|
|
|
I ran into a curious issue with the x64 version of bitcoind for Linux.
I have it running on 8 cores, with the task re-niced to "19" (ie, most nice).
However, it still seems to impact performance of the system for tasks such as compiling and executing, to the tune of 2x speed degradation.
Reducing the number of active cores improves the speed of other tasks, but I have to stop it altogether to let other higher-priority tasks run at full speed. The impact is not subtle -- things that used to take a minute now take two.
I confirmed that the nice level is "19", and the other tasks are at standard "0", yet bitcoind still causes them to take twice as long.
Memory consumption seems reasonable, and it's not swap-happy.
Any ideas?
Yeah, the nice 19 is still half down from 0, so even though the nice level is 19, there are still -19 levels beyond that of prioirty. So while 19 is as low as it gets, your task running at 0 are not at the top of the priority queue. |
|
|
|
It seems that broadcasting your version of block 70,000 or whatever would immediately trigger Reorganize(), which would delete it and make all later blocks invalid. (Assuming I have all the blocks.)
You couldn't modify blocks before ones that are locked in, in any case. (Lockin is at line 1362 of main.cpp.)
That's what I was looking for. It's locked along the way with hard-coded hash values, that makes this vector of attack null. Glad someone already figured this out long ago and locked it in the code. It was a fun exercise in code review at least. |
|
|
|
 that is clever.Is there a way to verify that the current block chain has been generated for an agreed time period?Say it took 1 year to get to the current block length and your competing block chain only took 2 months? I think there was a post a while back that said the block chain was locked to say example:65,000 blocks in the new release client, but I haven't been able to find that post and didn't find anything in the source that suggested it. That would be a way to defeat this reverse time attack up to the point of the block snapshot. |
|
|
|
Interesting! Are you considering going all the way back to the genesis block?
I was presuming you would just wipe out recent transactions. That would require a shorter effort.
If I had to guess, I would say it would be hard (not impossible) to go all the way back to genesis. The reason I think so is the increasing amount of CPU power over time. Every time the difficulty increases, it is because blocks are generating faster on average than 1 per 10 min. There have been many difficulty increases, so therefore I'm guessing that on average since the launch of the system, blocks have been generated faster than 1 per 10 min. If you are trying to fix your rate at 1 per 10 minutes, it would seem you could never catch up.
Doh! I forgot you can fake time itself! That was the whole point of your title! You can generate blocks as fast as you want from your new genesis block! All you have to do is synchronize your network's fake clocks and fake transactions! You could probably wipe the whole list in days if you tried!
Woot! Nice attack!
Do the nodes not keep the alternate forks incase someone wants to extend them in a chunk later?
I'm not sure, I'm guessing no; if my experiment was any indication since the "real" network wiped out the "fake" network once they synced up. Think of like this, what would happen if you went back in time a few months with your client the way it is now and connected it to the network? Would everyone not see your client as "the longest chain, most up to date" and sync off of that? |
|
|
|
After testing this all day, this might be a real *theoretical* attack vector. But I'm not an alarmist, this is what it would take for it to work. Currently, everyone's client is trying to maintain a "1 block per 10 minutes" average and adjust the difficulty up and down based on how quickly blocks are being generated. The reason the attack *might* be possible is due to the fluctuation in block generation. Basically, it's chaos theory in action and this can be exploited. Example: Here are some recent block generation stats 756 seconds to find block 71953
1485 seconds to find block 71952
252 seconds to find block 71951
592 seconds to find block 71950
226 seconds to find block 71949
310 seconds to find block 71948
Average = 10.08 minutes per block
What my *corrupt* network will be doing is producing a perfect 10 block per minute chain, eventually (months) it will catch up with the real block chain and have a perfect start to finish block chain that is longer than the current block chain being used by all clients. I then take these *corrupt* clients and fuse them into the public network where they have a chain that is significantly longer than what is out there, but the math is perfect from block 1 to the end and by default all the clients will accept this chain, and then they spread it to the next and next, and just like a virus, this new block chain wipes out everyone. The key part is, as controlling the original PCs that made all those blocks, you end up controlling all the BTC in the system. This is a very slow attack and instead of attacking with brute force of thousands of servers, you "kill softly" with only a few PCs maintaining a perfect block cadence production over time. Thus an attack on *time* instead of CPU via chaos. The Trojan is the few PC that are growing the new corrupt network replacement. I'm going to check the current block chain to see if such an attack is likely, I'll report back my further findings. In the mean time, I'm not going to panic, I don't expect anyone else to either. |
|
|
|
|
I have a definitive answer for you all.
I built a test network on 5 computers, each running the client stock (fresh install) and had them all network to each other. They generated blocks all day (it's easy when the difficulty is 1.000), and after some transactions between them all (built up to 50 blocks doing this), I then connected them back to the "outside" world and as soon as they got in sync with the network, all the generated coin and transactions were wiped out and replaced by what is current on the network now.
So to answer your question, if the network is split and merges days/weeks/years later, whoever has the longest block chain (most CPU time) will win and the previous block chain will be wiped.
|
|
|
|
Suppose one client decided to modify CBlock::GetBlockValue() which hardcodes 50 * COIN as nSubsidy to 1000 * COIN and they "complete a block", what would happen? What line of code would catch this mis-match?
Shouldn't these kind of settings be in some kind of "config file" instead of distributed all over the code?
When I tested that, the other clients would ignore the one that decided to generate 1000 BTC a block for example. |
|
|
|
I don't quite understand. Do you mean preparing some chain ahead of time then feeding in a bunch of blocks when you get a valid block?
I doubt that's what you mean since the basic idea is that you can't work ahead because you need the hash from the previous block to start working ahead.
How do you cheat time?
It would be a very slow attack, but basically you grow a block chain with a small private network that is actually churning out blocks every 10 minutes (clients tweaked to go it exactly so there is never a change in difficulty) then after a lot of time (months), you'll have a organic chain that will eventually catch up with the real one and surpass it since the real chain flux around on block creation. What you are doing is cheating the time within the real block chain to eventually surpass it with a chain that always has perfect expansion. It follows the rules of the protocol and thus when finally introduced to the clients would appear to be a perfectly valid chain from start to finish, except you would literally have 99% of all the bitcoins from your private network under your control. |
|
|
|
A few days ago I generated 50.01000000000000 BTC. How is this possible? It has now more than 1000 confirmations.
0.01 for doing a transaction at your PC I would imagine, came from someone else I think. |
|
|
|
I was able to build a dev box with Mandriva 2009 & 2010 and a few tweaks were needed to get a successful build. Mandriva 2009 box gives you builds with Glibc 2.9 (good for those on older distros) Mandriva 2010 box gives you builds with Glibc 2.10 (good for those on last years distros) Think of these as "find & replace" for the default build instructions contained build-unix.txt file that comes with the source. Mandriva 2009 & 2010 Dependencies (packages for easy install) - make
- gcc
- libgtk+2.0_0-devel
- libopenssl0.9.8-devel
- libopenssl0.9.8-static-devel
- libdb4.7-devel
- libdb4.7-static-devel
Boost 1.4 & wxWidgets 2.9.0 instructions work fine from the build-unix.txt file. You will need to make one modification to the "makefile.unix" included in the source. -- Add -I"/usr/include/db4"to the end of the INCLUDEPATHS section at the very top so that it reads something like: INCLUDEPATHS= \
-I"/usr/local/include/wx-2.9" \
-I"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9" \
-I"/usr/include/db4"
Afterwards, you should get a solid compile. Works on both the 32bit and 64bit Mandriva 2009 & 2010 releases. I wanted this to be somewhere searchable so that it could be found by anyone that runs into issues using a Mandriva dev box to build the program from source. Enjoy! |
|
|
|
|
Show Posts
