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

[Lisa_Nelson]

Hey guys, I compiled the OrbitCoin daemon on my RPi 2, are you interested in the binary ?

I compiled it directly from Ghostlander's Github.

If anyone is interested, here is how to did it. It only covers the deamon compilation.

• Clone Ghostlander's repo
• Install/compile all the depndencies listed in doc/build.unix
• Edit makefile.unix to remove all -DASM occurences
• I also had to append -l snappy to the libs
• Then simply make it ! make -j3 -f makefile.unix

After about an hour, you'll get the daemon, ready to go. It's greener way to stake !

Good job! That info was posted on another forum thread at https://cryptocointalk.com/topic/38531-minor-problems-compiling-orb-wallet-on-non-x86-cpu-eg-raspberry-pi-odroid-c1/ along with some other useful hints (especially on the second page).
You got it working because you have double of the RAM amount I had (I suppose).
Congrats, anyway

I googled long time looking for someone else who did it and didn't find it

I've set up a 1GB swap partition, but I didn't try without though. That being said, orbitcoind uses almost 700MB RAM, so I doubt you can run the Qt client.

Yeah, the Qt client is a resource hog
Maybe my new Pine64+ (the 2GB RAM version) will accommodate it, though. I just need some spare time to un-box it

Yeah I guess it will ! I didn't knew the Pine64, it's very cheap !

[rmd73]

Hey guys, I compiled the OrbitCoin daemon on my RPi 2, are you interested in the binary ?

I compiled it directly from Ghostlander's Github.

If anyone is interested, here is how to did it. It only covers the deamon compilation.

• Clone Ghostlander's repo
• Install/compile all the depndencies listed in doc/build.unix
• Edit makefile.unix to remove all -DASM occurences
• I also had to append -l snappy to the libs
• Then simply make it ! make -j3 -f makefile.unix

After about an hour, you'll get the daemon, ready to go. It's greener way to stake !

Good job! That info was posted on another forum thread at https://cryptocointalk.com/topic/38531-minor-problems-compiling-orb-wallet-on-non-x86-cpu-eg-raspberry-pi-odroid-c1/ along with some other useful hints (especially on the second page).
You got it working because you have double of the RAM amount I had (I suppose).
Congrats, anyway

I googled long time looking for someone else who did it and didn't find it

I've set up a 1GB swap partition, but I didn't try without though. That being said, orbitcoind uses almost 700MB RAM, so I doubt you can run the Qt client.

Yeah, the Qt client is a resource hog
Maybe my new Pine64+ (the 2GB RAM version) will accommodate it, though. I just need some spare time to un-box it

Yeah I guess it will ! I didn't knew the Pine64, it's very cheap !

See https://bitcointalk.org/index.php?topic=1084908.msg15446329#msg15446329 also

[TvZ]

Orbitcoin block reward halving from block 2M!
We're now at block 1878674 and counting...
Be smart, buy some ORB, let your ORB stake, take advantage.
Long term investment in Orbitcoin is a good investment.

Please open port 15298 at your firewall/router for more and
faster connections, this also helps the Orbitcoin network!

 

[ghostlander]

With our block reward halving down from 1 ORB to 0.5 ORB in 100K+ blocks, there is an option for the block chain optimisation. We can increase the block time from 1 minute to 2 minutes and keep the current block reward for the next 500K blocks until another halving.

The point is to decrease bloat of the block chain and block index. Many (maybe most) blocks are without user transactions right now. Yet they contribute to the block chain size. What's more important, every block in the chain requires a corresponding entry in the block index. A couple hundred bytes each. It's kept in memory for fast access. In fact, most of the daemon's ~700Mb memory consumption comes from the block index. See yourself how much space is consumed by those *.sst and *.ldb files under data/blktree. Our UTXO data base is fairly compact and may be left as it is for now. The block index can be optimised to some extent, but it's much better to make it grow slower.

[rmd73]

With our block reward halving down from 1 ORB to 0.5 ORB in 100K+ blocks, there is an option for the block chain optimisation. We can increase the block time from 1 minute to 2 minutes and keep the current block reward for the next 500K blocks until another halving.

The point is to decrease bloat of the block chain and block index. Many (maybe most) blocks are without user transactions right now. Yet they contribute to the block chain size. What's more important, every block in the chain requires a corresponding entry in the block index. A couple hundred bytes each. It's kept in memory for fast access. In fact, most of the daemon's ~700Mb memory consumption comes from the block index. See yourself how much space is consumed by those *.sst and *.ldb files under data/blktree. Our UTXO data base is fairly compact and may be left as it is for now. The block index can be optimised to some extent, but it's much better to make it grow slower.

As "many (maybe most) blocks are without user transactions", the block time increase seems to be better. I'd vote in favor of that optimization.

[Mario241077]

our blockexplorer is not working?


this works http://cryptoguru.tk/Blocks/index.php?Currency=ORB

[Mario241077]

With our block reward halving down from 1 ORB to 0.5 ORB in 100K+ blocks, there is an option for the block chain optimisation. We can increase the block time from 1 minute to 2 minutes and keep the current block reward for the next 500K blocks until another halving.

The point is to decrease bloat of the block chain and block index. Many (maybe most) blocks are without user transactions right now. Yet they contribute to the block chain size. What's more important, every block in the chain requires a corresponding entry in the block index. A couple hundred bytes each. It's kept in memory for fast access. In fact, most of the daemon's ~700Mb memory consumption comes from the block index. See yourself how much space is consumed by those *.sst and *.ldb files under data/blktree. Our UTXO data base is fairly compact and may be left as it is for now. The block index can be optimised to some extent, but it's much better to make it grow slower.

do it

[TvZ]

I agree with every optimization that is good for Orbitcoin 

[bittamak]

Yes...memory consumption is one major issue...please fix that which is good...

[Mario241077]

maybe is ORB ready for break out?


support
BTC                         ORB
0.0005    0.0005    7.15867015 0.00007012
0.0010    0.0005    7.11497825 0.00007010
0.3568    0.3558    5082.12016283 0.00007001
3.2770    2.9202    41716.53162633 0.00007000
3.2779    0.0009    13.65000000 0.00006938
3.2789    0.0010    14.50000000 0.00006918
3.4505    0.1716    2500.00000000 0.00006862

sell only this
19740.427 ORB

[Mario241077]

want we support to?


ORB is supported by charnasolution

Charna Wallet ‏@CharnaSolutions 18. Mai

Charna wallet/charnacoin now supporting @ubiquityenergy order directly online using #crypto #chc @BitcoinWrld @Orbitcoin @PotCoinBot


 Ubiquity Energy
@ubiquityenergy

Free Solar Panels for Residential, Commercial municipalities. Projects in Panama, Puerto Rico, Philippines, Peru, and Brazil. Supported by @charna_coin

[Mario241077]

Ghost you showcase your

http://cryptomining-blog.com/8100-windows-binaries-for-the-cpuminer-opt-3-3-7-cpu-miner/

[bigs21024]

this is a good coin i was hacked and lost 56k of them i so wish i had them back along with everything else that was taken i hate theifes

[Mario241077]

this is a good coin i was hacked and lost 56k of them i so wish i had them back along with everything else that was taken i hate theifes

when?

[TvZ]

@bigs21024

That's sad to hear 

[ghostlander]

our blockexplorer is not working?


this works http://cryptoguru.tk/Blocks/index.php?Currency=ORB

VPS moved from New York to Virginia. There was a firewall misconfiguration which made our block explorer inaccessible for a day.

[ghostlander]

Ghost you showcase your

http://cryptomining-blog.com/8100-windows-binaries-for-the-cpuminer-opt-3-3-7-cpu-miner/

The NeoScrypt CPUminer is assembly powered. Any C compiler cannot make it faster. There was a quick attempt to add AVX in the past, but SSE2 4-way was faster anyway. Most people don't seem to care about the CPU miner, so I pay more attention to NSGminer.

[Mario241077]

crash Euro, DOW, DAX, TRY http://www.ig.com/de/ig-forex/usd-try

Military Coup: Turkish Armed Forces Say They Have Taken Control Of The Country
http://www.zerohedge.com/news/2016-07-15/martial-law-declared-turkey-helicopters-military-jets-flying-over-capital-army-tanks





http://de.coinmill.com/BTC_TRY.html?TRY=100#TRY

[bitmaster1x]

this is a good coin i was hacked and lost 56k of them i so wish i had them back along with everything else that was taken i hate theifes

Bummer dude

[almightyruler]

Good job! That info was posted on another forum thread at https://cryptocointalk.com/topic/38531-minor-problems-compiling-orb-wallet-on-non-x86-cpu-eg-raspberry-pi-odroid-c1/ along with some other useful hints (especially on the second page).
You got it working because you have double of the RAM amount I had (I suppose).
Congrats, anyway

I'm the OP of that thread.

As per that thread I gave up on ORB because an Odroid C1 with 1GB of RAM was insufficient (it would end up swapping like crazy - storage and CPU far too busy), plus it was randomly segfaulting.

I've now come back to it with an Odroid C2, which uses a 64 bit ARM CPU, with 2GB RAM. Not a single crash, and there's enough room for a couple more coin daemons, too.

ORB: 2162M virt, 723M res
COIN2: 2035 virt, 559M res
COIN3: 1017M virt, 344M res

Free memory: 257M

It has been running for 24 days stable, and has staked a couple of times.

I've also installed zram on the C2, which presents a swap device that compresses data, keeping it in RAM rather than swapping to disk if possible. If Raspbian supports it (and it is not already enabled by default) this should make a noticeable difference in available RAM on a 1GB Pi 3.  sudo apt-get install zram-config