Title: Updated Fairbrix Client Post by: Wolf0 on July 18, 2013, 02:55:00 AM NaN.
Title: Re: Updated Fairbrix Client Post by: markm on July 18, 2013, 03:03:05 AM Ah well, maybe its time as a small miner's coin for CPU mining is ending then, since already i was starting to think maybe someone uis using a GPU on it, or at least quite a few CPUs, and with newer code, that includes a daemon, how likely is it that all the CPU miners will be able to upgrade to the new code without some GPU bully or bullies jumping in to drive the CPU miners away?
It'll be nice not to have to run stupid GUI crap across continents from server to the desktop graphics-server though. Have you checked the ports, IRC channels, and especially things like the addresses-version and magic handshake bytes aren't just what was inherited from litecoin? That is, did the guy actually do the conversion to faribrix or merely clone litecoin itending to then never actually finish the job? -MarkM- Title: Re: Updated Fairbrix Client Post by: markm on July 18, 2013, 03:26:27 AM I checked the handshake bytes and the genesis hash they looked ok, the ports matched too so yeah it looks okay so far, it is getting the blockchain from one of the old nodes now...
-MarkM- Title: Re: Updated Fairbrix Client Post by: wiggi on July 24, 2013, 07:13:25 PM I found a Fairbrix client based off of 0.6.3 Very old version actually. ;)New one is this: https://github.com/wiggi/fairbrix-0.8-coincontrol-test Nothing really interesting, mostly a 1:1 conversion of the current Ltc development version with coin control. Notes: v0.8 complains about using just "1" for both username and password, so something like this Code: # bitcoin 0.8 requires rpcpassword != rpcuser Stable nodes: Code: addnode=54.245.186.179 If you allow incoming connections (i.e. open port 8591) don't use "maxconnections=...". It's buggy and prevents peers from dl'ing the blockchain. I did some obvious tests: dl/reindex blockchain, mine with cpuminer and reaper, send coins from and to old client versions, import v03 and v06 wallet, send from encrypted wallet etc. No problems so far. Title: Re: Updated Fairbrix Client Post by: Buffer Overflow on July 28, 2013, 08:17:43 AM I found a Fairbrix client based off of 0.6.3 Very old version actually. ;)New one is this: https://github.com/wiggi/fairbrix-0.8-coincontrol-test Nothing really interesting, mostly a 1:1 conversion of the current Ltc development version with coin control. Notes: v0.8 complains about using just "1" for both username and password, so something like this Code: # bitcoin 0.8 requires rpcpassword != rpcuser Stable nodes: Code: addnode=54.245.186.179 If you allow incoming connections (i.e. open port 8591) don't use "maxconnections=...". It's buggy and prevents peers from dl'ing the blockchain. I did some obvious tests: dl/reindex blockchain, mine with cpuminer and reaper, send coins from and to old client versions, import v03 and v06 wallet, send from encrypted wallet etc. No problems so far. I guess it would be trivial to port this over to Tenebrix. Title: Re: Updated Fairbrix Client Post by: wiggi on July 28, 2013, 03:04:21 PM I guess it would be trivial to port this over to Tenebrix. I haven't tried yet but would be surprised if it's not trivial: - PUBKEY_ADDRESS in base58.h (Ltc: 48, Tbx: 127, Fbx: 95) - checkpoints.cpp - hashGenesisBlock, nSubsidy, nTargetTimespan, nTargetSpacing and pchMessageStart (magic network number, Ltc: 0xdbb6c0fb, Tbx: 0xd9b4daf9, Fbx: 0xdbf9dbf9) in main.cpp - the Genesis block in main.cpp - GetDefaultPort in protocol.h - config file and data folder name in util.cpp Name of the executable in bitcoin.pro Name of the ".pid" file in util.cpp This should be enough for basic function, unless some blocks fail the security tests (like block 3075 in Fairbrix) and need an exception. - pnSeed in net.cpp Perhaps we should bring back IRC node discovery, it seems reliable (once again). Title: Re: Updated Fairbrix Client Post by: wiggi on August 17, 2013, 08:17:57 PM Source for v0.8.3.7: https://github.com/wiggi/fairbrix-0.8-coincontrol
There are 2 new debug window functions, svscanblocks and svdebugblock, to measure total in- and outflow for addresses that start with a given vanitygen string. testing: block 168266, 70 Fbx sent to fXgaga4p31vZvizUP6Y6coDAe6su8JMiph block 168271, 80 Fbx sent to fXgagaVmUAcfpptmEHhH64v5j6fbuxvXwd, change from 1st tx is one of the inputs block 168279, 200 Fbx sent to fXgaga4p31vZvizUP6Y6coDAe6su8JMiph block 168282, 300 Fbx sent to fXgagaVmUAcfpptmEHhH64v5j6fbuxvXwd block 168344, 115 Fbx sent to some address, the 70 Fbx from 1st tx is one of the inputs svscanblocks 168265 168345 Xgaga Code: { It backtraces tx's like the Bitcoin v0.7.2 Coin Control traceback function that was kicked out in 0.8, but only 1 deep to find the correct input(s), and without using the database. (txindex=1 is required) Why? Currently nodes can't access real world facts in any reliable way, thats why "Bitcoin mining difficulty contract" is used as example in https://bitcointalk.org/index.php?topic=260898.msg2926734#msg2926734 I want a PoS based voting system for this... |