Is anyone else bothered by the fact that this entire community does almost all of its communication VIA this 1 Thread instead of in a Full forum.
A: Information is Hard to find
B: 15 different conversations Burying Newcomer questions
C: Important information is burryed
Can we start using a forum instead of 1 thread?
Im registered at Bursttalk forums, Its sad how long questions sit unanswered in the support threads & how little activity is seen there but instead i have to look through 900+ pages of thread to find information I previously read and now need!
Is there a good reason we refuse to be like every other crypto coin and develop our own community in our own forum?
Topic: [ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000 - page 447. (Read 2170648 times)
January 27, 2015, 07:19:54 PM
January 27, 2015, 06:55:18 PM
(edit)
running the 1.2.1 precompiled jar gives me other results than running my compiled version of 1.2.1, using my fork at github, which *should*'ve been updated with the 1.2.1 on the burst github.
I will compare sources and trace back and see what's the cause, either i merged in something in a bad way, or i didn't pull stuff out correctly, or the compile process itself was wrong somehow, or perhaps the jar in the 1.2.1 archive has not been built with the exact 1.2.1 sources on github. Will go hunt for answes and be back once i know what i did wrong. Until further notice, you can assume i made an error somewhere.
my fork stumbles upon block 60414, while the burst.jar in the 1.2.1 distro has no issues with that block.
sorry for all the noise... just kinda confused, never had this kind of problem before.
Have you tried compiling the source code of the original 1.2.1 release burstdev uploaded here and compare the resulted jar with the one included in the release??running the 1.2.1 precompiled jar gives me other results than running my compiled version of 1.2.1, using my fork at github, which *should*'ve been updated with the 1.2.1 on the burst github.
I will compare sources and trace back and see what's the cause, either i merged in something in a bad way, or i didn't pull stuff out correctly, or the compile process itself was wrong somehow, or perhaps the jar in the 1.2.1 archive has not been built with the exact 1.2.1 sources on github. Will go hunt for answes and be back once i know what i did wrong. Until further notice, you can assume i made an error somewhere.
my fork stumbles upon block 60414, while the burst.jar in the 1.2.1 distro has no issues with that block.
sorry for all the noise... just kinda confused, never had this kind of problem before.
The jar burstcoin put up is as far as i can tell excatly the same jar that i can produce with the sources put up to github. burstcoin have done nothing wrong whatsoever.
My problem was in my windows compile batch file, i seem to have forgotten to add paths to all source, so for a few files, i was linking older AT stuff with newer AT stuff, and the mix didn't quite work well in all situations as one would expect. the windows javac does not understand /nxt/*/*.java - so i had written all the subdirs under /nxt one by one, but had missed out on the new AT directory so those classes was linked up from what i suppose was slightly older versions in my classes directory.
I am building and testing now, and it seems like i am down to all classes in the jar file being byte for byte the same, except the ones where i have actually made changes, and the changes match up. And, of course, my wallets work once again.
January 27, 2015, 06:38:00 PM
(edit)
running the 1.2.1 precompiled jar gives me other results than running my compiled version of 1.2.1, using my fork at github, which *should*'ve been updated with the 1.2.1 on the burst github.
I will compare sources and trace back and see what's the cause, either i merged in something in a bad way, or i didn't pull stuff out correctly, or the compile process itself was wrong somehow, or perhaps the jar in the 1.2.1 archive has not been built with the exact 1.2.1 sources on github. Will go hunt for answes and be back once i know what i did wrong. Until further notice, you can assume i made an error somewhere.
my fork stumbles upon block 60414, while the burst.jar in the 1.2.1 distro has no issues with that block.
sorry for all the noise... just kinda confused, never had this kind of problem before.
running the 1.2.1 precompiled jar gives me other results than running my compiled version of 1.2.1, using my fork at github, which *should*'ve been updated with the 1.2.1 on the burst github.
I will compare sources and trace back and see what's the cause, either i merged in something in a bad way, or i didn't pull stuff out correctly, or the compile process itself was wrong somehow, or perhaps the jar in the 1.2.1 archive has not been built with the exact 1.2.1 sources on github. Will go hunt for answes and be back once i know what i did wrong. Until further notice, you can assume i made an error somewhere.
my fork stumbles upon block 60414, while the burst.jar in the 1.2.1 distro has no issues with that block.
sorry for all the noise... just kinda confused, never had this kind of problem before.
Have you tried compiling the source code of the original 1.2.1 release burstdev uploaded here and compare the resulted jar with the one included in the release??
January 27, 2015, 05:10:31 PM
Beta pool at pool.burstcoining.com:8124 is back up. Looks like the wallet was upset due to that v1.2.0 fork so I cleaned out unconfirmed transactions and rescanned the blockchain.
Nice to see your back up and running you should become active in Burst irc chat so that people can keep in contact with you if something happens and can update memebers.
January 27, 2015, 03:22:31 PM
stuck again, this time at 60413 which is my latest block , and it matches exactly the one at the block explorer that is current - however, i get no more blocks than that, and that's on all 3 wallets again.
If i am alone having this problem, i'll revert to the pre-built 1.2.1 to see if that is better. all 3 wallets are showing errors like this, and it seems that these errors always show up when my chain stops being updated :
i will now try to revert to the precompiled burst.jar on one of the pc's and see if that fixes the problems. if it is, it's just me having broken my burst fork. i suspect not though, but who knows, perhaps i merged in 1.2.1 in a bad way, missing something important. Anyone else stuck at 60413?, and what wallet version are you using?
sorry for all the noise... just kinda confused, never had this kind of problem before.
If i am alone having this problem, i'll revert to the pre-built 1.2.1 to see if that is better. all 3 wallets are showing errors like this, and it seems that these errors always show up when my chain stops being updated :
Code:
2015-01-27 20:04:14 INFO: tx with id 1488316772753571631 found
2015-01-27 20:04:14 INFO: get timestamp for tx with id 1488316772753571631 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)
2015-01-27 20:04:58 INFO: tx with id 1488316772753571631 found
2015-01-27 20:04:58 INFO: get timestamp for tx with id 1488316772753571631 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)
2015-01-27 20:05:21 INFO: tx with id 1488316772753571631 found
2015-01-27 20:05:21 INFO: get timestamp for tx with id 1488316772753571631 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)
2015-01-27 20:04:14 INFO: get timestamp for tx with id 1488316772753571631 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)
2015-01-27 20:04:58 INFO: tx with id 1488316772753571631 found
2015-01-27 20:04:58 INFO: get timestamp for tx with id 1488316772753571631 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)
2015-01-27 20:05:21 INFO: tx with id 1488316772753571631 found
2015-01-27 20:05:21 INFO: get timestamp for tx with id 1488316772753571631 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 will now try to revert to the precompiled burst.jar on one of the pc's and see if that fixes the problems. if it is, it's just me having broken my burst fork. i suspect not though, but who knows, perhaps i merged in 1.2.1 in a bad way, missing something important. Anyone else stuck at 60413?, and what wallet version are you using?
sorry for all the noise... just kinda confused, never had this kind of problem before.
i have same messages, but daemon works fine
nxt.wellKnownPeers=198.199.103.145; 178.62.39.204; burst.cryptoport.io; 192.155.252.202; 37.58.107.74; 119.81.165.138; 119.81.44.170; 119.81.44.171
January 27, 2015, 03:14:57 PM
Currently on 60524 here, no issues. Sorry for not being of much help :/
January 27, 2015, 03:07:58 PM
(edit)
running the 1.2.1 precompiled jar gives me other results than running my compiled version of 1.2.1, using my fork at github, which *should*'ve been updated with the 1.2.1 on the burst github.
I will compare sources and trace back and see what's the cause, either i merged in something in a bad way, or i didn't pull stuff out correctly, or the compile process itself was wrong somehow, or perhaps the jar in the 1.2.1 archive has not been built with the exact 1.2.1 sources on github. Will go hunt for answes and be back once i know what i did wrong. Until further notice, you can assume i made an error somewhere.
my fork stumbles upon block 60414, while the burst.jar in the 1.2.1 distro has no issues with that block.
sorry for all the noise... just kinda confused, never had this kind of problem before.
running the 1.2.1 precompiled jar gives me other results than running my compiled version of 1.2.1, using my fork at github, which *should*'ve been updated with the 1.2.1 on the burst github.
I will compare sources and trace back and see what's the cause, either i merged in something in a bad way, or i didn't pull stuff out correctly, or the compile process itself was wrong somehow, or perhaps the jar in the 1.2.1 archive has not been built with the exact 1.2.1 sources on github. Will go hunt for answes and be back once i know what i did wrong. Until further notice, you can assume i made an error somewhere.
my fork stumbles upon block 60414, while the burst.jar in the 1.2.1 distro has no issues with that block.
sorry for all the noise... just kinda confused, never had this kind of problem before.
January 27, 2015, 02:11:54 PM
Another question, if you're plotting with the GPU plotter with 'direct write' so it optimizes and plots at the same time, how much slower does it go then normal plotting? It also looks like it freezes when you start plotting, but it's still writing to the disk, no status text is updated. Does stagger size matter with 'direct write'? If it's properly defraged couldn't you effectively have a stagger size of like 1024 and it wouldn't matter?
Bump on this... It takes so long to plot, a few questions help a lot.
https://burstforum.com/index.php?threads/gpu-plot-generator.45/
This thread should answer your questions.
Specific details in the middle of that thread
https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-12#post-3252
Hopefully these conversation can move to the forum and off of this thread for better organization.
Good-Luck
I already checked through that thread and read the relevant posts. It doesn't answer the above questions though as I was asking for other peoples experience with direct write and stagger size with direct write. That thread is also not active, so it's sorta pointless to post there.
Also, I finished optimizing one of my plots using the optimizer. However the newly 'optimized' plot is now smaller then the old plot by 5GB and of course the sizes don't match when I start up blagos miner. Is this normal? Did something go wrong along the way?
Hmmm... after adjusting the name of the file it only finishes 3s faster then the old plots (also it appears to be corrupt now).
Benchmark Comparison - Direct vs Buffer - https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-11#post-3014
Why Direct is Slower than Buffer - https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-11#post-3034
Plot size will remain the same after optimization, if it is not then something went wrong along the way. Did you run out of disc space?
Information about Stagger setting when Direct Plotting - https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-13#post-3348
During a direct right method, the stagger setting is used to setup a ram buffer for pre-ordering of the nonces.
In your example, a stagger size of 1024 during a direct right method will just use 1024KB of RAM for the nonce buffer re-ordering.
In this thread and the thread on the forums a few people have complained about the reliability of the direct right method, also the performance hit for direct right compared with just plotting and optimizing does not appear to be worth it.
Maybe someone else can add some information to this topic.
Just because no one has posted in the BurstForum thread about the GPU plotter doesn't mean it's dead. This seems like the perfect type of question to ask in a Burst forum within the GPU plotter post. I'm guessing the regulars have had their questions answered you would be a perfect candidate to awaken the thread and maybe Cryo will answer your questions directly
January 27, 2015, 01:30:43 PM
New article, front page on a major crypto site: "What happened to Ethereum?"...
https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/
Their tweet:
CCN claims to have more than 12,000 on their email list and 300,000 unique visitors. They have +23,000 followers on Twitter.
https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/
Quote
One of the promising applications of the block chain technology are smart contracts. Different startups have been working on launching smart contracts, like Ethereum, but it would appear that a small crypto startup has beaten everyone else to it.
Their tweet:
Quote
CryptoCoinsNews @CryptoCoinsNews · 6h 6 hours ago
Cryptocurrency BURST Makes Smart Contracts a Reality, What Happened to Ethereum? https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/ …
Cryptocurrency BURST Makes Smart Contracts a Reality, What Happened to Ethereum? https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/ …
CCN claims to have more than 12,000 on their email list and 300,000 unique visitors. They have +23,000 followers on Twitter.
146 Shares already. Nice work mate!
Gonna contact them about an error in the article, yes, really nice that we are getting noticed!
January 27, 2015, 01:23:08 PM
Another question, if you're plotting with the GPU plotter with 'direct write' so it optimizes and plots at the same time, how much slower does it go then normal plotting? It also looks like it freezes when you start plotting, but it's still writing to the disk, no status text is updated. Does stagger size matter with 'direct write'? If it's properly defraged couldn't you effectively have a stagger size of like 1024 and it wouldn't matter?
Bump on this... It takes so long to plot, a few questions help a lot.
https://burstforum.com/index.php?threads/gpu-plot-generator.45/
This thread should answer your questions.
Specific details in the middle of that thread
https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-12#post-3252
Hopefully these conversation can move to the forum and off of this thread for better organization.
Good-Luck
I already checked through that thread and read the relevant posts. It doesn't answer the above questions though as I was asking for other peoples experience with direct write and stagger size with direct write. That thread is also not active, so it's sorta pointless to post there.
Also, I finished optimizing one of my plots using the optimizer. However the newly 'optimized' plot is now smaller then the old plot by 5GB and of course the sizes don't match when I start up blagos miner. Is this normal? Did something go wrong along the way?
Hmmm... after adjusting the name of the file it only finishes 3s faster then the old plots (also it appears to be corrupt now).
January 27, 2015, 01:19:32 PM
New article, front page on a major crypto site: "What happened to Ethereum?"...
https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/
Their tweet:
https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/
Quote
One of the promising applications of the block chain technology are smart contracts. Different startups have been working on launching smart contracts, like Ethereum, but it would appear that a small crypto startup has beaten everyone else to it.
Their tweet:
Quote
CryptoCoinsNews @CryptoCoinsNews · 6h 6 hours ago
Cryptocurrency BURST Makes Smart Contracts a Reality, What Happened to Ethereum? https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/ …
Cryptocurrency BURST Makes Smart Contracts a Reality, What Happened to Ethereum? https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/ …
146 Shares already. Nice work mate!
January 27, 2015, 01:10:47 PM
New article, front page on a major crypto site: "What happened to Ethereum?"...
https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/
Their tweet:
CCN claims to have more than 12,000 on their email list and 300,000 unique visitors. They have +23,000 followers on Twitter.
https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/
Quote
One of the promising applications of the block chain technology are smart contracts. Different startups have been working on launching smart contracts, like Ethereum, but it would appear that a small crypto startup has beaten everyone else to it.
Their tweet:
Quote
CryptoCoinsNews @CryptoCoinsNews · 6h 6 hours ago
Cryptocurrency BURST Makes Smart Contracts a Reality, What Happened to Ethereum? https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/ …
Cryptocurrency BURST Makes Smart Contracts a Reality, What Happened to Ethereum? https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/ …
CCN claims to have more than 12,000 on their email list and 300,000 unique visitors. They have +23,000 followers on Twitter.
January 27, 2015, 12:41:16 PM
Another question, if you're plotting with the GPU plotter with 'direct write' so it optimizes and plots at the same time, how much slower does it go then normal plotting? It also looks like it freezes when you start plotting, but it's still writing to the disk, no status text is updated. Does stagger size matter with 'direct write'? If it's properly defraged couldn't you effectively have a stagger size of like 1024 and it wouldn't matter?
Bump on this... It takes so long to plot, a few questions help a lot.
https://burstforum.com/index.php?threads/gpu-plot-generator.45/
This thread should answer your questions.
Specific details in the middle of that thread
https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-12#post-3252
Hopefully these conversation can move to the forum and off of this thread for better organization.
Good-Luck
January 27, 2015, 12:14:27 PM
Another question, if you're plotting with the GPU plotter with 'direct write' so it optimizes and plots at the same time, how much slower does it go then normal plotting? It also looks like it freezes when you start plotting, but it's still writing to the disk, no status text is updated. Does stagger size matter with 'direct write'? If it's properly defraged couldn't you effectively have a stagger size of like 1024 and it wouldn't matter?
Bump on this... It takes so long to plot, a few questions help a lot.
January 27, 2015, 12:07:17 PM
I'm seeing NXT log entries like this:
Plus I submitted a transaction to my wallet, called getUnconfirmedTransactionIds then getTransaction on that transaction only to be told:
Possible race condition in the wallet software?
Code:
2015-01-27 14:41:42 INFO: tx with id 0 found
2015-01-27 14:41:42 INFO: Transaction to 4697159292272720752 amount 0
2015-01-27 14:41:42 INFO: Transaction to 4697159292272720752 amount 0
Plus I submitted a transaction to my wallet, called getUnconfirmedTransactionIds then getTransaction on that transaction only to be told:
Code:
{\"errorDescription\":\"Unknown transaction\",\"errorCode\":5}
Possible race condition in the wallet software?
These are AT txs, 4697159292272720752 is account number. When an AT program seeks for a tx after a timestamp and there is none you see that debug message. These outputs will be removed in next releases.
January 27, 2015, 11:10:20 AM
I've known about burst for while now, seriously considering a "bursting" rig I guess. Anyway to calculate best bang for buck? Obviously storage capacity is king so like 4tb blacks but what gpu for plotting? Does it matter? Thanks in advanced 
The plotter is for Plotting your hard drives, This is what creates the file you will mine from. The plotting software you use Has no effect on your mining. For a while GPU plotter was the fastest way to plot drives but atm i think Wplotter is King, Atleast its was for me.
Simple answer to your question, No. The plotter you use has no effect on your mining. Simple the speed of your plotting which can take weeks depending on how much HD space you have to Fill!
So is the way I described above with 4tb hard drives the best way to go?
January 27, 2015, 11:05:48 AM
I'm seeing NXT log entries like this:
Plus I submitted a transaction to my wallet, called getUnconfirmedTransactionIds then getTransaction on that transaction only to be told:
Possible race condition in the wallet software?
Code:
2015-01-27 14:41:42 INFO: tx with id 0 found
2015-01-27 14:41:42 INFO: Transaction to 4697159292272720752 amount 0
2015-01-27 14:41:42 INFO: Transaction to 4697159292272720752 amount 0
Plus I submitted a transaction to my wallet, called getUnconfirmedTransactionIds then getTransaction on that transaction only to be told:
Code:
{\"errorDescription\":\"Unknown transaction\",\"errorCode\":5}
Possible race condition in the wallet software?
January 27, 2015, 07:10:52 AM
Are you on irc? I'll contact you by email or PM otherwise.
I use Skype mostly so you can PM me to get my Skype id.
January 27, 2015, 07:06:44 AM
@mmmaybe - much appreciated - we are in this together and hopefully AT and Burst will be a successful combination (both myself and vbcs are very pleased with how AT has been integrated with Burst).
Looking to making more history with an actual "atomic cross-chain transfer" hopefully happening within the next month!
Looking to making more history with an actual "atomic cross-chain transfer" hopefully happening within the next month!
That would be amazing with a ACCT so soon! vbcs and I was talking about trying crowdfunding, and I might have a case. Are you on irc? I'll contact you by email or PM otherwise.
January 27, 2015, 07:03:52 AM
Beta pool at pool.burstcoining.com:8124 is back up. Looks like the wallet was upset due to that v1.2.0 fork so I cleaned out unconfirmed transactions and rescanned the blockchain.
Jump to: