[ANN] Orbitcoin v1.6.3.0 ~ NeoScrypt ~ Green Stake ~ 10 Years Old

[ghostlander]

 
Orbitcoin v1.6.3.0
 
 
(9-Jan-2022)
 

 
 


64-bit Windows GUI client
 
 

 
64-bit Linux GUI client & daemon
 
 

 
64-bit MacOS X (10.5+) GUI client
 
 


Source code
 
 
Block chain data for rapid deployment:

.orbitcoin.tar.gz (3350470 blocks, 05-Jan-2022, 1834Mb)
 md5sum (.orbitcoin.tar.gz) = 788109e1595e7b7beccca85b06414d61
 
 (for Windows users, rename extracted .orbitcoin to data)
 


NeoScrypt CPU and GPU miners

CPUminer (source code and binaries)

CUDAminer (source code and binaries)

NSGminer (source code and binaries)

NSGminer: The Fastest NeoScrypt GPU Miner


 
Specifications

advanced hybrid proof-of-work (PoW) and proof-of-stake (PoS)
fixed rate of 33% PoW blocks and 67% PoS blocks
3.92 million coins to be produced

block hashing is BLAKE2s
PoW hashing is NeoScrypt
PoS hashing is SHA-256d

2 minutes combined block target (6 minutes for PoW, 3 minutes for PoS)
retargets every block using Orbitcoin Super Shield (OSS)
time warp and instamining protection
advanced checkpointing against 51% attacks
transaction messaging supported
the 1st implementation of 0% PoS
PoW and PoS blocks carry the same fixed reward of 0.125 ORB
coin age for PoS: 1 day min. to 16 days max.
6 confirmations for regular transactions
200 confirmations for minted coins
very low transaction fees (most transactions are free)
no destruction of transaction fees (all collected by a block finder)
the default P2P port is 15298, RPC port is 15299
I2P/Tor ready


Example orbitcoin.conf

irc=1
dns=1
qtstyle=2
daemon=1
server=1
stakegen=1
logtimestamps=1
minersleep=2000
stakemintime=72
stakecombine=50
stakesplit=100
stakefence=360
port=15298
rpcport=15299
rpcuser=someuser
rpcpassword=somepassword
addnode=seed0.orbitcoin.org:15298
addnode=seed1.orbitcoin.org:15298

Some FAQ on staking

Block reward and optimal stake size


Merchants & Services

CoinToPay.com



 
Twitter
 
 

 
Facebook


Web Site


Block Explorer


Exchanges

FreiExchange (ORB/BTC)
Unnamed Exchange (ORB/BTC)
 
 
Advancement Fund
 
Our advancement fund is for Orbitcoin promotion and development actions approved by the community.
It's a public ledger with all transactions visible. It's a secure cold wallet.
You can also contribute to the fund if you please.
 
oRBBYYiaQ6Kw5fhf2b9YiT86HmynCBsoej
 
 
Orbitcoin is one of the oldest PoW / PoS altcoins launched on the 30th of July 2013 at Cryptocointalk!
 
 

[1695675618]

1695675618

[1695675618]

1695675618

[1695675618]

1695675618

[1695675618]

1695675618

[1695675618]

1695675618

[1695675618]

1695675618

[bushstar]

To the rescue again I see

I really hope that people appreciate your improvements to PoS and the contributions this brings. Perhaps you should write a short paper on the short comings of the original PoS and explain the work you have done here?

I'm mining Orb but if anyone has 0.5 Bitcoins worth then please send me a PM.

[almightyruler]

I've been thinking about a coin with fixed reward PoS for a while (...it's probably already been done...)

Are PoS minted blocks also eligible to generate further PoS themselves once they've matured sufficiently? If so, surely there would be issues with exponential runaway? If you start with 1 ORB then do nothing, after 30 days (or whatever) it will PoS mint an additional 1 ORB, so your balance is now 2 ORB; after 30 more days, you will PoS mint an additional 2 x 1 ORB, so you now have 4 ORB, and so on. In a year your 1 ORB will grow to 4096 ORB, at the end of 2 years it will be 16 million.

This can't be right. So is there some code to prevent PoS funds minting more PoS blocks?

[almightyruler]

Couple of patches to allow Orbitcoin to compile cleanly on FreeBSD:

util.cpp (in function LogStackTrace) :

Code:

1000c1000
< #ifndef WIN32
---
> #if !defined(WIN32) && !defined(__FreeBSD__)

Copy makefile.unix to makefile.freebsd, then patch:

Code:

15a16,21
> BOOST_INCLUDE_PATH=/usr/local/include
> BDB_INCLUDE_PATH=/usr/local/include/db48
> BOOST_LIB_PATH=/usr/local/lib
> BDB_LIB_PATH=/usr/local/lib/db48
> OPENSSL_INCLUDE_PATH=/usr/local/lib
>
51d56
<    -l dl \
62c67
< xCXXFLAGS=-O2 -fomit-frame-pointer -fno-stack-protector $(EXT_OPTIONS) -pthread -Wall -Wextra -Wno-ignored-qualifiers -Wformat -Wformat-security -Wno-unused-parameter \
---
> xCXXFLAGS=-O2 -fomit-frame-pointer -fno-stack-protector $(EXT_OPTIONS) -pthread -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter \
113c118
<       @echo "Building LevelDB ..."; cd leveldb; make libleveldb.a libmemenv.a; cd ..;
---
>       @echo "Building LevelDB ..."; cd leveldb; gmake libleveldb.a libmemenv.a; cd ..;

[Mad_Max]

I've been thinking about a coin with fixed reward PoS for a while (...it's probably already been done...)

Are PoS minted blocks also eligible to generate further PoS themselves once they've matured sufficiently? If so, surely there would be issues with exponential runaway? If you start with 1 ORB then do nothing, after 30 days (or whatever) it will PoS mint an additional 1 ORB, so your balance is now 2 ORB; after 30 more days, you will PoS mint an additional 2 x 1 ORB, so you now have 4 ORB, and so on. In a year your 1 ORB will grow to 4096 ORB, at the end of 2 years it will be 16 million.

This can't be right. So is there some code to prevent PoS funds minting more PoS blocks?

No any "exponential runaway". If many people (more than needed to generate the target number of PoS blocks) will do so it  just rise PoS difficulty up while keeping amount of PoS blocks (and coins productions via PoS) at same level. (= each person running PoS will get less coins)
And with high PoS diff it is better(=greater probability of finding the block) to have in wallet few relative large incoming transactions vs very many small transactions.

So it's just as self-regulating process as with the usual PoW mining.

Plus i thinks you miss this: "The minimum amount to generate a PoS block is 20 ORB."
So just one PoS block is not enough to generate another PoS block even now (at very low PoS diff) only if stack few PoS blocks up to 20 ORBs at same address.

[almightyruler]

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.

[loveyou]

well done

good job.....

[Raxe.io]

If there is any development you guys need please contact us, here is our portfolio so far:

epawncoin Website: http://epawncoin.com

epawncoin Wallet: http://wallet.epawncoin.com/

epawncoin Android Application: https://play.google.com/store/apps/details?id=com.epawncoin.wallet

kimdotcoin Wallet: http://kimdotcoin.co.nz/

Kimdotcoin Android App: https://play.google.com/store/apps/details?id=com.raxe.kimdotcoin

Compasscoin Wallet: http://wallet.compasscoin.org

Compasscoin Android App: https://play.google.com/store/apps/details?id=com.compasscoin.wallet

STLCoin Wallet: http://wallet.stlcoin.org/#/

STLCoin Android App: https://play.google.com/store/apps/details?id=com.stlcoin.wallet

Epawncoin Exchange: http://coinpod.net


If you have any questions please do not hesitate to contact us:

https://twitter.com/RaxeSoftware
contact@raxe.io
Skype: raxe.io (Raxe.io Support)

[platorin]

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!

[ChekaZ]

Pool: www.orb.chekazpools.com

Regards,
ChekaZ

[smartmining]

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

[ghostlander]

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.

[almightyruler]

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? 

[ghostlander]

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? 

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.

[almightyruler]

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?

[ghostlander]

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.

Are Cryptsy on board with the latest version?

Yes, they are.

[Mad_Max]

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

[ghostlander]

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.

[yogg]

Hello everybody 
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

Feel free to send a PM or Contact Us on the website if anything.

[Mad_Max]

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