Bitcoin Forum
November 05, 2024, 02:57:37 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 [35] 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 »
  Print  
Author Topic: [ANN][AID] AidBit | Digital-currency redefined | POW/POS | Groestl | Charity  (Read 101129 times)
coke15
Member
**
Offline Offline

Activity: 176
Merit: 10


View Profile
July 31, 2014, 10:59:05 AM
 #681

hi

possible to force coin swap to use the last good wallet?

my aid are still blocked :/


edit:  the AID "no confirmed" on wallets  are definitly dead?

If they were mined on the wrong blockchain, unfortunately yes. Are you sure you have the latest clean blockchain?
Please PM the screenshot and TX IDs. Try to export the private key. Delete everything and import the key back. (dumpprivkey/importprivkey)

Cheers.

hi vger  you have a pm Smiley
vger888
Full Member
***
Offline Offline

Activity: 129
Merit: 100

AidBit - Technical Support


View Profile
July 31, 2014, 02:28:39 PM
Last edit: July 31, 2014, 03:15:21 PM by vger888
 #682

Guyz, can't tell you enough how happy I am, thank you very much for holding on, despite issues at start! We've put huge amount of energy into this project and will continue doing so! Smiley

Cheers,

V
thenite0wl
Full Member
***
Offline Offline

Activity: 192
Merit: 100


View Profile
July 31, 2014, 02:40:23 PM
 #683

last two wallet releases cause my wallet to constantly crash during solo mining. any ideas?
minersday
Hero Member
*****
Offline Offline

Activity: 1484
Merit: 535


View Profile
July 31, 2014, 02:40:44 PM
 #684

Guyz, can't tell you enough how happy I am, thank you very much for holding on, despite our problems! We've put huge amount of energy into this project and will continue doing so! Smiley

Cheers,

V

Nice to hear this!
AidBit (OP)
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile WWW
July 31, 2014, 02:46:39 PM
Last edit: July 31, 2014, 03:02:50 PM by AidBit
 #685

last two wallet releases cause my wallet to constantly crash during solo mining. any ideas?
Please PM Windows Application Error log entries and screenshot. You're probably talking Windows, right? I have pretty good idea what could be the problem and will address the issue as soon as my brain cools down a bit. Smiley Actually, we've had only one such occurrence since the launch, so please check if it's not something on your end. Thank you.

AidBit
coke15
Member
**
Offline Offline

Activity: 176
Merit: 10


View Profile
July 31, 2014, 06:20:55 PM
 #686

hi

thanks to aidbit team for her work  and special thanks to vger  Wink
thenite0wl
Full Member
***
Offline Offline

Activity: 192
Merit: 100


View Profile
July 31, 2014, 08:43:58 PM
 #687

if success comes through hard work, then aidbit should be a success.
AidBit (OP)
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile WWW
July 31, 2014, 11:12:27 PM
 #688

if success comes through hard work, then aidbit should be a success.

Hard work without the vision wouldn't be very productive! Wink

thenite0wl
Full Member
***
Offline Offline

Activity: 192
Merit: 100


View Profile
August 01, 2014, 12:10:59 AM
 #689

is there a fee associated with the official pools?
HR
Legendary
*
Offline Offline

Activity: 1176
Merit: 1011


Transparency & Integrity


View Profile
August 01, 2014, 06:33:02 AM
 #690

is there a fee associated with the official pools?

    High performance Node.js backend
    Coin Maturity: 500 blocks
    Min Payout: 10 AID
     Low Fees: 1%

http://maya.aidbit.net/
http://felix.aidbit.net/
http://kei.aidbit.net:8888/



AidBit (OP)
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile WWW
August 01, 2014, 11:16:27 AM
Last edit: August 02, 2014, 06:14:08 AM by AidBit
 #691



OFFICIAL STATEMENT:

AidBit Dev Team is proud to announce that we’ve managed to fix all our our forking and synchronization issues.

When we were designing AidBit, we wanted to create something different, something new and something better and not just a copy of a proven recipe. We had an extensive two months testing period, but just couldn’t predict everything and test every possible combination. Unfortunately, block reward calculation algorithm started causing forks on our pool servers, as soon as POS blocks appeared. POS blocks also crippled POW network by rising the POW difficulty sky high.

We reacted in minutes and started diagnosing the problem. We tried to address the issues from multiple directions and in the process extended POS Target Spacing from 1 minute to 10 minutes and implemented various optimizations. At the end we decided to modify the block reward algorithm to calculate block reward based on previous block's height and difficulty, regardless whether previous block was a POW or POS block. This way we introduced special “After-POS blocks”, which are calculated using POS difficulty. In the long run, this can help create scarcity and prevent multi-pools and pool-hopper from taking advantage of current high hashrates.

We would like to apologize for all problems caused and thank the community for being so understanding. We would also like to request the community to try to stay as polite as possible to other coins communities, even if they’re spreading lies and attacking us. Let’s prove ourselves by our actions and not by others' mistakes.

Sincerely,

AidBit Team


HR
Legendary
*
Offline Offline

Activity: 1176
Merit: 1011


Transparency & Integrity


View Profile
August 01, 2014, 12:03:39 PM
 #692

According to the money supply growth over these last 72 hours, daily, 24 hour average rewards come to 235,223 AidBit. This translates into 9,801 AidBit per hour, and an average payout of 163.35 AidBit per block. After taking into account the 10% charity contribution, the 3% to developers, and the 1% pool fee, the 'take home' rewards for miners would be roughly the following: 202,291 daily, 8,429 hourly, and an average of 140.48 per block.

Using these numbers, it's possible to calculate an average network hashrate of just under 1.35 GH/s (for the past 24 hours ending at approximately 7:15 UTC today), and an average daily net payout ("take home") of just under 1,500 AidBit per 10 MH/s of hash power.

According to sgminer data, we're seeing just under 57 blocks found per hour, or 1,359 daily, with an average diff of 28.859 (63 max., 12 min., and 28 mean). Using the formula given on the OP, that would translate into, well, I still don't know exactly what - I'm not able to come up with anything close to what the real time numbers are.  Sad

The block explorer data confirms the sgminer blocks found numbers, but generates an average diff of 25.4 (since sgminer always rounds to the next highest integer, that's probably the explanation for the difference).

My problem is that I'm still not able to get these numbers to match with the ceil(8 * dDiff / (525600 + nHeight) * 525600) formula on the OP, which using the sgminer and BE diffs would give us average total rewards of .0000000008 and .0000000007, respectively (as of block 21161). If we take those numbers and multiply them by the subsidy that we get using "getsubsidy" in the console, we get 20 and 17.5, respectively. If we multiply by absolute network hashrate numbers, we get even smaller numbers. I can't get close to "blockvalue" either.  Huh

230.872 / 287,377,581,600 = .0000000008

203.2 / 287,377,581,600 = .0000000007

I'm still at a loss trying to get the numbers to "balance out" and I'm sure that's it's my lack of understanding a complicated formula that takes time and effort to explain, time and effort not necessarily available or well spent at the moment, and, as such, I do not expect any immediate response to this - just posting my "Rubik's Cube" ponderings.  Wink

A recent  "getmininginfo" snapshot leaves me with the same quandary.
{
"blocks" : 21242,
"currentblocksize" : 0,
"currentblocktx" : 0,
"difficulty" : {
"proof-of-work" : 22.91746578,
"proof-of-stake" : 10.10269522,
"search-interval" : 0
},
"blockvalue" : 17700000000,
"netmhashps" : 2008.77073548,
"netstakeweight" : 592733.68530821,
"errors" : "",
"pooledtx" : 0,
"stakeweight" : {
"minimum" : 0,
"maximum" : 0,
"combined" : 0
},
"stakeinterest" : 20000000,
"testnet" : false
}

(8 * 22.91746578 / (525600 + 21242) * 525600)

183.33972624 / (546842 * 525600)

183.33972624 / 287420155200 = .00000000063

What do we multiply the .00000000063 number by to get a block reward of 177?

280952380952 * .00000000063 = 176.99999999
Where does that 280952380952 number come from.  Huh

Just having fun and doing my best to understand, but this is not mission critical and requires no immediate attention.   Cheesy


Again, great work you guys!


AidBit (OP)
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile WWW
August 01, 2014, 12:32:06 PM
 #693

According to the money supply growth over these last 72 hours, daily, 24 hour average rewards come to 235,223 AidBit. This translates into 9,801 AidBit per hour, and an average payout of 163.35 AidBit per block. After taking into account the 10% charity contribution, the 3% to developers, and the 1% pool fee, the 'take home' rewards for miners would be roughly the following: 202,291 daily, 8,429 hourly, and an average of 140.48 per block.

Using these numbers, it's possible to calculate an average network hashrate of just under 1.35 GH/s (for the past 24 hours ending at approximately 7:15 UTC today), and an average daily net payout ("take home") of just under 1,500 AidBit per 10 MH/s of hash power.

According to sgminer data, we're seeing just under 57 blocks found per hour, or 1,359 daily, with an average diff of 28.859 (63 max., 12 min., and 28 mean). Using the formula given on the OP, that would translate into, well, I still don't know exactly what - I'm not able to come up with anything close to what the real time numbers are.  Sad

The block explorer data confirms the sgminer blocks found numbers, but generates an average diff of 25.4 (since sgminer always rounds to the next highest integer, that's probably the explanation for the difference).

My problem is that I'm still not able to get these numbers to match with the ceil(8 * dDiff / (525600 + nHeight) * 525600) formula on the OP, which using the sgminer and BE diffs would give us average total rewards of .0000000008 and .0000000007, respectively (as of block 21161). If we take those numbers and multiply them by the subsidy that we get using "getsubsidy" in the console, we get 20 and 17.5, respectively. If we multiply by absolute network hashrate numbers, we get even smaller numbers. I can't get close to "blockvalue" either.  Huh

230.872 / 287,377,581,600 = .0000000008

203.2 / 287,377,581,600 = .0000000007

I'm still at a loss trying to get the numbers to "balance out" and I'm sure that's it's my lack of understanding a complicated formula that takes time and effort to explain, time and effort not necessarily available or well spent at the moment, and, as such, I do not expect any immediate response to this - just posting my "Rubik's Cube" ponderings.  Wink

A recent  "getmininginfo" snapshot leaves me with the same quandary.
{
"blocks" : 21242,
"currentblocksize" : 0,
"currentblocktx" : 0,
"difficulty" : {
"proof-of-work" : 22.91746578,
"proof-of-stake" : 10.10269522,
"search-interval" : 0
},
"blockvalue" : 17700000000,
"netmhashps" : 2008.77073548,
"netstakeweight" : 592733.68530821,
"errors" : "",
"pooledtx" : 0,
"stakeweight" : {
"minimum" : 0,
"maximum" : 0,
"combined" : 0
},
"stakeinterest" : 20000000,
"testnet" : false
}

(8 * 22.91746578 / (525600 + 21242) * 525600)

183.33972624 / (546842 * 525600)

183.33972624 / 287420155200 = .00000000063

What do we multiply the .00000000063 number by to get a block reward of 177?

280952380952 * .00000000063 = 176.99999999
Where does that 280952380952 number come from.  Huh

Just having fun and doing my best to understand, but this is not mission critical and requires no immediate attention.   Cheesy


Again, great work you guys!



I think I know, why your calculations don't add up. Actually, blockvalue calculation is wrong. It is currently calculated based on the bestblock diff and height and not on the previous block as it should be. It is purely a cosmetic issue, left from our old calculation. We were rushing the emergency release and left it for later. Thank you so much! Smiley
vger888
Full Member
***
Offline Offline

Activity: 129
Merit: 100

AidBit - Technical Support


View Profile
August 01, 2014, 12:55:25 PM
 #694

(8 * 22.91746578 / (525600 + 21242) * 525600)

183.33972624 / (546842 * 525600)

183.33972624 / 287420155200 = .00000000063

What do we multiply the .00000000063 number by to get a block reward of 177?

280952380952 * .00000000063 = 176.99999999
Where does that 280952380952 number come from.  Huh

Just having fun and doing my best to understand, but this is not mission critical and requires no immediate attention.   Cheesy


Again, great work you guys!



The difficulty the GetProofOfWorkReward function uses is calculated from nBits using the following function:

Code:
double ConvertBitsToDouble(unsigned int nBits){
    int nShift = (nBits >> 24) & 0xff;

    double dDiff =
        (double)0x0000ffff / (double)(nBits & 0x00ffffff);

    while (nShift < 29)
    {
        dDiff *= 256.0;
        nShift++;
    }
    while (nShift > 29)
    {
        dDiff /= 256.0;
        nShift--;
    }

    return dDiff;
}

Cheers,

V.
AidBit (OP)
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile WWW
August 01, 2014, 02:26:44 PM
 #695



REQUEST:

Please help us get accepted to Cryptsy.
Please submit Support Ticket and say something nice about AidBit.

https://cryptsy.freshdesk.com/support/tickets/new

Thank you!

Yours Sincerely,

AidBit
HR
Legendary
*
Offline Offline

Activity: 1176
Merit: 1011


Transparency & Integrity


View Profile
August 01, 2014, 02:51:20 PM
 #696


The blockvalue calculation would certainly affect my calculations and could be the reason why I'm having difficulties.

On the other hand, the dDiff shouldn't be a problem for me to figure out since that is the reported diff and something I just extract from the reported data, correct?

Where I'm having a problem is with figuring out how we arrive at the estimated block reward and what value is used to multiply nSubsidy by - the nSubsidy that's derived from nSubsidy = ceil(8 * 22.91746578 / (525600 + 21242) * 525600)

I've got to admit that both of your answers went right over my head.   Embarrassed   But that's okay - you always end up learning way more than you ever wanted when you ask questions that are out of your league. I'm studying the code (and I'm not a coder remember) and brushing up on operators and compound assignments, etc., and, well, I've got more to study . . .

. . . but I do have a quick question for now: How is the value for "COIN" derived?

AidBit (OP)
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile WWW
August 01, 2014, 03:39:01 PM
Last edit: August 01, 2014, 03:52:40 PM by AidBit
 #697


The blockvalue calculation would certainly affect my calculations and could be the reason why I'm having difficulties.

On the other hand, the dDiff shouldn't be a problem for me to figure out since that is the reported diff and something I just extract from the reported data, correct?

Where I'm having a problem is with figuring out how we arrive at the estimated block reward and what value is used to multiply nSubsidy by - the nSubsidy that's derived from nSubsidy = ceil(8 * 22.91746578 / (525600 + 21242) * 525600)

I've got to admit that both of your answers went right over my head.   Embarrassed   But that's okay - you always end up learning way more than you ever wanted when you ask questions that are out of your league. I'm studying the code (and I'm not a coder remember) and brushing up on operators and compound assignments, etc., and, well, I've got more to study . . .

. . . but I do have a quick question for now: How is the value for "COIN" derived?

This is a really simple one:

static const int64_t COIN = 100000000;

And one more thing, your calculation is actually the estimated reward for block 21243. Remeber, we're using reward calculation for the previous block.

nSubsidy = ceil(8 * 22.91746578 / (525600 + 21242) * 525600)
thenite0wl
Full Member
***
Offline Offline

Activity: 192
Merit: 100


View Profile
August 01, 2014, 05:08:24 PM
 #698

now that the network is stable, what's next for aidbit?
HR
Legendary
*
Offline Offline

Activity: 1176
Merit: 1011


Transparency & Integrity


View Profile
August 01, 2014, 05:53:30 PM
 #699


The blockvalue calculation would certainly affect my calculations and could be the reason why I'm having difficulties.

On the other hand, the dDiff shouldn't be a problem for me to figure out since that is the reported diff and something I just extract from the reported data, correct?

Where I'm having a problem is with figuring out how we arrive at the estimated block reward and what value is used to multiply nSubsidy by - the nSubsidy that's derived from nSubsidy = ceil(8 * 22.91746578 / (525600 + 21242) * 525600)

I've got to admit that both of your answers went right over my head.   Embarrassed   But that's okay - you always end up learning way more than you ever wanted when you ask questions that are out of your league. I'm studying the code (and I'm not a coder remember) and brushing up on operators and compound assignments, etc., and, well, I've got more to study . . .

. . . but I do have a quick question for now: How is the value for "COIN" derived?

This is a really simple one:

static const int64_t COIN = 100000000;

And one more thing, your calculation is actually the estimated reward for block 21243. Remeber, we're using reward calculation for the previous block.

nSubsidy = ceil(8 * 22.91746578 / (525600 + 21242) * 525600)

183,33972624 / 287420155200 = 0,000000000637880548468927

nSubsidy *= COIN would be 0,0637880548468927, and that, multiplied by the network hashrate, was getting me close to projecting block rewards consistent with the wallet and BE . . . thought I had a spread sheet that worked - was getting numbers very close anyway *using* the "netmhashps" number as a final variable to multiply by . . . but to no avail - it looks like the netmhashps number is not too reliable . . .

I give up. It's not that big of a deal. As you all have said, there's still plenty of 'polishing' left to do.

I think I remember you saying that the projected reward wasn't completely reliable yet . . .

. . . maybe I need to compare my numbers with actual payouts of the next block found. HUM.


Anyway, that's all fine and dandy, but let's not let this little issue of mine cloud the major success that this coin has already become.

  • The best POW/PoS coin in existence (using the best, most energy efficient algo in existence)
  • A truly state-of-the-art, one click mining wallet!
  • What's looking to be a network that's just as superlative as the coin and the wallet.
  • One of the best block explorers I've seen.
  • The most professional and engaged developers I have ever seen (and by your location, I think I might have an idea about where that comes from  Wink ).


I think I can smell something very big brewing here. VERY BIG.



HR
Legendary
*
Offline Offline

Activity: 1176
Merit: 1011


Transparency & Integrity


View Profile
August 01, 2014, 06:21:32 PM
 #700

So I was in the shower and came up with an idea that could help both the wallet woes and give the devs time to rethink the POS issues. Its kinda funny how running water can have such heavy influences on our awareness. I was think instead of implimenting POS into the current payouts we could instead make the POS for early adopters more like a certificate of deposit(CD). In other words allow users to choose how much they want to put into a savings account in the wallet that is not spendable unitl it has matured to a specific date. Allow users to specify between different amounts of time like 2yr 3 yr and 4yr. This way the devs could have time to figure out how to payout the 20% interest on these accounts over tim for at least 2 years, The users get to keep mining groestl pow and making aidbit..and the best point of all...This would be even more assurance that those with CDs would hold aidbit and not dump it for at least 2 yrs. IMO this would be highly lucrative for early adopters and also an added bonus for late adopters to keep adoption going. It would also encourage more buy orders than sell orders increasing aidbits liquidity.

I really like this idea too. Very interesting. I'm not sure how it would be implemented (but, hey, that's not my job Wink ) but I'm sure it can be done in some shape or form. Maybe not exactly as you have conceived it, but perhaps something simiiar. Great idea for motivating people to think long[er] term!

I also had a 'bright' idea (but I don't remember if I was in the shower or not Wink ), and mine was about the charity side of things. The phrase "give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime" came to mind, and I thought, hey, if we could link AidBit charity to information technology, wouldn't that be great? Supporting community centers in underdeveloped areas (1st world, 2nd world, 3rd world, whatever and wherever) with IT infrastructure (computers?) and internet conectivity (and of course, AidBit wallet installs) would be an example that would be incredibly charitable and symbiotic at the same time. It would sure beat giving away paper wallets anyway!


Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 [35] 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!