Updated Fairbrix Client

[Wolf0]

NaN.

[markm]

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-

[markm]

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-

[wiggi]

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
rpcpassword=foobar
rpcuser=1
rpcport=8645
server=1

is needed in fbx.conf

Stable nodes:

Code:

addnode=54.245.186.179
addnode=198.154.60.61

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.

[Buffer Overflow]

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
rpcpassword=foobar
rpcuser=1
rpcport=8645
server=1

is needed in fbx.conf

Stable nodes:

Code:

addnode=54.245.186.179
addnode=198.154.60.61

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.

[wiggi]

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

[wiggi]

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:

{
"total balance change" : 580.00000000
}

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