I managed to get the new 1.0.1.0 wallet by clicking the link in the OP.
However, despite having connections to the network and a spinning "sync wheel", My blockchain seem to be stuck 7 hours in the past.
Could this be an issue caused by connecting to nodes running the old wallet, and if so could you provide nodes that are using the new wallet/fork so I can update my conf file?
Try to restart the wallet or delete the blockchain database (%appdata%/AidBit - be careful you don't delete wallet.dat). Worked for me. Everything confirmed up to a little over 12 hours ago. Waiting . . . Should we expect to lose coins that were possibly mined on an old/bad fork? Add: thought it had worked - showed as having finished the sync - now "downloading 12172 of 12824 . . . last block received 32 seconds ago" - "647 block remaining" Weird! If your on Linux Wallet, please check: ./aidbitd getblockhash 12138 0000000011e73e1aa8c10e14b5d7bb8b48b0994a07a3a92bd694671c395560ec Using the windows 1.0.1.0 wallet, but that "weirdness" has cleared up now. BTW, all of my rewards with exclamation marks were mined on maya.aidbit.net - 23 payouts from 10:34 PM 07/25/2014 to 4:59 07/26/2014 UTC/GMT. I'll check the databases. Approximate ammount and address, please and I'll see what I can do.  Strangest thing. Some of those "exclamation marks" are starting to come in and confirm . . . as the block count increases . . . weird. Now downloading 12308 of 12959 . . . 651 remaining. current block 12308 16:58:31 getblockhash 12308 16:58:31 0000000000e569c415ccee9facf08a5916195bcb04879d736339bd96998c7137 Just reporting this for what it's worth. I'm mining, in no hurry to have it sync completely, and more interested in seeing where this goes.  For what it's worth. |
|
|
|
BTW, all of my rewards with exclamation marks were mined on maya.aidbit.net - 23 payouts from 10:34 PM 07/25/2014 to 4:59 07/26/2014 UTC/GMT.
I'll check the databases. Approximate ammount and address, please and I'll see what I can do. Okay. Sounds good. It's not urgent, so I'll PM you that data once the dust settles and you've got time to look at it. |
|
|
|
I managed to get the new 1.0.1.0 wallet by clicking the link in the OP.
However, despite having connections to the network and a spinning "sync wheel", My blockchain seem to be stuck 7 hours in the past.
Could this be an issue caused by connecting to nodes running the old wallet, and if so could you provide nodes that are using the new wallet/fork so I can update my conf file?
Try to restart the wallet or delete the blockchain database (%appdata%/AidBit - be careful you don't delete wallet.dat). Worked for me. Everything confirmed up to a little over 12 hours ago. Waiting . . . Should we expect to lose coins that were possibly mined on an old/bad fork? Add: thought it had worked - showed as having finished the sync - now "downloading 12172 of 12824 . . . last block received 32 seconds ago" - "647 block remaining" Weird! If your on Linux Wallet, please check: ./aidbitd getblockhash 12138 0000000011e73e1aa8c10e14b5d7bb8b48b0994a07a3a92bd694671c395560ec Using the windows 1.0.1.0 wallet, but that "weirdness" has cleared up now. no it hasn't - just came back - now it's "downloading 12203 of 12823 ... with 620 blocks remaining". Looking at the block explorer, the 12203 looks good as the last block . . . where the 12823 is coming from and the 620 block remaining, I don't know. I am running as a server and solo mining, if that matters. BTW, all of my rewards with exclamation marks were mined on maya.aidbit.net - 23 payouts from 10:34 PM 07/25/2014 to 4:59 07/26/2014 UTC/GMT. Are you sure you have the latest version? ./getblockhash 12203 0000000003d954fd87fdd01f74b9e09681a8f188d83911dff49be9ce56e178d2 15:20:02 getblockhash 12203 15:20:02 0000000003d954fd87fdd01f74b9e09681a8f188d83911dff49be9ce56e178d2 15:21:03 getblockhash 12206 15:21:03 0000000000851198689ffa8aa55cf8596d4cc6611c81bfb597ee8b4119dee698 |
|
|
|
I managed to get the new 1.0.1.0 wallet by clicking the link in the OP.
However, despite having connections to the network and a spinning "sync wheel", My blockchain seem to be stuck 7 hours in the past.
Could this be an issue caused by connecting to nodes running the old wallet, and if so could you provide nodes that are using the new wallet/fork so I can update my conf file?
Try to restart the wallet or delete the blockchain database (%appdata%/AidBit - be careful you don't delete wallet.dat). Worked for me. Everything confirmed up to a little over 12 hours ago. Waiting . . . Should we expect to lose coins that were possibly mined on an old/bad fork? Add: thought it had worked - showed as having finished the sync - now "downloading 12172 of 12824 . . . last block received 32 seconds ago" - "647 block remaining" Weird! If your on Linux Wallet, please check: ./aidbitd getblockhash 12138 0000000011e73e1aa8c10e14b5d7bb8b48b0994a07a3a92bd694671c395560ec Using the windows 1.0.1.0 wallet, but that "weirdness" has cleared up now. no it hasn't - just came back - now it's "downloading 12203 of 12823 ... with 620 blocks remaining". Looking at the block explorer, the 12203 looks good as the last block . . . where the 12823 is coming from and the 620 block remaining, I don't know. I am running as a server and solo mining, if that matters. BTW, all of my rewards with exclamation marks were mined on maya.aidbit.net - 23 payouts from 10:34 PM 07/25/2014 to 4:59 07/26/2014 UTC/GMT. |
|
|
|
I managed to get the new 1.0.1.0 wallet by clicking the link in the OP.
However, despite having connections to the network and a spinning "sync wheel", My blockchain seem to be stuck 7 hours in the past.
Could this be an issue caused by connecting to nodes running the old wallet, and if so could you provide nodes that are using the new wallet/fork so I can update my conf file?
Try to restart the wallet or delete the blockchain database (%appdata%/AidBit - be careful you don't delete wallet.dat). Worked for me. Everything confirmed up to a little over 12 hours ago. Waiting . . . Should we expect to lose coins that were possibly mined on an old/bad fork? Answered my question reading previous posts - exclamation marks mean the coins were mined on a bad fork, correct? Add: thought it had worked - showed as having finished the sync - now "downloading 12172 of 12824 . . . last block received 32 seconds ago" - "647 block remaining" Weird! |
|
|
|
Didn't hear anything about the negotiations with the brick&mortar stores. Did you make any progress there or is this on standby until you fixed the flaws, Jared?
A lot of this is occurring in the background as we speak. Do to NDA's etc we cannot give any more details until we are ready to publicly release the information. Good things lay ahead. Our primary focus right now getting the multi-algo update out. We have now successfully compiled different algos and we are in the process of testing them. What do you all think about these five algos as a unique DigiByte combo? 1) Sha256 2) Scrypt 3) Skein (2nd runner up NIST competition) 4) Keccack (considered to be the most secure algo after winning NIST competition as SHA-3 finalsit) 5) x11 (Miners seem to really love it) Which five algos would you like to see? After making sure the Myriad set up worked for DigiByte we decided it would be best if we did something unqie if possible. What are all your thoughts? There have been some very good suggestions on here recently. Thank you all for contributing! You know I like Groestl, so I won't bore you with tirades and exclamation marks. I believe that Groestl should be included for a multitude of reasons, but I'll limit this post to just mentioning my most important argument here and leave it to the rest of the community of Groestl believers to add to the list. If you leave Groestl out of the 5 algo mix, you'd be shunning the energy efficient GPU miners. One of the strongest arguments for the 5 algo mix is to include everybody, to make the coin a home for all miners, and hopefully on the most equitable basis possible. By leaving out groestl, you'd be leaving out the best of the energy efficient GPU algos. Qubit is the most efficient CPU algo, but I promised to limit this to one. x11 = total crap (sorry, but I couldn't resist) All IMVHO of course. |
|
|
|
Difficulty based block reward according to: ceil(8 * dDiff / (525600 + nHeight) * 525600)
Block reward scaling factor on 12 month periods
I can only get close with this: 8 * dDiff / ((525600 + nHeight) / 525600) Which looks wrong since that would be an increasing subsidy into a complete double by day 356 (and forget what multiplication instead of division gets you!). 8 * dDiff / ((525600 - nHeight) / 525600) would be a decreasing subsidy and gets me closer, for now, but that would take us to a complete 0 subsidy by day 365.  I'm sure I'm missing something here and really showing my ignorance.  nHeight is block height or block number. 1 year = ~525600 blocks So lets calculate the reward for dDiff = 1 and block 525600 (~365th day) 8 * 1 / ((525600 + 525600) / 526500) = 8 * 1 / (1051200 / 525600) = 8 * 1 / 2 = 4Realtime rewards are closer to a simple 8 * 1 dDiff, but off by a good fraction (even after taking into account the 10% charity factor). I can't get anything to work consistently. Also, I understand nHeight to mean current block height, being the highest block in existence to date. 12194 as of 2014-07-25 22:50:26. Am I wrong on this? |
|
|
|
Gents, a question... First off all, I think the price of the coin is very undervalued...
However, when we have multiple mining on the go, this will even create more DGB coins...
Don't you think this will drive the price even further down due to high inflation ? Thank you.
Actually the block rewards are the same if I am not mistaken It is my understanding as well that the block reward will stay the same.
Here's a little study I did on MYR:Do you really think so? Where are you getting your data? Blocks are being mined at an equal rate (more or less) regardless of the algo being used. http://myriad.theblockexplorer.com And the block reward is the same. Yes I have used this page. On that page you have an information how many coins you are getting per unified MH unit. 340 MYR / MH day by Sricpt 2805 MYR / MH day by Skein Of course this data fluctuates with every block a bit. My SKEIN GPU rig has power usage 300 W / 1 MH = 2805/300 = 9,35 MYR / W My SCRIPT ZEUS Blizzard miner has 38 W / 1 MH = 340/38 = 8,94 MYR / W Okay, I’ve been going over the numbers, and your numbers are looking better and better, but . . . Should it be the case that you are correct, the ASIC issue would be mute since effective reward adjustment would be already happening on an individual miner, per MH/s, basis. Looking at things from the total number of coins mined and their distribution to individual miners on a 1 MH/s basis, we move in your direction, but are unable to arrive at a similar conclusion with respect to Scrypt (on the other hand, the numbers suggest that SHA-256 should be effectively neutralized). I’m going to use the numbers taken from the following snapshot.  Let’s divide the 120,000 coins mined each hour by the 5 algos doing the mining. That leaves us with 24,000 coins, per hour, for each algo. If we then divide those 24,000 coins by the respective algo hashrates, we come up with the following results: Scrypt = 14.916096 coins per hour per MH/s SHA-256 = .0011722 coins per hour per MH/s Groestl = 2.2573363 coins per hour per MH/s Skein = .3992414 coins per hour per MH/s Qubit = 8.4299262 coins per hour per MH/s That’s simply dividing the reward by the collective hashrates. The per hour, per MH/s distribution is what it is. Same machine DAILY results would be roughly the following: Scrypt = 357.9863 coins @ 1 MH/s SHA-256 = 28.1328 coins @ 1 GH/s Groestl = 920.9932 coins @ 17 MH/s Skein = 1197.7242 coins @ 120 MH/s Qubit = 1143.0979 coins @ 5.65 MH/s That’s how the global numbers are divvyed up (give or take a few KH/s). Why would the SHA-256 settle for so little? Do they really have much choice? Anywhere else to go? . . . instead of turning their ASICs into very expensive paperweights . . . By these numbers, Scrypt ASIC is still hauling them in (on a relative basis) and have a long way to go before falling below breakeven (when using the 7 watt gridseed as electricity cost basis, even more so). So, is this issue a non-issue with respect to SHA-256? Or still an issue since they are so desperate as to keep mining when it’s a losing proposition and throwing good money after bad? These numbers suggest to me that the Scrypt ASIC continues to be an issue - until their numbers grow sufficiently so as to reduce their per MH/s rewards below profitability. Just where that equilibrium lay is still an unknown, but we can be quite sure it’s at some lower price rather than a higher price . . . as long as ASIC is part of the picture (unless their numbers and crowd herding gets as crazy as the SHA-256 crowd). BTW, what are the components of your SKEIN GPU rig? |
|
|
|
Difficulty based block reward according to: ceil(8 * dDiff / (525600 + nHeight) * 525600)
Block reward scaling factor on 12 month periods
I can only get close with this: 8 * dDiff / ((525600 + nHeight) / 525600) Which looks wrong since that would be an increasing subsidy into a complete double by day 356 (and forget what multiplication instead of division gets you!). 8 * dDiff / ((525600 - nHeight) / 525600) would be a decreasing subsidy and gets me closer, for now, but that would take us to a complete 0 subsidy by day 365. I'm sure I'm missing something here and really showing my ignorance. |
|
|
|
|
I've got an open ticket with Cryptsy that's been open for 7 hours . . . which is a good sign since it wasn't automatically closed.
Everyone's got to open a ticket. To use a much overused and abused phrase of late: Spread The Word!
|
|
|
|
I'm afraid boobs cant save GRS anymore. Shitcoins taken over too much shine.
you misspelled *Titcoins*  Hey, that's not a bad idea. Two for one! |
|
|
|
Let's get back on track with some constructive discussion, someone asked about the timing of the new algo etc.. based on this link: https://vertcoin.org/pow-algorithm-upgrade-lyra2/ , order of events would be: "There is still much work to be done before we roll it out. Here is a approximate timeline: 1. Derive appropriate initial memory and cpu levels to roughly match the current level (8/15/2014) 2. Implement the new algo in all the wallets including mobile (10/15/2014) 3. Run final testing on testnet (11/15/2014) 4. Final release to mainnet (11/30/2014) - These are estimates, we may move faster -" I hope this helps That's how you keep a thread serious! If there were any doubt before, there shouldn't be any more. On the other hand, taking into account the 6 rapid fire responses to my joke that would make any red-blooded reddit user proud and feeling right at home ... nah ... I know that wasn't your motivation. If there's one thing that I think I could call a common "thread" in recent times in the crypto sphere, it's been everyone's getting sidetracked with gimmicks and the call to "spread the word" to the point of cheap low rate spamming instead of keeping focused on simply creating and maintaining a good coin. |
|
|
|
Are we talking about the same site?
I think so. You tell me. http://www.reddit.com/ Packed to the hilt with twits and nitwits, IMO of course. |
|
|
|
The simple and basic reason is that there is far more volume with reddit and the 5000+ readers than here which has the same ~30 people posting.
" 5000+ readers" ...with a collective IQ that doesn't reach that same number.  " ~30 people posting" ...which often means that there's actual intelligence being expressed and the multitude of readers get their answers before having to post. https://bitcointalk.org/index.php?action=stats ...and the idiots think twice before posting crap. Add: so in reference to my first question/allusion on the matter, if a Dev gives more importance to reddit than BitCoinTalk, then 1) he/she is afraid of the technical level inherent in BitCoinTalk 2) he/she is frivolous, juvenile and only interested in being "virtually" popular (i.e. "liked") 3) he/she is not interested in serious intellectual interchange regarding coin development 4) all the above (Now you have the full version of my original tongue-in-cheek humor - please show your intelligence when responding.) |
|
|
|
We have some news! SpainCoin distribution Stage 3 set to begin on July 28th!
http://blog.spaincoin.org/2014/07/18/stage-3-to-begin-on-july-28th/SpainCoin stage 3 will begin on Monday, July 28th. With still about 6M coins left in stage 2, it seems unlikely it will all be allocated, so we will again be destroying excess coins like we did in the previous stage, providing a boost to SpainCoin’s projected value. We’re also going to work again on the SpainCoin marketplace we had envisioned earlier on.
Updated distribution plan:
Stage 1 (already over) 5M coins, ~1M were distributed, ~4M destroyed
Stage 2 began on June 10th, max 10M coins to be given away, excess coins to be destroyed.
Stage 3 to begin on July 28th, max 10M coins to be given away, half of the coins remaining to be destroyed, the other half to go towards the final stage 4.
Stage 4 to begin in early september, giving away the remaining coins, until the end of the year. I wouldn't destroy the remaining coins. I would hold them for late adopters and give out the same amounts already given out to whoever registers and whenever they finally do (until the giveaway coins run out). With over 1.6 million gamers in Spain, and only 2,352 people having received SPA via the electronic DNI, I'd say there's a lot of very computer literate people in Spain who still haven't heard about SPA. http://cincodias.com/cincodias/2014/03/05/economia/1394019685_040180.html One of the most important aspects of any successful cryptocurrency is a widely distributed network, and those 1.6 million Spanish gamers represent a huge user base for potential newcomers to the network. The DNI coin giveaway would continue to be a positive for SPA by getting their interest (that is if there are still giveaway coins to attract their interest with). Destroying the coins may have a short term benefit by boosting price short term, but the long term costs would be fatal in my opinion. "Pan para hoy, hambre para mañana" as we say in Spanish. Keep those coins for late comers so that the network can grow, and, along with that, as a healthy byproduct, so that the chances of wide scale adoption are also increased. Si no, creo que estaríamos tirando piedras sobre nuestro tejado. And then we'd need to start a campaign aimed at those Spanish gamers! |
|
|
|
Good news. But what do devs who value reddit more than BitCoinTalk indirectly tell us? (This is not an isolated case either.) |
|
|
|
Very few coins actually have devs that know what they are doing. These guys know what they are doing, they just need to figure out the best direction, then work can start.
I'm of the same opinion. Very few coins have devs that know what they're doing. Do you think that perhaps we should start an independent thread one of these days with a list on the OP? . . . not that it would be easy by any means - opinions without factual events, incidents, interchanges, etc., that serve to justify those opinion are meaningless . . . It might be worth it though as it could become one of the most entertaining and interesting reads on BitCoin Forum. |
|
|
|
The initial reward is diff * 8 and decreasing with every block found. Actually it isn't linear so the reward won't halve every year but be 8 * diff / number_of_years_passed.
Thanks for the help. I think I'm getting closer to a working understanding. Looking forward to it. Thank you. |
|
|
|
|
Show Posts
