Bitcoin Forum
May 24, 2024, 05:42:07 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 »
141  Alternate cryptocurrencies / Altcoin Discussion / Re: Possible 51% Attack on fairbrix (fbx) on: October 03, 2011, 02:47:12 PM
Well, the most recent 100 fbx blocks took ~63 sec average at diff 0.00390625, that's about 266kH/s. so someone with a bit more hashrate than our forker could pull pretty much the same stunt even now.
Any relaunch would start with way less miners on it, so it could potentially be fucked with the same way by the same guy(s), unless it's *started* with well > 250kH/s, or block acceptance rules are changed to make orphaning a existing decently-length chain a lot harder (did anyone ever do this? it'd make giving a fresh node a "fake" chain a lot easier, as in that case the main chain has to be the one with a lot more work than the fake one. But it'd also mean a rogue miner would need to have several times (3? 4?) the network hashrate to pull off a "fork the chain".
I'm imagining something simple along the lines of "only accept a new block as the best if it's a direct descendant of the current best block, or if it's total work since the last common ancestor with the current "best" chain is 2 (3? 4?) times higher than the work done in the current best since that common ancestor." *could* work.
It'd also mean network efficency would drop, as miners happening to mine a orphan would get stuck mining completely pointless children of it until the main  chain got ahead at least 4 blocks... and if they're > 25% of total network hashrate, their client won't *ever* notice as their fork keeps growing fast enough so the main chain work-since-fork would never hits the 4-times reorg trigger limit.
142  Alternate cryptocurrencies / Altcoin Discussion / Re: Possible 51% Attack on fairbrix (fbx) on: October 03, 2011, 02:21:05 PM
Well, back on topic then, picking apart my local fbx nodes blk0001, ... doesn't look very accidental.
I have a 1327 block chain that was orphaned starting at block 58.
There's a ~4h24m gap from block 57 to what now is the current block 58, and block timestamps after that look "reasonable enough" without huge gaps or long runs of minimum-time-increment blocks, so I'm guessing the attacker didn't fake block timestamps.
By block timestamps, the orphaned chain was mined over 5h57m, the new chain spans 1h33m over the same block #s.
taking hashes/time... the oprhaned original chain was mined at about 65kH/s, the same blocks in the new chain 250kH/s.
And there's something decidedly odd about the block nonces in the new chain, they're ... too high.
Orig chain had nonces averaging out to ~4000 (which is hinting at how many hashes one cpuminer instance is roughly doing between getworks...)
New chain nonces average... about 235000
so either a single cpuminer instance was doing ~60 times what your average cpu does, or they had something like a custom getwork proxy splitting workitems into noncranges and handing the same work with different starting nonces out to a whole bunch of machines (possibly to reduce getwork load?)
but at "only" 250kH/s, why bother with that? pushpool can handle a few 100 mining boxes just fine.
hrrrm... "single cpuminer instance doing 60 times your average hashrate" ... massive NUMA system? single system image cluster? My phenomII X6 @ 3.6GHz does ~3.25kH/s/core and new xeons are probably getting into similar ranges... 64-core server?
Of course this is all pure speculation as I'm only assuming block timestamps weren't faked. If they were, there's no telling how much hashrate it really was.
After that the "odd-noncey" blocks are still appearing for quite a while, noticeably drop off in count after 2016 and nearly completely stop after 4032, there's only 9 blocks with nonce > 100k but not obviously byteswapped after 4032.
Thats another oddity, there's at least one other miner creating "weird" nonces, they're obviously doing em byteswapped (but appears slow-ish, only 32 of those byteswapped nonces in ~600 blocks since 4032).
So overall... yeah, looks like someone with ~250kH/s deliberately orphaned blocks from 57 on to about 1400, then switched to mining legit and got about half of the remaining blocks up to 2016, slowed down for the next 2016 (looks like he went down to about 1-in-5 blocks) and completely stopped after block 4032.
Wild-ass guess... someone had access to a pretty damn massive box or 2, was late to the party and decided to "get all them easy early coins"
Or he might have noticed the weird nonces his setup generates and fixed it somehow.
But my money is on "asshat with access to a large NUMA box (at work?)"
143  Alternate cryptocurrencies / Altcoin Discussion / Re: Possible 51% Attack on fairbrix (fbx) on: October 03, 2011, 12:14:10 PM
hmmm...
http://school.anhb.uwa.edu.au/personalpages/kwessen/shared/Marsaglia03.html

Hope you didn't forget to credit Mr. Marsaglia for the CMWC4096 RNG

Aww how cute artforz. Actually try wikipedia for a simple CWC, it's amazing how bad your google searching skills are, shouldn't be a surprise given you poor programming/copying skills though?
[ ] I realize that "simple CWC" on wikipedia *is* CMWC4096.
144  Bitcoin / Development & Technical Discussion / Re: Difficulty adjustment needs modifying on: October 03, 2011, 11:39:09 AM
It's taking the time over 2015 blocks. Every 2016 blocks. Last time I checked, 2015 != 2016.
In case you still don't get it, is the time taken from the last block with diff X to the first block with diff Y counted? Really?
But honestly, thats just making a elephant of a simple implementation flaw, nothing to do with the theoretical properties of the proper algorithm.
So back on topic... This idea actually looks promising, I yet have to run the numbers but I suspect it'll work "economically" as long as you keep the total adjustment possible over X blocks symmetrical for up vs. down (or even allow quicker up than down adjustment). Still somewhat worried about poisson noise causing issues for a faster-adjusting algo, but I guess that *should* average out over time...
145  Alternate cryptocurrencies / Altcoin Discussion / Re: Possible 51% Attack on fairbrix (fbx) on: October 03, 2011, 10:36:06 AM
Yes, and I have an idea for a chain that will be completely fair, immune to all known attacks, any possible unknown attack and even impossible unknown attacks! Mining it will also produce more power than it consumes. So not only will it revolutionize the global financial economy, it'll also fix the energy crisis, cure cancer and shit rainbows! And it'll be done Real Soon Now(tm).

You? Have an idea?  Grin Please, you take copying to a whole new level. You ruined the comedy act when you started it with "I have an idea". And for what it's worth, when you and your playground chums don't manage to inflict any damage on SC2.0 what then? Going to crawl back into your little house built with failbrix? It's going to be hilarious.
Nah I'm not like artforz, copying other code to solve problems which are simple. Take a look at my block init for example.

Code:
void BlockHash_Init()
{
    static unsigned char SomeArrogantText1[]="Back when I was born the world was different. As a kid I could run around the streets, build things in the forest, go to the beach and generally live a care free life. Sure I had video games and played them a fair amount but they didn't get in the way of living an adventurous life. The games back then were different too. They didn't require 40 hours of your life to finish. Oh the good old days, will you ever come back?";
    static unsigned char SomeArrogantText2[]="Why do most humans not understand their shortcomings? The funny thing with the human brain is it makes everyone arrogant at their core. Sure some may fight it more than others but in every brain there is something telling them, HEY YOU ARE THE MOST IMPORTANT PERSON IN THE WORLD. THE CENTER OF THE UNIVERSE. But we can't all be that, can we? Well perhaps we can, introducing GODria, take 2 pills of this daily and you can be like RealSolid, lord of the universe.";
    static unsigned char SomeArrogantText3[]="What's up with kids like artforz that think it's good to attack other's work? He spent a year in the bitcoin scene riding on the fact he took some other guys SHA256 opencl code and made a miner out of it. Bravo artforz, meanwhile all the false praise goes to his head and he thinks he actually is a programmer. Real programmers innovate and create new work, they win through being better coders with better ideas. You're not real artforz, and I hear you like furries? What's up with that? You shouldn't go on IRC when you're drunk, people remember the weird stuff.";
    BlockHash_1_MemoryPAD8 = new unsigned char[BLOCKHASH_1_PADSIZE+8];  //need the +8 for memory overwrites
    BlockHash_1_MemoryPAD32 = (uint32*)BlockHash_1_MemoryPAD8;

    BlockHash_1_Q[0] = 0x6970F271;
    BlockHash_1_Q[1] = 0x6970F271 + PHI;
    BlockHash_1_Q[2] = 0x6970F271 + PHI + PHI;
    for (int i = 3; i < 4096; i++)  BlockHash_1_Q[i] = BlockHash_1_Q[i - 3] ^ BlockHash_1_Q[i - 2] ^ PHI ^ i;
    BlockHash_1_c=362436;
    BlockHash_1_i=4095;

    int count1=0,count2=0,count3=0;
    for(int x=0;x<(BLOCKHASH_1_PADSIZE/4)+2;x++)  BlockHash_1_MemoryPAD32[x] = BlockHash_1_rand();
    for(int x=0;x<BLOCKHASH_1_PADSIZE+8;x++)
    {
        switch(BlockHash_1_MemoryPAD8[x]&3)
        {
            case 0: BlockHash_1_MemoryPAD8[x] ^= SomeArrogantText1[count1++]; if(count1>=sizeof(SomeArrogantText1)) count1=0; break;
            case 1: BlockHash_1_MemoryPAD8[x] ^= SomeArrogantText2[count2++]; if(count2>=sizeof(SomeArrogantText2)) count2=0; break;
            case 2: BlockHash_1_MemoryPAD8[x] ^= SomeArrogantText3[count3++]; if(count3>=sizeof(SomeArrogantText3)) count3=0; break;
            case 3: BlockHash_1_MemoryPAD8[x] ^= 0xAA; break;
        }
    }
}
BlockHash_1_c=362436;
BlockHash_1_i=4095;
...
BlockHash_1_rand();

hmmm...
http://school.anhb.uwa.edu.au/personalpages/kwessen/shared/Marsaglia03.html

Hope you didn't forget to credit Mr. Marsaglia for the CMWC4096 RNG
146  Bitcoin / Development & Technical Discussion / Re: Difficulty adjustment needs modifying on: October 03, 2011, 10:23:42 AM
Meni Rosenfeld:
I never claimed otherwise, I only answered how I came to the conclusion that "naive algo with asymmetric limits is possibly disastrous".

Zibbo:
Sliding window is a interesting idea, you'd obviously have to reduce the per block adjustment factor and the limits to the 2016-th root to get the same overall adjustment speed as bitcoin, but at first look this should work without introducing new vulnerabilities and result in "smoother" adjustments (obv. not really *faster* if you use factors to end up with bitcoin-equiv adjustment rate, but less... well... blocky).

kano:
That's the whole point, the current network will happily accept chain-of-massive-number-of-low-diff-blocks over chain-of-less-harder-blocks as long as the sum of difficulty of the first is higher and it follows the "rules set in stone" (no invalid tx, generation amount <= calculated amount, difficulty == getNextDifficulty(prevblock), block nTime > median of prev 11 blocks, block nTime can't be more than 2 h in the future, ...).
Assuming someone forks the chain, creating a chain with more work than the real network over the same real time obviously requires the attacker(s) having more hashrate than the rest of the network... you know, kinda the definition of a 51% attack.
And as I already explained, creating such a low-difficulty chain starting at the same nTime as the real chain without having nTime of the forkchain blocks run off into the far future (as real clients wouldn't accept that, see above) *should* be impossible. But it isn't due to the off-by-1 in getNextDifficulty, am I talking Chinese here or something?
147  Alternate cryptocurrencies / Altcoin Discussion / Re: CPU Mining - Who will emerge Dominant? on: October 03, 2011, 10:01:11 AM
Yeap Solidcoin was the earliest with the idea, hopefully theirs won't be so difficult.
No matter what you say SC will always NOT be the first and will simply be an iteration of Tenebrix.

GPU hostility or better known as parallel computing hostility was tried and failed awhile back by cryptographers trying to come up with a hashing solution that couldn't be cracked by the likes of GPU's and FPGA's. Same principle applies here.

Works for me and rather than get greedy, I'll simply drop a single 5770 on it and rack up hella lot of coin. A single 5770 will compute like 30 Core i7-2600's  Grin

care to elaborate?

lolcust, artforz, your thoughts about this claim?
I honestly have zero clue what he's talking about. But I have the slight feeling if it were true it'd be HUGE news in the cryptographic community...
148  Alternate cryptocurrencies / Altcoin Discussion / Re: Possible 51% Attack on fairbrix (fbx) on: October 03, 2011, 09:55:52 AM
Even if the code is not done yet, the ideas are better than bitcoin and any other chain out there. You just cannot see it because of you inherent hate towards any other chain that beats bitcoin.
Yes, and I have an idea for a chain that will be completely fair, immune to all known attacks, any possible unknown attack and even impossible unknown attacks! Mining it will also produce more power than it consumes. So not only will it revolutionize the global financial economy, it'll also fix the energy crisis, cure cancer and shit rainbows! And it'll be done Real Soon Now(tm).
149  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency on: October 03, 2011, 09:17:02 AM
Well until you can disprove it, it can be assumed to be true and the guy who attacked Fairbrix can actually be Artforz/lolcust until you have concrete evidence to disprove this.

In public he helps complete Fairbux to look like good competition but in private he attacks it with his botnet so that it does not compete with pump+dump tenebrix scheme. Simples !
A magic fairy told me bulanula is a sockpuppet of CH/RS.
Well until you can disprove it, it can be assumed to be true and the guy who claims to be bulanula can actually be CH until you have concrete evidence to disprove this.
150  Alternate cryptocurrencies / Altcoin Discussion / Re: Possible 51% Attack on fairbrix (fbx) on: October 03, 2011, 09:13:19 AM
Nice describing Tenebrix, Fairbrix and Solidcoin 2. Hopefully I can mine other stuff than Tenecrap because ATM Solidcoin 2 and Fairbrix is down due to attack by Artforz and his buddy lolcust ( maybe same person too ? ) which cannot understand "competition" when it comes to CPU mining etc.
I see, the SC shills are again out in force making libelous claims about their "competition".
Guess they have to distract everyone from "2.0 Public Beta Testnet this weekend" followed by a whole lot of nothing...
151  Bitcoin / Development & Technical Discussion / Re: Difficulty adjustment needs modifying on: October 03, 2011, 07:50:05 AM
Yep, all the "fucking with timestamps" are "only" worsening the result of 51% attacks.
The problem is this changes the economic incentives of miners, as "defecting" is suddenly a lot more profitable...

Short version of the simple version, cooperators are mining "as planned", defectors fork the chain and communicate to collectively build a alternate version with optimally adjusted timestamps, N is the fraction of "cooperating" hashrate:

Bitcoin as planned:
N = 1 cooperate, everyone gets 1.
N > 0.5 cooperate, cooperators get 1/N, defectors get 0.
N < 0.5 cooperate, cooperators get 0, defectors get 1/(1-N).
N = 0 cooperate, everyone gets 1.

Solidcoin/ixcoin/i0coin/... with *1.1 /4 limits (edit: in theory, as the real chains all also have the same off-by-1 in their retargeting):
N = 1 cooperate, everyone gets 1.
N > 0.5 cooperate, cooperators get 1/N, defectors get 0.
N < 0.5 cooperate, cooperators get 0, defectors get 3.6/(1-N).
N = 0 cooperate, everyone gets 3.6.

Bitcoin with off-by-1:
N = 1 cooperate, everyone gets 1.
N > 0.5 cooperate, cooperators get 1/N, defectors get 0.
N < 0.5 cooperate, cooperators get 0, defectors get near infinite (really (what difficulty should be)/(minimum difficulty)).
N = 0 cooperate, everyone gets near INF.

edit: forgot, all current *1.1 /4 chains *also* have the off-by-1, so it's really "near infinite" for "defectors get a majority" there, too...
152  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency on: October 03, 2011, 06:45:41 AM
That 2M @ 0.0001 buy order ... not me.
So, please dump enough coins... whoops, there's only 774K GG total in existence.
Aka "more completely baseless FUD from mr. egomaniac to keep propping up vaporcoin".
Or how did the "SC2.0 Public Beta Testnet this weekend" work out? Oh, right.
Oh, and as a thanks for this nice personal attack, I'll gladly donate my expertise and if required a few days on my personal 5970s and/or LX150 cluster to break your chain to hell and back.

Haha, the amateur has his feelings hurt. The order on btc-e is yours. And yes, donate everything to the "attack". You might want to get some help with the programming of it though. I don't think there is some source for you to copy for this kind of thing.
Everyone got this? CoinHunter officially invited the attack, so no pre-warning this time, and no crying "EVIL BLACKHAT TERRRRRIST!!!" after.
153  Bitcoin / Development & Technical Discussion / Re: Difficulty adjustment needs modifying on: October 03, 2011, 06:42:23 AM
Unless I'm seriously misunderstanding, no one is discussing asymmetric adjustments here..

You are.  This is exactly what is under discussion.
From the OP: “It would (as I said) be an up or down adjustment test, not just for downward adjustments.”

Maybe I'm misunderstanding what you mean by asymmetric?

EDIT: Regarding ArtForz's attack (the one you linked to), it was against against an off-by-one error in the implementation of bitcoin. That sort of thing is really orthogonal to the discussion here. Unless there is another attack he published that I'm not aware of?
That is the one he's referring to.
I've spent a little time finding related links:

ArtForz' last post about it (Forum time: September 13, 2011, 06:37:13 PM)
https://bitcointalk.org/index.php?topic=42417.msg523751#msg523751
saying that bitcoin doesn't have the fix included

I then went through the bitcoin git and read all the commits since 12/13 Sep:
https://github.com/bitcoin/bitcoin/commits/master

(AND a complete off topic comment on the last lot of commits:
LOL you let namecoin merged mining sneak in - did anyone realise that's what this is?
https://github.com/bitcoin/bitcoin/pull/476
Oh well, I guess it doesn't matter that they will be adding extra non-bitcoin data to the block-chain ...)

ArtForz' comment that there is a fix for the timewarp exploit:
https://bitcointalk.org/index.php?topic=42417.msg523714#msg523714

GG Git: ArtForz' NTP commit:
https://github.com/Lolcust/GeistGeld/commit/a25e1ce480f5bfbf7529bccd56df28b54c0eea77
basically trying to keep bitcoin's time accurate with the -ntp option
(on linux install ntpd as I always have Tongue)

But I can't find the change to the actual calculation ...
and I can't find anything like this link of Gavin's anywhere in GG or bitcoin:
https://bitcointalk.org/index.php?topic=42417.msg517020#msg517020

Nope, bitcoin still has the off-by-1, as for now it's deemed "too big to fail" and fixing it would mean a backwards-incompatible change to the blockchain.

The off-by-1 fix is completely orthogonal to the NTP stuff.
It's right here:
https://github.com/Lolcust/GeistGeld/commit/f9523f33ec22e26b7781f5a545fc74b4ecdc31a6#diff-3

Iirc my "why asymmetric diff adjustment is bad" was in a thread discussing SCs adjustment algo, and so far every asymmetric diff adjustment method I bothered to figure out a optimal strategy on has the same problem, a 51% attacker can create more blocks in the same nTime window than "he should be able to" while only doing the same # of hashes as the real chain over the same nTime window. And every time the factor gained happened to come out exactly as the maximum down adjustment over the maximum up adjustment for the same # of blocks.
Trivial example for how time-based has the same flaw, let's say daily retarget and /4 *4 limits
official chain hashes along at difficulty 1 for 2 days, so it has 2 difficulty-days and takes 2 days worth of nTime.
attackers chain has 0 blocks on day 1 (= diff retargets by /4), 8 times the normal blocks at diff 1/4 on day 2 (=diff retargets *4 and is back to 1 afterwards), so the attackers chain has a total of 1/4 * 8 = 2 difficulty-days, starts and ends with diff 1, also takes 2 days worth of nTime, but contains 4 times the # of blocks of the official chain.
154  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency on: October 03, 2011, 06:03:02 AM
Mostly because tenebrix is a bitch and a half to get working in the first place.   Took me an hour of looking at code, windows batch files, etc to see why it's dumping core or failing assertions before I got it running.  EC2 boxes don't have GUIs.

You've fixed the headless problem, so the major hurdle to running the miners remotely has been cleared.  It's easy enough to do, but as you pointed out with a grand total of 230 BTCs available to cash out (and only 30 of that above .0001BTC) it's definitely not worth the price of admission.

The two orders on GG/TBX at btc-e that look like 200 @ 0.0001 are actually artforz orders. So try and pump-n-dump down to that level if you want to start costing Artforz some btc. Smiley
That 2M @ 0.0001 buy order ... not me.
So, please dump enough coins... whoops, there's only 774K GG total in existence.
Aka "more completely baseless FUD from mr. egomaniac to keep propping up vaporcoin".
Or how did the "SC2.0 Public Beta Testnet this weekend" work out? Oh, right.
Oh, and as a thanks for this nice personal attack, I'll gladly donate my expertise and if required a few days on my personal 5970s and/or LX150 cluster to break your chain to hell and back.
155  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency on: October 03, 2011, 05:13:09 AM
cd src
make -f makefile.unix bitcoind
Duh.
156  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency on: October 02, 2011, 05:22:24 PM
At the current point, yeah. tbx seems to have about 1200kH/s on it, fbx looks like about 150.
So a potential attacker only needs something like 60 high end cpus or about 1000 really crappy ones to have a good chance at forking and overtaking the tbx chain, about 1/8 that for fbx.
157  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency on: October 01, 2011, 02:38:35 PM
10 difficulty means it's 10x harder to generate the current block than the block chain's first block.
No - the block chain's first block is created manually.
Yes difficulty is a direct multiplier - as you can see I even know how to convert the 4byte number to a difficulty ...
What I don't know is what 1 difficulty represents.
In 'proper bitcoin' 1 difficulty represents an expected statistical average of 2^32 hashes.
If it is a direct conversion (as would seem likely but I wasn't really thinking when I wrote that) then 0.04195601 would mean 1.8Ghashes
So my 4,368khashes seems rather low ...
Yep, diff 1 is 2**32 hashes as in bitcoin to avoid even further confusing things.
Minimum and initial tbx difficulty is/was difficulty 1/4096 (= 2**20 hashes).
but your hash# calc is somehow off by a factor of 10, diff 0.0419... * 2**32 = ~ 180M, not 1.8G hashes/block avg.
158  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency on: October 01, 2011, 10:24:27 AM
That's ... weird.
I'm pretty much seeing *zero* of those building tenebrix on debian... Are you sure you started with a clean tree?

I did a clean clone of the repo https://github.com/Lolcust/Tenebrix.git like 3h ago.
Well, here's what build output for me on sid amd64 looks like: http://pastie.org/2621383
On ubuntu natty amd64 ... same thing. clone repo, qmake, make, Huh, profit... errr... binary built!
So... not sure wth is going wrong on your system.

edit: just tried on natty i386 ... again same thing, builds fine.
159  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency on: October 01, 2011, 09:58:36 AM
Is the head on the git-hub repo really supposed to build under Linux?
I have corrected tens of things that just couldn't possibly compile, and I am still finding more and more of these.
head of what? Tenebrix, Tenebrix-daemon-exp or Tenebrix-miner?

Tenebrix

I got it built finally, but quite a few things are broken, probably due to a recent merge from Multicoin and the use of qmake instead of autoconf / automake.

  • All the moc_xxx.cpp files include files from src/thread, but this dir doesn't exist (files are in src/qt in fact, so making a symlink thread -> qt does the trick).
  • qmake doesn't generate the makefile with the right dynamic library linking directives.
    I had to add manually the following to LIB (in the below, WXLIBS contain the output of wx-config --libs)
    Quote
    -lcrypto $(WXLIBS) -ldb -ldb_cxx -lboost_system -lboost_thread -lboost_program_options -lboost_filesyst
  • I had to add manually the output of wx-config --cflags to CXXFLAGS.
  • ui.o contains symbols that conflict with bitcoingui.o
    rpc.o contains symbols that conflict with bitcoinrpc.o
    Only one of these implementations should make it to the makefile, but currently both are there which creates symbol conflicts.
    Actually, ui.cpp contains MFC code, so much for a unix build...
  • Add -DQT_GUI to DEFINES
  • Plus a few missing or conflicting symbols
    Patch there (check the raw one) : http://pastebin.com/zkwUh9Mb
    Don't apply the patch as is, this is just to point out things that break the build on Debian.
That's ... weird.
I'm pretty much seeing *zero* of those building tenebrix on debian... Are you sure you started with a clean tree?
160  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency on: October 01, 2011, 08:33:51 AM
Is the head on the git-hub repo really supposed to build under Linux?
I have corrected tens of things that just couldn't possibly compile, and I am still finding more and more of these.
head of what? Tenebrix, Tenebrix-daemon-exp or Tenebrix-miner?
Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!