[ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000

[mmmaybe]

Mod in Polo's trollbox:

whatever: OldManKidd, are your BURST wallet updated?
whatever: OldManKidd, http://is.gd/6xoPV7
OldManKidd: whatever, it has been reported already... withdrawal and deposits are down at this time
whatever: OldManKidd, update wallet and DB from http://is.gd/6xoPV7
whatever: OldManKidd, you are on a fork
OldManKidd: whatever, we are aware of the update. it should be done shortly

[1713582640]

1713582640

[1713582640]

1713582640

[1713582640]

1713582640

[1713582640]

1713582640

[1713582640]

1713582640

[crazyearner]

Hoping on board over at pool.burstcoining going to see how this works out compared to farm mining maybe work better on payments as ran on their for the last month and seems payments not going so smooth well payments are on time and like clock work but think I could earn better as it seems with me current TBs etc meant to be generating at least 4 to 5 times more unless that calculator is way off on the calculator website

[crazyearner]

Generated 20684.85644 BURST for around 28 days worth of mining is that even right for having around 3.8TB plotted and mining away on one machine ?

[burstcoin]

Hrm.... the network is somehow fucked or forked or something....
Half the pools I go to are stuck on block 793 and not finding anymore blocks, while other pools I go to are working on block 802 and seem to be finding blocks fine....

all my 3 wallets on 3 machines, 1.2.1 are having problems with a block, however it seems like they are only printing out an exception and then continuing to work. the printout :

Code:

2015-01-25 19:43:08 INFO: get timestamp for tx with id -4762078490203704075 found
nxt.at.AT_Exception: Calculated md5 and recieved md5 are not matching
        at nxt.at.AT_Controller.validateATs(AT_Controller.java:404)
        at nxt.BlockchainProcessorImpl.accept(BlockchainProcessorImpl.java:682)
        at nxt.BlockchainProcessorImpl.pushBlock(BlockchainProcessorImpl.java:647)
        at nxt.BlockchainProcessorImpl.access$400(BlockchainProcessorImpl.java:51)
        at nxt.BlockchainProcessorImpl$1.processFork(BlockchainProcessorImpl.java:323)
        at nxt.BlockchainProcessorImpl$1.run(BlockchainProcessorImpl.java:191)
        at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
2015-01-25 19:43:09 INFO: tx with id -4762078490203704075 found
2015-01-25 19:43:09 INFO: get timestamp for tx with id -4762078490203704075 found

it seems the problem started somewhere between block 59761 and 59771

all 3 wallets on all 3 different machines give the same error. i would assume something got in via the network, that the software stumbles upon.

That error was caused from a miner that had outdated version. If you restart the wallets you probably will be good

but do you mean there are somebody who is mining in solo with old wallet?
and this cause the fork?

This is very risky

i hope dev can implement a petch to avoid this in futures...

The "INFO: tx with id" messages are debugging info that didn't get removed.

As for the exception, a simpler message would have probably been better than dumping the stack trace, but it's just rejecting a block(most likely created by 1.2.0 in this case) it received as invalid.

I'm a bit surprised the 1.2.0 chain is still running since it tended to get stuck under the current situation(block generation wouldn't pass verification so it would loop failing to create a block), not continue on wrong.

The 1.2.1 chain is longer and has a higher cumulative difficulty, so 1.2.1 clients should all eventually end up there.

[crazyearner]

Seem to be having problems setting rewardassignment

setting with passphrase and also using address to set to pool however shows transaction ID but no confirmations been like this almost 3 hours now reloaded wallet and transaction not their and sent a number of times now and not worked.

Transaction ID 10369527127830035063   /   26/01/2015 03:23:42   Reward Recipient Assignment      0   1   BURST-BANK-DT2R-BM8G-FYFRH
Sent again and still nothing happening.

Any idea what is going on here?

[pinballdude]

Hrm.... the network is somehow fucked or forked or something....
Half the pools I go to are stuck on block 793 and not finding anymore blocks, while other pools I go to are working on block 802 and seem to be finding blocks fine....

all my 3 wallets on 3 machines, 1.2.1 are having problems with a block, however it seems like they are only printing out an exception and then continuing to work. the printout :

Code:

2015-01-25 19:43:08 INFO: get timestamp for tx with id -4762078490203704075 found
nxt.at.AT_Exception: Calculated md5 and recieved md5 are not matching
        at nxt.at.AT_Controller.validateATs(AT_Controller.java:404)
        at nxt.BlockchainProcessorImpl.accept(BlockchainProcessorImpl.java:682)
        at nxt.BlockchainProcessorImpl.pushBlock(BlockchainProcessorImpl.java:647)
        at nxt.BlockchainProcessorImpl.access$400(BlockchainProcessorImpl.java:51)
        at nxt.BlockchainProcessorImpl$1.processFork(BlockchainProcessorImpl.java:323)
        at nxt.BlockchainProcessorImpl$1.run(BlockchainProcessorImpl.java:191)
        at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
2015-01-25 19:43:09 INFO: tx with id -4762078490203704075 found
2015-01-25 19:43:09 INFO: get timestamp for tx with id -4762078490203704075 found

it seems the problem started somewhere between block 59761 and 59771

all 3 wallets on all 3 different machines give the same error. i would assume something got in via the network, that the software stumbles upon.

That error was caused from a miner that had outdated version. If you restart the wallets you probably will be good

but do you mean there are somebody who is mining in solo with old wallet?
and this cause the fork?

This is very risky

i hope dev can implement a petch to avoid this in futures...

The "INFO: tx with id" messages are debugging info that didn't get removed.

As for the exception, a simpler message would have probably been better than dumping the stack trace, but it's just rejecting a block(most likely created by 1.2.0 in this case) it received as invalid.

I'm a bit surprised the 1.2.0 chain is still running since it tended to get stuck under the current situation(block generation wouldn't pass verification so it would loop failing to create a block), not continue on wrong.

The 1.2.1 chain is longer and has a higher cumulative difficulty, so 1.2.1 clients should all eventually end up there.

I downloaded the chain linked in mega and after replacing my burst_db with that, my 3 wallets jumped onto the longer chain.

with the downloaded chain i don't get the error message quoted above, so i'd suspect the shorter chain contains a bad transaction or bad block, and the longer chain does not contain that transaction and that block. I have the shorter chain as a backup if anyone might be interested in looking at what transaction or block it was, and where it came from.

anyway now on 59942 at basetarget 2201127 and everything seems fine here with my 50TB solomining operation.

[fragamemnon]

Guys, I request help or advice. 

My account is stuck on 0 burst, and I've used both faucets once already. I spent the coins on swapping pools around.
I'm currently stuck on burstcoin.io which, apparently, isn't up-to-date anymore, and can't shift pools around.

Funny thing is, according to the block explorer my account should have 225 BURST (with only one incoming transaction of 76  ). I've already deleted and re-downloaded the blockchain once, but my balance still shows as zero. Wallet is v1.2.1

To be honest, I am experiencing such a fork for the first time, and am lost on what to do.

Thanks for your time!

[vbcs]

I'm at 59830...

I don't see the AT Lotteries in the .html. There is no lottery to pick. Do I have to put an account id of the lottery-wallet?

Maybe you have to redownload the html, as the ones i posted at the beginning were using testnet port instead of mainnet ports.
Here is the link to the post with the links:https://bitcointalk.org/index.php?topic=731923.msg10254497#msg10254497

That worked! Thanks alot vbcs...! Can't believe this just works fine. Can't wait for more implementations of AT.


Would be nice though to put a dot into the "Buy Ticket"-Price of 201500000000.

Yes you are correct, amounts are in NQT, i could probably add a dot or comma there. But don't worry if you send an amount greater than the ticket cost the lottery will refund you the difference and still gives you a ticket. If you send to the lottery less than the ticket cost and the amount you sent is also greater than the processing fees of 15 burst coins still you will get a refund ( but no ticket ). Any amounts below 15 burst coins are ignored.

[bensam123]

Thanks for the DB download.

I've been mining coins for quite a long time and have seen some pretty shitty forks, which usually result in the developers having to release a client that actually kills the bad forks. I don't understand why developers and people say 'just let it sort itself out', meanwhile countless users of the coin risk losing fuck tons and mining time by continuing to use essentially a broken coin?

Developers should be on top of this shit. They should immediately release a client that kills the old forks if it doesn't clear itself up in 3-6 hours. We've had this forking issues since the 1.2.1 release if I'm not mistaken, which happened on... friday? From what I understand, it's not hard to kill old forks either with a new client.

Forks are like a slow poison that work their way through a coin and really mess things up. If there is an exchange as big as Poloniex still on the wrong fork, there is definitely something wrong, regardless of how good the coin is. Tons of people exchange with poloniex and if they see their transactions going through, it'll perpetuate the circle.

There is essentially six pages of posts here trying to find ways to fix the fork, work on the fork, and eventually culminated in a 'community fix', which is transplanting someone elses DB to your computer, which you should never need to do if everything is working alright. Is releasing a new version of the wallet really 'that' bad compared to having people possibly sit on a fork for god knows how long?

I know, I know, forks happen, but pro-active development could really limit their impact.

[duncan_idaho]

26/01/2015 03:35:07      289.5111251 + 1   BURST-VZFK-MKJV-6BRZ-668SV   /
25/01/2015 18:23:27      173.20694859 + 1   BURST-VZFK-MKJV-6BRZ-668SV   /

Something is wrong. I have no confirmation for this transactions.
Also all my miners and bursts daemons crashed.
1.2.1 is buggy?

[bensam123]

My miners are getting a Visual Basic R6010 error from time to time right now as well (which crashes the miner).

[duncan_idaho]

also have errors in java console

INFO: tx id with id 0 found
Transaction to <long number> found amount 0
get timestamp for tx id - <big number> found

[Deystorm]

I need some help getting my rig mining.
I have claimed some BURST on different faucets, but my address is still "not found" at https://mining.burstcoin.io/

Can someone send me some burstcoins, so that I can get started with mining...

Or am I wrong with this interpretation???
Thanks!

[b3da]

My mining statistics is on right fork now
It's working again! 
calculator is going crazy, diff so low

[vbcs]

also have errors in java console

INFO: tx id with id 0 found
Transaction to <long number> found amount 0
get timestamp for tx id - <big number> found

This is not an error, these messages are debug messages for the AT, they will be removed in next release

[burstcoin]

Thanks for the DB download.

I've been mining coins for quite a long time and have seen some pretty shitty forks, which usually result in the developers having to release a client that actually kills the bad forks. I don't understand why developers and people say 'just let it sort itself out', meanwhile countless users of the coin risk losing fuck tons and mining time by continuing to use essentially a broken coin?

Developers should be on top of this shit. They should immediately release a client that kills the old forks if it doesn't clear itself up in 3-6 hours. We've had this forking issues since the 1.2.1 release if I'm not mistaken, which happened on... friday? From what I understand, it's not hard to kill old forks either with a new client.

Forks are like a slow poison that work their way through a coin and really mess things up. If there is an exchange as big as Poloniex still on the wrong fork, there is definitely something wrong, regardless of how good the coin is. Tons of people exchange with poloniex and if they see their transactions going through, it'll perpetuate the circle.

There is essentially six pages of posts here trying to find ways to fix the fork, work on the fork, and eventually culminated in a 'community fix', which is transplanting someone elses DB to your computer, which you should never need to do if everything is working alright. Is releasing a new version of the wallet really 'that' bad compared to having people possibly sit on a fork for god knows how long?

I know, I know, forks happen, but pro-active development could really limit their impact.

1.2.1 was the fix. It was released 6 days ago.

1.2.1 won't sync to the 1.2.0 fork, and 1.2.0 won't sync to the 1.2.1 fork, however 1.2.1 can get stuck for a little while at the fork point if it can't find the 1.2.1 fork right away due to all the 1.2.0 spam.

The only problem in play right now is the number of 1.2.0 clients around and amount of hashrate still on 1.2.0 keeping that fork running and widely available. Sure an update could be released to blacklist the 1.2.0 fork, but the 1.2.0 fork fails validation in 1.2.1 anyway, so it wouldn't change anything. The only fix is having a larger percent of the network on 1.2.1, and time and publicity are the only things that help that out.

Personally I've yet to see any significant issues getting onto the correct fork when using 1.2.1, although it depends a lot on which/how many peers you are connected to. I had 4 instances of 1.2.1 running from separate locations from before the fork, and they all followed onto the correct one without issue. I've also synced up to date in 1.2.1 from old blockchain copies I had, and from fully synced 1.2.0 from the bad fork, and nothing took more than a few minutes to figure out which the correct chain was.

[mirny]

@poloniex chat

mirnyyy: Is BURST on the good chain?
Coinsss: mirnyyy, ya i think so
Chickenliver: mirnyyy, yes

[Blago]

[mmmaybe]

Mod in Polo's trollbox:

whatever: OldManKidd, are your BURST wallet updated?
whatever: OldManKidd, http://is.gd/6xoPV7
OldManKidd: whatever, it has been reported already... withdrawal and deposits are down at this time
whatever: OldManKidd, update wallet and DB from http://is.gd/6xoPV7
whatever: OldManKidd, you are on a fork
OldManKidd: whatever, we are aware of the update. it should be done shortly

I've got my Polo deposit but no answer on the ticket yet. I'll try a withdraw.

***EDIT: Both deposits and withdraws from poloniex.com is working again

[mirny]

6BTC dump@polo