Pages:
Author

Topic: remove thread - page 7. (Read 31237 times)

hero member
Activity: 894
Merit: 1001
January 04, 2014, 04:47:23 AM
Very tired now so I'm having a quick look and trying to understand the problem. Is it as simple as the time of two adjacent blocks being out of sequence, the more recent one having an older time, resulting in a negative number when calculating the last time period?

Code:
31-Dec-2013 13:56:33 height: 411227 mint: 0.25 difficulty: 0.17286038 flags: proof-of-work
31-Dec-2013 14:56:05 height: 411228 mint: 0.25 difficulty: 0.17353002 flags: proof-of-work
31-Dec-2013 13:58:21 height: 411229 mint: 0.25 difficulty: 0.05879355 flags: proof-of-work
31-Dec-2013 14:07:36 height: 411230 mint: 0 difficulty: 0.00024414 flags: proof-of-stake

So somehow a block which based on timestamp should have been around #411235 ended up in the blockchain at #41228. The next block was the final PoW one.

That's enough to cause the network to get stuck?

I can see the same thing happened to CDC earlier this morning.

Is this a hard fork where EVERYONE will need to update their client in order to mine, or will it be sufficient for the majority of the network to update?
Yes - wrong timestamps of blocks - is a part of conditions to trigger bug. But PoS involved too - of no PoS blocks mined at same time - wrong PoW blocks will be just orphaned and situation selfcorrected after some time (few hours MAX). But with PoS block at same time (and without full check in PoS gen code) wrong PoW blocks are sealed in the blockchain and can not be orphaned by PoW miner (it can be orphaned by other PoS miners but they do not do so as PoS code does not see any problem in such blocks and regard them as valid)

About fork. Actually we have 2 options:
fork from 411227 block then only majority of miners(PoS miners mainly)  need to update. After miners with updated client build longes chain (compared to stuck one) on all other(not updated) clients all blocks after 411227 will be orphaned and replaced by new chain without invalid blocks automatically. Without any soft updates.
And my first patch was this version - i just BAN (blacklist) block 411228 and rebuild blockchain - PoW mining start normal working from 411227 block.
But later I refused this option - because it creating a large number of orphan PoS blocks (which can include some real important transaction for the last 5-6 days) + this variant need a large number of PoS miners with large amounts of coins in stack to quickly generate at least 400-500 PoS blocks and overtake the current chain + this NOT prevent such bugs again in future.

In second patch i remove block ban and add simple check for negative time spacing. No need to orphan current blockchain, but all will need to update because old clients not accept blocks from new (even if it from longest chain). If not all update clients it will lead to blockchain fork to 2 parallel chains.
So it is some sort of hardfork now...
legendary
Activity: 2268
Merit: 1092
January 04, 2014, 04:43:20 AM
Does look like a hard fork - everyone will have to adopt the fix. Sad Don't hold much hope, over in the Stablecoin thread there have been about 4 new releases over the past 6 months, some peers are still running the original client!
newbie
Activity: 42
Merit: 0
January 04, 2014, 03:41:07 AM
ORB THREAD TO REMOVE WTF?


[ANN] Orbitcoin (ORB) Official Release Thread - Scientific POW/POS Adv. Hybrid
legendary
Activity: 2268
Merit: 1092
January 04, 2014, 03:37:08 AM
Very tired now so I'm having a quick look and trying to understand the problem. Is it as simple as the time of two adjacent blocks being out of sequence, the more recent one having an older time, resulting in a negative number when calculating the last time period?

Code:
31-Dec-2013 13:56:33 height: 411227 mint: 0.25 difficulty: 0.17286038 flags: proof-of-work
31-Dec-2013 14:56:05 height: 411228 mint: 0.25 difficulty: 0.17353002 flags: proof-of-work
31-Dec-2013 13:58:21 height: 411229 mint: 0.25 difficulty: 0.05879355 flags: proof-of-work
31-Dec-2013 14:07:36 height: 411230 mint: 0 difficulty: 0.00024414 flags: proof-of-stake

So somehow a block which based on timestamp should have been around #411235 ended up in the blockchain at #41228. The next block was the final PoW one.

That's enough to cause the network to get stuck?

I can see the same thing happened to CDC earlier this morning.

Is this a hard fork where EVERYONE will need to update their client in order to mine, or will it be sufficient for the majority of the network to update?
hero member
Activity: 894
Merit: 1001
January 04, 2014, 02:48:53 AM
Will do full github fork later.
But main (only necessary) patch is very simple. You can do it youself:
just open src/main.cpp find this function: unsigned int static GetNextTargetRequired

and add code:
Quote
int64 nActualSpacing = pindexPrev->GetBlockTime() - pindexPrevPrev->GetBlockTime();

    if (nBestHeight >= 411228 && nActualSpacing < 0) nActualSpacing = 0; // patch to prevent negative nActualSpacing
And compile. If you can connect to my node and sync to ~412100 blocks(>19 billion trust score) or more - you do all right  Wink
Bacup wallet.dat ofcourse before try.

I make few other minor updates (like protocol and client version info update) - but they all are optional.

411228 - is last normal block before PoW is broken. Initially i think we need fork blockchain from it... But i try start mining from latest PoS block - and it works too.
So no need to orphan last ~300 PoS bloks  Smiley (it may include some real transactions)
legendary
Activity: 2268
Merit: 1092
January 04, 2014, 01:50:47 AM
Very interested to see the code changes - I'm using *nix so need to compile from source Smiley

BTW, overnight CloudCoin went into "locked" mode, just like ORB, only PoS blocks make it into the network now. Mining doesn't work at all.

I believe AndroidTokens (ADT) is also having the same problem.
hero member
Activity: 894
Merit: 1001
January 04, 2014, 01:27:21 AM
YES - it is not OrbitCoin exclusive bug. It was inherited from the previous forks.
Just need some rare confluence of conditions for its manifestation.

Bay the way. After of few days of compiling and debugging i finaly patch code and successfully compile/build it under Windows!
My small patch is working - i can mining (PoW) normal now. (I am at 411847 block already - started from current last PoW block 411577 )
But all need to apply this patch or network will be forked. (2 exchanges and block explorer - most important part)

Here is my new (1.2.1) version of OrbitCoin client:
Windows binary: http://yadi.sk/d/8BiaEltqFR844

For those who want to see the all changes in code and try to compile yourself i will try make fork on GitHub (although I have never done that yet, and even there is not registered)

P.S.
To all - do NOT make any transaction now - until it is not clear which of the forks win.
legendary
Activity: 2268
Merit: 1092
January 03, 2014, 09:06:45 AM
2 almightyruler
No this changes activates only after 1051200 (1 mil) blocks.

Right, I understand the code now, in the original nSubsidy was shifted zero bits (no change) until after block #1051200. The code rewrite makes it clearer.

But now we at ~410k blocks only. Some bugs it in POS realisation part (Inherited from BitBar/YAcoin or even from NovaCoin or PPCcoin - not sure ORB was forked from, some sight in code point to NovaCoin, but may be fork of the fork of fork...) - sometimes (in some rare situations) POS produce buggy(incorrect) block but it pass check and not rejected/orphaned but included in blockchain.
After this monent all other PoW bloks will be regarded as invalid and rejected - only PoS accepted.

This sounds a little what has happened to CloudCoin (CDC). In that case, PoW blocks are being generated by miners, but the network is reversing most of them within a few minutes. Looks like ORB is not accepting PoW blocks at all though.

For comparison, last 24 hours in the blockchain...

CDC: 1399 PoS blocks, 0 PoW
ORB: 48 PoS blocks, 0 PoW

Both coins broken.

Are a lot of other derived coins with the same bugs going to start failing?  Huh  Lips sealed
hero member
Activity: 894
Merit: 1001
January 03, 2014, 12:03:36 AM
2 almightyruler
No this changes activates only after 1051200 (1 mil) blocks. But now we at ~410k blocks only. Some bugs it in POS realisation part (Inherited from BitBar/YAcoin or even from NovaCoin or PPCcoin - not sure ORB was forked from, some sight in code point to NovaCoin, but may be fork of the fork of fork...) - sometimes (in some rare situations) POS produce buggy(incorrect) block but it pass check and not rejected/orphaned but included in blockchain.
After this monent all other PoW bloks will be regarded as invalid and rejected - only PoS accepted.
 

P.S.
After many hours I could finally build it under windows. But now it crash just after start...
Will try recompile QT itself + boost from source next time before  compile client. But it so looong and slow...
legendary
Activity: 2268
Merit: 1092
January 02, 2014, 07:21:20 PM
I think i can temporaly fix network (it is a buggy code, although the original developer thinks that this some kind of attack on network and conspiracy against him  Grin  Grin ).

Would the network stalling be anything to do with the reward change? Won't that affect validating blocks if the network is split between old and new code?

orbitcoin 1.0
Code:
       int64 nSubsidy = 0.25 * COIN;

        if(nHeight < 11)
        {
                nSubsidy = 100000 * COIN;
        }

        nSubsidy >>= (nHeight / 1051200);

orbitcoin 1.2
Code:
       int64 nSubsidy = 0.25 * COIN;

        if(nHeight < 11){nSubsidy = 100000 * COIN;}
        else if (nHeight > 1051200){nSubsidy = 0.25 * COIN;}
        else if (nHeight > 2102400){nSubsidy = 0.125 * COIN;}
        else if (nHeight > 3153600){nSubsidy = 0.0625 * COIN;}
        else if (nHeight > 4204800){nSubsidy = 0.03125 * COIN;}
        else if (nHeight > 5256000){nSubsidy = 0.015625 * COIN;}
        else if (nHeight > 3994560000){nSubsidy = 0 * COIN;}       ********

******** g++ complains "warning: comparison is always false due to limited range of data type" about the last conditional, which I guess means the client will keep generating coins forever. Cheesy


======

This is what debug.log says when my miner submits a found block. I'm not that familiar with the code but I guess it could mean there's an issue with the difficulty calculation. Miner is finding block at supplied difficulty, client rejects PoW as it's the wrong difficulty?

Code:
BitcoinMiner:
new block found
  hash: 0000000a0cd72247dfb722bfb8e594367038b1c1c4733ae288c45a9631b4a592
target: 0000000fd7140000000000000000000000000000000000000000000000000000
CBlock(hash=0000000a0cd72247dfb722bfb8e594367038b1c1c4733ae288c45a9631b4a592, ver=4, hashPrevBlock=a85d39f3db0d3648e91f1a8d631fe863104d891432625b77dbff65f5f1e29c7b, hashMerkleRoot=1651473609dd90780cdf0fdca9925d51fb81d4cfb486e7fcd3fdd08a6857a263, nTime=1388708165, nBits=1d8fd714, nNonce=2906194432, vtx=1, vchBlockSig=3046022100fdf6c348fc7f909754e30ee88c3484b1e7d9b3d84570592e39d6991b1c5666a3022100e339281ed4efb86ac9097bd4801b7cc1608f6fb986772f80c16307b70b480908)
  Coinbase(hash=1651473609, nTime=1388706796, ver=2, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 036e4706025209062f503253482f)
    CTxOut(nValue=0.25, scriptPubKey=03d5548c59fc86215680f1f6e645e8aa6e22a719503129a268327acc1cd7f976df OP_CHECKSIG)
  vMerkleTree: 1651473609
generated 0.25
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
ERROR: BitcoinMiner : ProcessBlock, block not accepted

BTW I am able to compile the source, but I'm only using the headless daemon under *nix.
hero member
Activity: 894
Merit: 1001
January 02, 2014, 06:04:30 PM
No working pools and solomine not work too (at all = 100% rejects). 5th day now
Although transactions are still going through - but only at the rare POS blocks. (if there was no POS generation network would already be dead)

I think i can temporaly fix network (it is a buggy code, although the original developer thinks that this some kind of attack on network and conspiracy against him  Grin  Grin ).
But i even cannot compile it from sourse:
on the official site only binary files.
And source at https://github.com/Orbitcoin/Orbitcoin not compile - lot of random errors (wrong path, wrong includes, wrong functions call from libs etc). Think it is not same version from which it was current binaries for windows created...


I Try
both console deamon and full GUI QT wallet.
MinGW 4.8.1
QT 4.8.5
boost (source of majority of problems at compiling) boost_1_43, boost_1_50 / boost_1_53 / boost_1_55
db-4.8.30.NC
openssl-1.0.1
sr. member
Activity: 308
Merit: 250
January 02, 2014, 02:40:20 PM
are there any wallet or pool alive?
legendary
Activity: 1946
Merit: 1005
My mule don't like people laughing
January 02, 2014, 07:20:16 AM
What happened to this coin?
newbie
Activity: 2
Merit: 0
December 31, 2013, 03:38:33 PM
Re-launching my Orbitcoin pool as per request of acckiller. Lets bring this coin alive again Smiley

http://orb.nordicminers.eu

1% fee, proportional payouts and no delays in payouts. 0% Fee during the holidays. Merry X-mas!
I just jumped in the deep end with 600 kh/s.  I've been a fan of your pools.
Does this pool work?
Code:

Round Shares Submitted shares since last found block (ie. round shares)
Est. Shares 241 (done: 111608.71%)
Pool Valid 268977
Your Valid 3642
Pool Invalid 508
Your Invalid 5

Left it on overnight and still 0 confirmed 0 unconfirmed
member
Activity: 75
Merit: 10
December 26, 2013, 12:24:18 PM
Re-launching my Orbitcoin pool as per request of acckiller. Lets bring this coin alive again Smiley

http://orb.nordicminers.eu

1% fee, proportional payouts and no delays in payouts. 0% Fee during the holidays. Merry X-mas!
I just jumped in the deep end with 600 kh/s.  I've been a fan of your pools.
newbie
Activity: 51
Merit: 0
December 23, 2013, 07:07:34 PM
Re-launching my Orbitcoin pool as per request of acckiller. Lets bring this coin alive again Smiley

http://orb.nordicminers.eu

1% fee, proportional payouts and no delays in payouts. 0% Fee during the holidays. Merry X-mas!
sr. member
Activity: 966
Merit: 250
December 17, 2013, 09:21:20 AM
Avg Profitability Past 7 Days: 1 727,64%

Current price in cryptsy: 0.00144872 BTC

Difficulty: 0.32056
legendary
Activity: 2268
Merit: 1092
December 16, 2013, 10:28:49 PM
orbitcoind grabs a heap of CPU for some reason. A basic RPC call like 'getinfo' can take 10 to 20 seconds to respond.

The server itself is not at 100% load.

No change with the newer 1.2 version. It's still a CPU hog, even when it's synced and there are no blocks to verify for a minute or two. It seems to be stuck in a loop doing SOMETHING. Any ideas?
sr. member
Activity: 966
Merit: 250
December 16, 2013, 10:42:34 AM
Avg Profitability Past 7 Days: 1 451,50%

Current price in cryptsy: 0.00140000 BTC

Difficulty: 0.30418

Pointing miners Smiley
hero member
Activity: 924
Merit: 1005
Product Marketing & Promotion / Software Developer
December 16, 2013, 05:32:44 AM
With the spelling and lots of other interesting things on their website, I don't think Orbit.
Pages:
Jump to: