Bitcoin Forum
November 20, 2017, 09:44:20 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 [865] 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 ... 1299 »
  Print  
Author Topic: [ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000  (Read 2112024 times)
burstcoin
Sr. Member
****
Offline Offline

Activity: 280


View Profile
January 26, 2015, 03:29:53 AM
 #17281

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.


BURST-QHCJ-9HB5-PTGC-5Q8J9
1511171060
Hero Member
*
Offline Offline

Posts: 1511171060

View Profile Personal Message (Offline)

Ignore
1511171060
Reply with quote  #2

1511171060
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511171060
Hero Member
*
Offline Offline

Posts: 1511171060

View Profile Personal Message (Offline)

Ignore
1511171060
Reply with quote  #2

1511171060
Report to moderator
crazyearner
Legendary
*
Offline Offline

Activity: 1722



View Profile
January 26, 2015, 03:38:16 AM
 #17282

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
Sr. Member
****
Offline Offline

Activity: 287


View Profile
January 26, 2015, 04:11:06 AM
 #17283

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
Jr. Member
*
Offline Offline

Activity: 38


View Profile
January 26, 2015, 05:34:07 AM
 #17284

Guys, I request help or advice.  Undecided

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  Huh). 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
Full Member
***
Offline Offline

Activity: 137


AT - Automated Transactions - CIYAM Developer


View Profile
January 26, 2015, 05:46:36 AM
 #17285

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

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.

1ELCU3hahFLMPPqsoHS2Mg2Rqjya6VXjAW
bensam123
Sr. Member
****
Offline Offline

Activity: 424


View Profile
January 26, 2015, 05:54:10 AM
 #17286

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
Sr. Member
****
Offline Offline

Activity: 336


View Profile
January 26, 2015, 06:23:26 AM
 #17287

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
Sr. Member
****
Offline Offline

Activity: 424


View Profile
January 26, 2015, 06:26:49 AM
 #17288

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

Activity: 336


View Profile
January 26, 2015, 06:30:20 AM
 #17289

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
Newbie
*
Offline Offline

Activity: 2

Hello! Goodbye! :P


View Profile
January 26, 2015, 06:33:24 AM
 #17290

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
Member
**
Offline Offline

Activity: 94


View Profile
January 26, 2015, 06:49:03 AM
 #17291

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

vbcs
Full Member
***
Offline Offline

Activity: 137


AT - Automated Transactions - CIYAM Developer


View Profile
January 26, 2015, 06:49:47 AM
 #17292

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

1ELCU3hahFLMPPqsoHS2Mg2Rqjya6VXjAW
burstcoin
Sr. Member
****
Offline Offline

Activity: 280


View Profile
January 26, 2015, 07:02:14 AM
 #17293

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.

BURST-QHCJ-9HB5-PTGC-5Q8J9
mirny
Legendary
*
Offline Offline

Activity: 969



View Profile
January 26, 2015, 08:05:41 AM
 #17294

@poloniex chat

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

Blago
Sr. Member
****
Offline Offline

Activity: 416



View Profile
January 26, 2015, 08:07:55 AM
 #17295


Relax, I’m russian!...
BURST-B2LU-SGCZ-NYVS-HZEPK
mmmaybe
Sr. Member
****
Offline Offline

Activity: 462



View Profile WWW
January 26, 2015, 08:21:38 AM
 #17296

Mod in Polo's trollbox:

Quote
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
Legendary
*
Offline Offline

Activity: 969



View Profile
January 26, 2015, 08:50:34 AM
 #17297

6BTC dump@polo

mmmaybe
Sr. Member
****
Offline Offline

Activity: 462



View Profile WWW
January 26, 2015, 09:03:56 AM
 #17298







Not really good but better than 1.2.0...?


Updated db folder on mega:
https://mega.co.nz/#!J8hyHDjI!lx0o_Ei1p4a3QIgeZ-s8z8hkG-BoUKFx11FvXiNc1GI


osvald
Newbie
*
Offline Offline

Activity: 15


View Profile
January 26, 2015, 09:13:48 AM
 #17299

Hello all!
Now pool cryptomining.farm work incorrect.
He find block 60022.
Polls burst.ga and other find block 60025.
pinballdude
Sr. Member
****
Offline Offline

Activity: 287


View Profile
January 26, 2015, 09:53:12 AM
 #17300

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.

things worked fine for my wallets too, but at 59800 something broke, and i went on a bad fork, i tried to restart many many times, and waited for hours. my wallets were stuck on the shorter chain, and there were these notifications of exceptions as shown previously. i didn't have the experience that my 1.2.1s went to the longer chain by themselves in any kind of hurry.

after having downloaded the right fork things worked for a while again, but right now, my wallets seem to post an error every 15 seconds, along the lines of :
Quote
2015-01-26 10:46:15 INFO: tx with id -1019205954960601549 found
2015-01-26 10:46:15 INFO: get timestamp for tx with id -1019205954960601549 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.run(BlockchainProcessorImpl.java:171)
        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)

i am working on block 60018 on all 3 wallets (all 3 showing above info message, with various intervals from seconds to minutes)
basetarget 2027904 height 60018 indicates i am on the right chain right now i would assume, but i fear we might have forked again around 60017 +/- as the last fork started with a similar error beginning to show on the bad fork.

Must admit that i *am* running a version i compiled myself, so i might have done something wrong in the build, in which case i should be the only one seeing above error. When i'm back from work tonight, i'll try to use the original 1.2.1 and see if that makes a difference.
Pages: « 1 ... 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 [865] 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 ... 1299 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!