Pages:
Author

Topic: ANN[gryF]$GRYF/GryfX Virtual Currency Options Market, NEW INFO MUST READ - page 9. (Read 37627 times)

full member
Activity: 238
Merit: 100
Hi,

Thank you, it seems, the 2118 block is the same in the wallet and in the pool.

BR
legendary
Activity: 938
Merit: 1001
We are on block 2102 (next is 2103)

Net hash only 2.8mh/s

Resynced from beginning

addnode=37.59.21.199

If people want our node

If there is longer fork - let us know nodes and we will add.
legendary
Activity: 938
Merit: 1001


We have modified our systems to display the correct Gryfen mined (basically x 100 does the trick) for clarity.

But be prepared for supporting any exchange adding this coin if you want them to display the coins properly.

Maybe don't need to do the x100 trick, see it: http://www.hashharder.com/payouts?address=Gc8vEQMyVb4NbjUBKPz1A3kpVKCGFWCKje

"Gryfen    2083    26/Aug/2014 22:25:42 / 24 minute s ,34 second s ago    4900 GRYF
Gryfen    2082    26/Aug/2014 22:25:15 / 25 minute s ,1 second ago    4900 GRYF
Gryfen    2081    26/Aug/2014 22:25:11 / 25 minute s ,5 second s ago    4900 GRYF
Gryfen    2080    26/Aug/2014 22:24:23 / 25 minute s ,53 second s ago    4900 GRYF
Gryfen    2079    26/Aug/2014 22:16:51 / 33 minute s ,25 second s ago    4900 GRYF
Gryfen    2078    26/Aug/2014 22:15:55 / 34 minute s ,21 second s ago    4885.97137 GRYF"

Nice spot. It was only a display correction. I've removed the *100 part for now.

legendary
Activity: 938
Merit: 1001
Maybe forked Sad

My wallet on block 2090, in mean time I found block 2085 for Hashharder. Could someone check it? E.g. 2088 block hashes in wallet different from pool.

We have updated the wallet daemon to latest github. And removed the old blockchain/peers - resyncing from the beginning.
full member
Activity: 238
Merit: 100


We have modified our systems to display the correct Gryfen mined (basically x 100 does the trick) for clarity.

But be prepared for supporting any exchange adding this coin if you want them to display the coins properly.

Maybe don't need to do the x100 trick, see it: http://www.hashharder.com/payouts?address=Gc8vEQMyVb4NbjUBKPz1A3kpVKCGFWCKje

"Gryfen    2083    26/Aug/2014 22:25:42 / 24 minute s ,34 second s ago    4900 GRYF
Gryfen    2082    26/Aug/2014 22:25:15 / 25 minute s ,1 second ago    4900 GRYF
Gryfen    2081    26/Aug/2014 22:25:11 / 25 minute s ,5 second s ago    4900 GRYF
Gryfen    2080    26/Aug/2014 22:24:23 / 25 minute s ,53 second s ago    4900 GRYF
Gryfen    2079    26/Aug/2014 22:16:51 / 33 minute s ,25 second s ago    4900 GRYF
Gryfen    2078    26/Aug/2014 22:15:55 / 34 minute s ,21 second s ago    4885.97137 GRYF"
full member
Activity: 238
Merit: 100
Maybe forked Sad

My wallet on block 2090, in mean time I found block 2085 for Hashharder. Could someone check it? E.g. 2088 block hashes in wallet different from pool.
full member
Activity: 238
Merit: 100
I'm too, thank you for the dev. I joined to the hashharder pool, but I'm only who is mining on that pool. Please join to me to find block together and break out from current POW difficulty (15.97). Thank you.

Just a remark, the showed pool and my hashrate is 3 times higher than my rig's 5 MH/s .
sr. member
Activity: 342
Merit: 250
i successfully upgraded to the latest wallet using gryfencoin-installer.msi and qt is running fine

i observed though that it did not create a shortcut to the qt in the start-menu, i only got shortcuts to the miner, readme and whatsnew
hero member
Activity: 629
Merit: 500
IMPORTANT UPGRADE!

We have updated the windows and linux wallet
Before updating,  backup your entire ~/.gryfencoin folder  (~\AppData\Roaming\GryfenCoin on windows) including the wallet.dat file.
We have been testing the wallet for days and everything is working properly, but extra precaution is always a good practice.

LINUX: http://gryfenco.in/download/gryfencoin-qt-x64-ubutu-140.4.zip
WIN: http://gryfenco.in/download/gryfencoin-installer.msi
SOURCE: https://github.com/GryfenCrypto/gryfencoin
or download from GryfenCoin website http://gryfenco.in/#dld

This release basically fixes the controversial problem of the FOUNDATION address in a very radical way:
the extra vout transaction has been completely removed and the FOUNDATION define commented out


transferred wallet.dat just fine in windows 7  Grin
newbie
Activity: 12
Merit: 0
IMPORTANT UPGRADE!

We have updated the windows and linux wallet
Before updating,  backup your entire ~/.gryfencoin folder  (~\AppData\Roaming\GryfenCoin on windows) including the wallet.dat file.
We have been testing the wallet for days and everything is working properly, but extra precaution is always a good practice.

LINUX: http://gryfenco.in/download/gryfencoin-qt-x64-ubutu-140.4.zip
WIN: http://gryfenco.in/download/gryfencoin-installer.msi
SOURCE: https://github.com/GryfenCrypto/gryfencoin
or download from GryfenCoin website http://gryfenco.in/#dld

This release basically fixes the controversial problem of the FOUNDATION address in a very radical way:
the extra vout transaction has been completely removed and the FOUNDATION define commented out
newbie
Activity: 12
Merit: 0
I cleaned up the code removing the second output in that transaction and commenting out all the reference to FOUNDATION address.

Yep, we now have the new wallet code. And setup the pool again.

The real point is: the problem was non existent at all.

This was simply not the case. Your wallet was Rejecting blocks because of the very fact that you had kept the second transaction requirement in the code. Upon submitting a block to the wallet, it was REJECTING all found blocks because the "coinbase transaction does not pay the dev address".

So, the normal solution to this (as in X13 coins and others), is to locate the FOUNDATION address (in main.h) and modify the pool software to automatically generate a second coinbase transaction (usually referred to as the tx_charity or tx_donation). The address has to be encoded as an script pub key - which is trivial.

However, even after doing this - the wallet was still rejecting the coins.

Also we truncated the COIN constant value to be sure that the total amount we decided to support would fit without overflowing.

And this is all fine and dandy when it comes to your own coin's implementation of how it displays it. But as (all? nearly all?) other coins have the 8.8 notation - presumably most exchange/pool software is coded to handle that sort of storage - database rows would be typed potentially as 8.8 Deciminal types. This coin is using 10.6, which affects this type of storage very differently. Of course if people are using double floating point notation in all places, it should be ok - But expect hiccups.

We have modified our systems to display the correct Gryfen mined (basically x 100 does the trick) for clarity.

But be prepared for supporting any exchange adding this coin if you want them to display the coins properly.
It is strange that you got that message because the code was the following:
        // gryfencrypto:
        int64_t nExtraFee = 0;//nFees * EXTRA_FEE_PCT;
        //if(nExtraFee < MIN_EXTRA_FEE) nExtraFee=MIN_EXTRA_FEE;
        if (vtx[0].vout[1].nValue < nExtraFee)
            return error("ConnectBlock() : coinbase does not pay enough to dev addresss");

is not possible that nValue is ever  <0;

anyway I have found a serious bug I fixed right now:
In main.cpp  CheckBlock, line 2224:
// Coinbase output should be empty if proof-of-stake block
        //gryfencoin: added compatibility check because there are some transactions with 2 vout and vout[1] not empty
        if(vtx[0].vout.size() == 1 )
        {
            if(!vtx[0].vout[0].IsEmpty())
                return error("CheckBlock() : coinbase output not empty for proof-of-stake block");
        }
        else if (vtx[0].vout.size() == 2)
        {
            if ((!vtx[0].vout[0].IsEmpty() || !vtx[0].vout[1].IsEmpty() ))
                return error("CheckBlock() : coinbase output not empty for proof-of-stake block");
        }
        else
           return error("CheckBlock() : something really wrong happened!");

that should avoid orphan transaction and invalid blocks.
hero member
Activity: 629
Merit: 500
glad to hear its stable now =]  this coin has an awesome future.
sr. member
Activity: 294
Merit: 250
member
Activity: 115
Merit: 10
One of the big selling points for this coin's Twitter marketing was "CPU mineable." Is anyone actually CPU mining - specifically with a factory-default CPU? Are you getting anything?

So the difficulty is at 479 so no this coin cannot be CPU mined.  I mined about 300 blocks solo running x15 into localhost but the CPU seemed pointless at that point.  The whitepaper says they are going to implement a GPU only algo for the POS mining and for like bonus payouts different from the block rewards which will remain x15 if I read it correctly. 
member
Activity: 75
Merit: 10
One of the big selling points for this coin's Twitter marketing was "CPU mineable." Is anyone actually CPU mining - specifically with a factory-default CPU? Are you getting anything?
legendary
Activity: 938
Merit: 1001
I cleaned up the code removing the second output in that transaction and commenting out all the reference to FOUNDATION address.

Yep, we now have the new wallet code. And setup the pool again.

The real point is: the problem was non existent at all.

This was simply not the case. Your wallet was Rejecting blocks because of the very fact that you had kept the second transaction requirement in the code. Upon submitting a block to the wallet, it was REJECTING all found blocks because the "coinbase transaction does not pay the dev address".

So, the normal solution to this (as in X13 coins and others), is to locate the FOUNDATION address (in main.h) and modify the pool software to automatically generate a second coinbase transaction (usually referred to as the tx_charity or tx_donation). The address has to be encoded as an script pub key - which is trivial.

However, even after doing this - the wallet was still rejecting the coins.

Also we truncated the COIN constant value to be sure that the total amount we decided to support would fit without overflowing.

And this is all fine and dandy when it comes to your own coin's implementation of how it displays it. But as (all? nearly all?) other coins have the 8.8 notation - presumably most exchange/pool software is coded to handle that sort of storage - database rows would be typed potentially as 8.8 Deciminal types. This coin is using 10.6, which affects this type of storage very differently. Of course if people are using double floating point notation in all places, it should be ok - But expect hiccups.

We have modified our systems to display the correct Gryfen mined (basically x 100 does the trick) for clarity.

But be prepared for supporting any exchange adding this coin if you want them to display the coins properly.
newbie
Activity: 12
Merit: 0
Code:
    if(IsProofOfWork())
    {
        CBitcoinAddress address(!fTestNet ? FOUNDATION : FOUNDATION_TEST);
        CScript scriptPubKey;
        scriptPubKey.SetDestination(address.Get());
        if (vtx[0].vout[1].scriptPubKey != scriptPubKey)
            return error("ConnectBlock() : coinbase does not pay to the dev address)");

        // gryfencrypto:
        int64_t nExtraFee = 0;//nFees * EXTRA_FEE_PCT;
        //if(nExtraFee < MIN_EXTRA_FEE) nExtraFee=MIN_EXTRA_FEE;
        if (vtx[0].vout[1].nValue < nExtraFee)
            return error("ConnectBlock() : coinbase does not pay enough to dev addresss");
    }

Is still in code.

If you could please update your coin to remove this.

Or ideally, another pool who has this working - if they could publish the stratum changes.

We have worked with many coins that have donation address requirements - and haven't had this issue of block submission before.


I cleaned up the code removing the second output in that transaction and commenting out all the reference to FOUNDATION address.
Anyway I  zeroed the transaction value initially just to release the coin on time without compromising the rest of code. Now I have finished performing tests and it seems stable and working properly.
The real point is: the problem was non existent at all. there was no coin going to FOUNDATION address before because the value was zero. Also why in the world a mining pool service would use an address in the src code to configure their software?Huh You run coind and get a new valid address... that's it!
Also we truncated the COIN constant value to be sure that the total amount we decided to support would fit without overflowing.
Regarding the CentOs installing script, we are open to contributions. We don't have neither CentOs installed on our development systems, nor experts of this specific distro, so any kind of help will be highly appreciated.
Thanks for your precious feedback and support and get the new src at the usual location https://github.com/GryfenCrypto/gryfencoin.git
sr. member
Activity: 332
Merit: 250
If you require any promotional services please do send me a private message.
legendary
Activity: 938
Merit: 1001
Code:
    if(IsProofOfWork())
    {
        CBitcoinAddress address(!fTestNet ? FOUNDATION : FOUNDATION_TEST);
        CScript scriptPubKey;
        scriptPubKey.SetDestination(address.Get());
        if (vtx[0].vout[1].scriptPubKey != scriptPubKey)
            return error("ConnectBlock() : coinbase does not pay to the dev address)");

        // gryfencrypto:
        int64_t nExtraFee = 0;//nFees * EXTRA_FEE_PCT;
        //if(nExtraFee < MIN_EXTRA_FEE) nExtraFee=MIN_EXTRA_FEE;
        if (vtx[0].vout[1].nValue < nExtraFee)
            return error("ConnectBlock() : coinbase does not pay enough to dev addresss");
    }

Is still in code.

If you could please update your coin to remove this.

Or ideally, another pool who has this working - if they could publish the stratum changes.

We have worked with many coins that have donation address requirements - and haven't had this issue of block submission before.

full member
Activity: 238
Merit: 100
Hi Guys,

To avoid other misinterpretations, the mentioned Newsletter came from on email for me and other registered user on the official homapage. Maybe I had a mistake, that I didn't underlined and stressed that is not my opinion, and I was also surprised about it...


Best regards and good luck for this unmineable coin, however, I hope dev will be correct the source and wallet, because on the proposed pool also unuseable ATM.
Pages:
Jump to: