Author

Topic: [ANN] Orbitcoin v1.6.0.0 ~ NeoScrypt ~ Green Stake ~ 4 Years Old - page 118. (Read 200997 times)

hero member
Activity: 595
Merit: 500
....But ALL of my ~80 PoS blocks was generated by inputs >= 20 ORBs only.
And no single PoS block for inputs < 20 ORBs.
I believe that I finally got one PoS block from a series of just over 10 ORB inputs, all around 20 days old (just over 150 weight).
I saw that with the current diff (0.003) that inputs around that weight start to stake, earlier diff was over 0.005 and I saw even 20 ORB inputs with weight of 190 still had not staked yet.
Initially diff was 0.0002 and inputs around 80-90 weight were staking reliably as soon as they got 9 days old.
Ghostlander, are inputs now able to stake after 5 days?
hero member
Activity: 894
Merit: 1001
I recompile 1.4.2 with dynamic link dll's. Do not know why - but it works: application run fine without previous errors, while statically linked throw errors right after startup.
Patch for staking and combining for small inputs begins working too.

Although with the current increase of PoS difficulty the probability of finding blocks for small input becoming low - after ~12 hours wallet could only create 2 PoS blocks by staking 35 small inputs (all with coin ages between 10 and 15 days, ~2500 weight total).
sr. member
Activity: 375
Merit: 250
wow!!!orbitcoins is funtastic by collecting any coin,this is really impressive...
legendary
Activity: 1239
Merit: 1020
No surrender, no retreat, no regret.
Yes, i re-download entire database from scratch after upgrading from 1.4.1 to 1.4.2. (BTW this time it was significantly faster ~ 8-9 hours instead of ~ 20 hours with 1.4.1 and i notice what it use second CPU core from time to time, not strict 1 core as was with 1.4.1. You already add partial multi-threading support?)

I have reduced message polling latency from conservative 100ms to fast 20ms and disabled the ACP checks during initial block chain downloads. Now orb-msghand thread processes data fast enough to keep up with orb-net thread supplying it.
hero member
Activity: 894
Merit: 1001
Yes, i re-download entire database from scratch after upgrading from 1.4.1 to 1.4.2. (BTW this time it was significantly faster ~ 8-9 hours instead of ~ 20 hours with 1.4.1 and i notice what it use second CPU core from time to time, not strict 1 core as was with 1.4.1. You already add partial multi-threading support?)

And your precompiled binary work fine on same computer (with same datafolder). This problem only if i compile myself from source...
Probable it somehow affected by fact what you configure 1.4.2 for static linking(just one .exe) while 1.4.1 was dynamically linked (with use of external .dll's)
I will try recompile 1.4.2 with dynamic linking to check if it change anything...
legendary
Activity: 1239
Merit: 1020
No surrender, no retreat, no regret.
Can you upload recompiled binaries with this last patch? Or may be better if someone tell what could be the cause of the error in my own compiled version:
I compile 1.4.1 myself and it work fine(and prev 1.3.0 and 1.3.2 OK too), but with 1.4.2 i am getting errors for some unknown reason (i use exactly same compiler and external libs only replace ORB source and libs included with it like levelDB).

I'll make one or two additional patches before releasing an update. Have you re-built the transaction data base after switching to v1.4.2.0 by bootstrapping or re-downloading? The old one lacks metadata needed by the new code, so it throws exceptions and crashes.
hero member
Activity: 894
Merit: 1001
If 1st vout is reserved then it is clear this check (txNew.vout.size() == 2) is a reason for small (<20) inputs not staking at all (at least until >20 days old).

if PPC not have any minimum stake requirements(and PoS reward is % of coins-days, not fixed), then I  understand why Sunny King made ​​such a check. It allow to "glue" only very small inputs. And "small" is dynamic criteria (based on current PoS difficulty and mining activity) not static limit. If input manages to generate PoS blocks before reaching max weight then it mean it is NOT very small. And if it exceed max coin age before generating PoS - then it is probable too small for current diff and better to combine few small inputs into larger one.

I thinks on ORB with fixed minimum stake amount and fixed PoS reward we not need this: because if program running this part of code then it mean we already know that  input is too small (<20 ORBs) and it needed to combine them. Otherwise it can not create PoS block in principle - no matter how long it tries, and will only waste CPU resources in futile attempts (generating PoS kernels but always fails at full blocks).
But your last patch should fix this too. (because all small input < 50 will have txNew.vout.size() == 2 not matter input coin age)

Can you upload recompiled binaries with this last patch? Or may be better if someone tell what could be the cause of the error in my own compiled version:
I compile 1.4.1 myself and it work fine(and prev 1.3.0 and 1.3.2 OK too), but with 1.4.2 i am getting errors for some unknown reason (i use exactly same compiler and external libs only replace ORB source and libs included with it like levelDB).
It compile OK but right after start and loading block database and wallet client produce such error:


Funny thing: despite this error message application in the background actually works just fine - responding to the network requests, downloads the new blocks, receives transaction, mining also works, etc.
But until clicking on the OK button - then immediately aborts/crash.
legendary
Activity: 1239
Merit: 1020
No surrender, no retreat, no regret.
The current code tries to combine inputs only if generating input is above split age (nStakeMinAge + nStakeMaxAge). It is the only condition when txNew.vout.size() == 2. The 1st vout is reserved always. vout.size() == 2 means one actual output. vout.size() == 3 means two actual outputs, i.e. stake split.

This patch fixes this issue as well as stake splits to amounts below the combining threshold. This kind of fragmentation isn't necessary. Inputs less than 50 ORB won't be halved. Works fine.


So i not understand why we need this check about 2 outputs?

This requirement comes from PPC. The reasons behind it are unclear, so you may want to ask Sunny King. Maybe he didn't want input combining to work our way, though PPC uses this feature very occasionally as there is no generation threshold. Even if a generating input is very small and there is nothing available to combine it with, a PoS block is produced still.
hero member
Activity: 894
Merit: 1001
Must be the same bug. It's one day left until the hard fork, not good to rush with additional changes. Even if it doesn't, we can fix it later without a hard fork.
If it can be fixed without hard fork then no need to rush of course.

I will check after 1.4.2 hard fork if it change anything but right now i am start thinking what coins additions for inputs <20 ORBs not working properly at all (even if PoS kernel and additional inputs both > 9 days old).
I monitor my primary large PoS mining wallet (~ 300 inputs now, ~ 5000 ORBs).
Last 3 days it produce PoS blocks fine and non stop. About 80 PoS blocks already mined, and generations now slowing down because wallet running out of inputs > 9 days old. (i expect new wave of PoS after hard fork when inputs 5-9 days old will start work too)

But ALL of my ~80 PoS blocks was generated by inputs >= 20 ORBs only.
And no single PoS block for inputs < 20 ORBs.
My wallet contains 35 inputs < 20 ORBs which is 3 - 18 ORBs in size each and 11 - 14 days old. Still not get a single PoS for them but logs shows lot of ERROR: CreateCoinStake() : stake amount below the minimum
This indicate what wallet keep finding PoS kernels but can not produce full PoS blocks based on inputs <20 ORBs.

Same situation with my other wallet running 24/7 on another machine where a LOT (~150 now) of 2 ORBs inputs (coins from PoW solo mined blocks) with age > 9 days at same address can not produce single PoS bock (and ERROR: CreateCoinStake() : stake amount below the minimum in logs too).

I check this part of source code myself but not found any errors:
Code:
    BOOST_FOREACH(PAIRTYPE(const CWalletTx*, unsigned int) pcoin, setCoins)
    {
        // Attempt to add more inputs
        // Only add coins of the same key/address as kernel
        if (txNew.vout.size() == 2 && ((pcoin.first->vout[pcoin.second].scriptPubKey == scriptPubKeyKernel || pcoin.first->vout[pcoin.second].scriptPubKey == txNew.vout[1].scriptPubKey))
            && pcoin.first->GetHash() != txNew.vin[0].prevout.hash)
        {
            int64 nTimeWeight = GetWeight((int64)pcoin.first->nTime, (int64)txNew.nTime);

            /* Do not add too many inputs */
            if(txNew.vin.size() >= 10)
              break;
            /* Do not add any inputs if above the threshold already */
            if(nCredit > nCombineThreshold)
              break;
            /* Do not add a new input exceeding the stake limit if defined */
            if(nCredit + pcoin.first->vout[pcoin.second].nValue > nBalance - nReserveBalance)
              break;
            /* Do not add any large inputs capable of stake generation on their own */
            if(pcoin.first->vout[pcoin.second].nValue > nCombineThreshold)
              continue;
            /* Do not add any inputs under the min. age */
            if(nTimeWeight < nStakeMinAge)
              continue;

            txNew.vin.push_back(CTxIn(pcoin.first->GetHash(), pcoin.second));
            nCredit += pcoin.first->vout[pcoin.second].nValue;
            vwtxPrev.push_back(pcoin.first);
        }
    }

    /* Fail if the minimal stake amount not reached */
    if(nCredit < MIN_STAKE_AMOUNT)
      return error("CreateCoinStake() : stake amount below the minimum");

All seems simple and correct for me except first check which i not fully understand (and if input not pass it it rejected)

 if (txNew.vout.size() == 2 && ((pcoin.first->vout[pcoin.second].scriptPubKey == scriptPubKeyKernel || pcoin.first->vout[pcoin.second].scriptPubKey == txNew.vout[1].scriptPubKey)) && pcoin.first->GetHash() != txNew.vin[0].prevout.hash)

txNew.vout.size() == 2 means what coins additions will work only for PoS blocks with 2 outputs? And why this restriction needed? 2 outputs in PoS block produced if block is splited (and blocks splits if input generates PoS blocks before reaching max stake age) so it will never work for old inputs?
Or if coins base also counted in txNew.vout.size() then it will work only for old (> max stake ages) inputs and NOT work for inputs < max stake age?
So i not understand why we need this check about 2 outputs?

P.S.
2 ALL
Although this problem looks insignificant at first sight, it actually important. Because now wallet while PoS mining splits PoS blocks into 2 parts (if block was found before input reach the maximum stake age = 20 days at the moment), over time in an actively used wallet this result ALL  inputs will be sliced to   pieces less than 20 ORBs (not matter how large it was at beginning - e.g. 150/2=75/2=37.5/2=18.75<20 after 3 rounds) and PoS mining will stop until the user manually glue/melt them back into larger pieces via coin control. That aside much time on boring and monotonous work also destroy all accumulated coin-days.
So an automated process that would gather them back into large pieces are very important for successful PoS realization
legendary
Activity: 2464
Merit: 3158


Hello everybody  Smiley
I am happy to introduce Altdice to the Orbitcoin community.
It's a provably fair dice game pretty much like Satoshi Dice.

http://orb.altdice.net

To play, choose your favorite odds and send a transaction to the associated address, with an amount anywhere from min bet to the max bet.
A Lucky number between 0 and 65535 will be picked up for you, based on your bet transaction ID.
If this Lucky number is below the target number of the game, then you win your bet amount * Prize Multiplier which is paid out directly to your wallet.
If you lose, you get 0.001 ORB back to your wallet.

The game requires 1 ORB confirmation to process a bet. 98% expected payout. 2% edge house.
Come and multiply your Orbitcoins ! You can win up to 100 ORBs.

Have a try :-)
Send any amount from 1 ORB to 88 ORB to oQ3S67KVQTdFTE49Fd6HURFm1XA4sdTdeq => This is the 85% chance of winning game address. It pays out x1.153 your bet amount automatically to your wallet if you win.

I wish players endless fun and the best of luck on http://orb.altdice.net Smiley

Feel free to send a PM or Contact Us on the website if anything.
legendary
Activity: 1239
Merit: 1020
No surrender, no retreat, no regret.
I notice what "bug" with coins actually start staking only after 9 days (instead of 5 days) apply not only to stake kernels but for additional inputs too.
e.g. if small (< 20 ORBs) but with relative hight weight(old coins) inputs generates PoS it search for other inputs to add up to >= 20 ORBs before can produce normal PoS blocks .
By design minimum age for such additional inputs is 5 days too. But in practice (in current v 1.4.1) it not work - wallet can use only old (~10 days or more) inputs for this. In situation when at same adress(key) lays smal old (10-15 days or more) inputs and larger younger(5-9 days) inputs  it produce error about stake amount below the minimum
It is a same bug and is this fixed in 1.4.2 ? If not i think is not too late to fix it before hardfork at #650000

Must be the same bug. It's one day left until the hard fork, not good to rush with additional changes. Even if it doesn't, we can fix it later without a hard fork.
hero member
Activity: 894
Merit: 1001
The block chain is not restarted. The initial support for pruned transactions appeared in v1.4.0.0 with the CCoins* class functions. It's extended now to actual data serialisation. Failed transactions are also detected and managed properly now. Incorrect interval of stake modifiers has been fixed finally, though this issue existed since the coin launch, but no one cared to find out why all coins are staking after 9 days instead of 5 days by design. There is enough time for every user to upgrade.


I notice what "bug" with coins actually start staking only after 9 days (instead of 5 days) apply not only to stake kernels but for additional inputs too.
e.g. if small (< 20 ORBs) but with relative hight weight(old coins) inputs generates PoS it search for other inputs to add up to >= 20 ORBs before can produce normal PoS blocks .
By design minimum age for such additional inputs is 5 days too. But in practice (in current v 1.4.1) it not work - wallet can use only old (~10 days or more) inputs for this. In situation when at same adress(key) lays smal old (10-15 days or more) inputs and larger younger(5-9 days) inputs  it produce error about stake amount below the minimum
It is a same bug and is this fixed in 1.4.2 ? If not i think is not too late to fix it before hardfork at #650000
legendary
Activity: 1239
Merit: 1020
No surrender, no retreat, no regret.
I meant that the local copy of the blockchain would need to be rebuilt from scratch.

Just concerned that there have been two versions requiring hard forks in such a short period. I missed the last hard fork by a few days so I had to reset/restart my local db.

A local copy of the block chain is the same (actual data in .orbitcoin/blocks and index in .orbitcoin/blktree). Metadata for future transaction pruning was added to transaction data base (.orbitcoin/coins) making it incompatible with the previous releases.


Quote
Are Cryptsy on board with the latest version?

Yes, they are.
legendary
Activity: 2268
Merit: 1092
I meant that the local copy of the blockchain would need to be rebuilt from scratch.

Just concerned that there have been two versions requiring hard forks in such a short period. I missed the last hard fork by a few days so I had to reset/restart my local db.

Are Cryptsy on board with the latest version?
legendary
Activity: 1239
Merit: 1020
No surrender, no retreat, no regret.
Orbitcoin v1.4.2.0 is available now. A hard fork at block #650K, many improvements. Please upgrade in time.

Due to changes to transaction data base, block chain re-download is necessary. Deploy your new client to a separate location and use bootstrap.dat or let it synchronise on its own.


So those who upgraded to v1.4.1.0 only two weeks ago need to upgrade again, plus restart the blockchain from scratch?  Undecided

The block chain is not restarted. The initial support for pruned transactions appeared in v1.4.0.0 with the CCoins* class functions. It's extended now to actual data serialisation. Failed transactions are also detected and managed properly now. Incorrect interval of stake modifiers has been fixed finally, though this issue existed since the coin launch, but no one cared to find out why all coins are staking after 9 days instead of 5 days by design. There is enough time for every user to upgrade.
legendary
Activity: 2268
Merit: 1092
Orbitcoin v1.4.2.0 is available now. A hard fork at block #650K, many improvements. Please upgrade in time.

Due to changes to transaction data base, block chain re-download is necessary. Deploy your new client to a separate location and use bootstrap.dat or let it synchronise on its own.


So those who upgraded to v1.4.1.0 only two weeks ago need to upgrade again, plus restart the blockchain from scratch?  Undecided
legendary
Activity: 1239
Merit: 1020
No surrender, no retreat, no regret.
Orbitcoin v1.4.2.0 is available now. A hard fork at block #650K, many improvements. Please upgrade in time.

Due to changes to transaction data base, block chain re-download is necessary. Deploy your new client to a separate location and use bootstrap.dat or let it synchronise on its own.
member
Activity: 82
Merit: 10
For a 100 ORB input getting 110 ORB within 10 days (according to our tests) is absolutely great.

In case anyone wants to mine the new PoS rewarding ORB, you're welcome to join us:

orb.smartmining.net

legendary
Activity: 1884
Merit: 1005
sr. member
Activity: 392
Merit: 250
So it's just as self-regulating process as with the usual PoW mining.

Oh, of course. I knew that PoS has its own difficulty to regulate the number of blocks generated, but I was in stupid mode. Apologies for my temporary brain fart.
Thx for changing that, mate!
Jump to: