New project for miners, absolute free, this project development "ETHlargement" - EthereumPill release
Support Algo: Ethash/KawPow/ProgPow

Download: https://ethereumpill.info/ProjectEthereumPill.zip

Virustotal: https://www.virustotal.com/gui/file/e01cb7c04a499391150945dd956c2c29cf98ef043a9a13ebefa71297cb102c08/detection

Hashrate:
Nvidia
1080ti - 58 mh/s
2060 - 59 mh/s
2070 - 60-62 mh/s
2080 - 63-67 mh/s
2080ti - 68-71 mh/s
3070 - 76-78 mh/s
3080 - 97-99 mh/s
3090 - 115-127 mh/s

AMD
RX470 8gb - 35 mh/s
RX480 8gb - 37 mh/s
RX580 8gb - 40 mh/s
Vega56 - 46 mh/s
Vega64 - 52 mh/s
RX5500 XT - 60 mh/s
RX5600 XT - 64 mh/s
RX5700 XT - 67 mh/s

P.S.: the project is being drowned by competitors, don't trust anyone, check the information yourself

Latest Blockchain Bootstrap files as of today...

Delete every file except peers.dat, bullion.conf, wallet.dat and folder Backup

https://mega.nz/file/IEdQzRzK#tOAJVjzOQ6ApL7o7Pp6TM8W1aQWQUJ8crVorvFz5wYA

nodes list

79.167.32.123

nodes list

79.167.32.123

nodes list

79.167.32.123
68.224.77.122

nodes list

141.237.178.207
68.224.77.122

nodes list

79.167.137.245

looks like my vault (v3 alpha4) is also on a fork
i can confirm there is a fork with many clients on it
i'll try to resync my vault from an older bootstrap file i have...

nodes list

158.58.134.253
141.237.52.229

the new version (v 3 alpha 4) works and staking like a charm for me... nice work guys
keep up the efforts and many congrats to you all for another quick response/solution

as of yesterday my vault (v3.0) can't sync, stuck at block 2359262 and this error shows on debug.log

2018-04-13 07:01:54 receive version message: /Vault:2.4.4/: version 60010, blocks=2360397, us=141.237.52.229:51092, peer=1
2018-04-13 07:01:54 Added time data, samples 2, offset +0 (+0 minutes)
2018-04-13 07:01:55 ERROR: CheckBlock() : hashMerkleRoot mismatch
2018-04-13 07:01:55 ERROR: ProcessNewBlock : CheckBlock FAILED
2018-04-13 07:01:55 Misbehaving: node.alex4j.cryptobullion.io (0 -> 100) BAN THRESHOLD EXCEEDED
2018-04-13 07:01:57 receive version message: /Vault:2.4.4/: version 60010, blocks=2360397, us=141.237.52.229:51094, peer=2
2018-04-13 07:01:58 ERROR: CheckBlock() : hashMerkleRoot mismatch
2018-04-13 07:01:58 ERROR: ProcessNewBlock : CheckBlock FAILED
2018-04-13 07:01:58 Misbehaving: node.alex4j.cryptobullion.io (0 -> 100) BAN THRESHOLD EXCEEDED
2018-04-13 07:01:59 receive version message: /Vault:2.4.4/: version 60010, blocks=2360397, us=141.237.52.229:51095, peer=3
2018-04-13 07:02:00 ERROR: CheckBlock() : hashMerkleRoot mismatch
2018-04-13 07:02:00 ERROR: ProcessNewBlock : CheckBlock FAILED
2018-04-13 07:02:00 Misbehaving: node.alex4j.cryptobullion.io (0 -> 100) BAN THRESHOLD EXCEEDED
2018-04-13 07:02:02 receive version message: /Vault:2.4.4/: version 60010, blocks=2360397, us=141.237.52.229:51097, peer=4
2018-04-13 07:02:03 ERROR: CheckBlock() : hashMerkleRoot mismatch
2018-04-13 07:02:03 ERROR: ProcessNewBlock : CheckBlock FAILED
2018-04-13 07:02:03 Misbehaving: node.alex4j.cryptobullion.io (0 -> 100) BAN THRESHOLD EXCEEDED

any help from dev team ?

nodes list

141.237.37.184

nodes list

93.190.19.162
68.224.77.122
5.20.224.107
141.237.37.184

nodes list

109.235.186.158
213.230.79.145
141.237.37.184

synchronizing from scratch without bootstrap stuck at block #2256008 Sat Jan 20 03:06:01 2018 (win 7 x64 - tried 2 times)

debug.log

2018-02-26 06:36:01 ERROR: GetTransaction : Deserialize or I/O error - non-canonical ReadCompactSize()
2018-02-26 06:36:01 ERROR: CheckProofOfStake() : INFO: read txPrev failed, aa2f8c400739d2cc6576bda8b19088f099bda90a05789a393dd428dbafaa2286
2018-02-26 06:36:01 WARNING: ProcessBlock(): check proof-of-stake failed for block 4bf4fd27021a7130e6397f34b04d051c60cf6b39694f52dfc891b2ffa5c1dec7
2018-02-26 06:36:01 ERROR: ProcessNewBlock : AcceptBlock FAILED

nodes list

109.235.186.156
141.237.37.184

What about a time cycle - sharing of masternode role ?

We have a fixed number of 125  MN operating simultaneously.
Masternodes begin to operate and they take their MN ID and fill the queue order.
As the number of MNs is > 125 then cycling begins and MN ID #1 forfeit the role and goes to last position of the queue and MN ID #126
takes MN ID #125 and begin to participate (MN ID #127 takes pos. #126 and so on).
The cycling time can be let's say 6 to 72 hours so any of the MN candidates can estimate the exact time is needed
for taking the role (MN ID #128 -> 3 positions X 6 hours = 18 hours to take the role and 6 hours X 125 = 750 hours to forfeit it... and so on)
(*the cycling time can be fixed or variable -based on the MN candidates number-)

I think this approach has many benefits against ordinary established MN implementations.

I always believe that a master node must not be a privilege but a supporting=participation role with additional reward.

just my 2 cents...  

@dev team

I have 2 questions

1) Let's say someone have 4000 bullions in one wallet but separated in two addresses (2k - 2k).
    This wallet considered as one or two masternode(s) ?

2) How the network recognizes the masternode(ID), by Client IP Address, by wallet address or something else ?
    I ask this cause i think many of the clients doesn't have static IP addresses and they must take actions to be prepared
    for participate in masternode queue.

many congrats for your efforts dev team, keep up...

nodes list

68.108.2.84
141.237.37.184

very exciting news, congrats to lead community members...
coinbook will be only for us citizens or not ?