[JBS] Jumbucks - No IPO/ICO - Proof of Stake - Slack - DCR Stake Pool - 2+ Years

[BoscoMurray]

thanks for the regular updates jyap. they are appreciated.

[jyap]

New difficulty adjustment algorithm update

I'm currently working on porting the Digishield v3 difficulty adjustment algorithm to an Ethereum code base. Need to port some additional functions from Bitcoin over such as BIP 113 "Median time-past as endpoint for lock-time calculations" https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki

This is a pretty standard and "safe" difficulty algorithm as it has a fixed up and down adjustment percentage and mostly works based on time and difficulty medians.

This algorithm was also chosen for Zcash after they evaluated a few options.

Ported over BIP 113 tonight. Looks to be working well.  Hopefully I can finish the the diff algo shortly and have a new Alpha network up and running very soon.  I'll be running some tests of adding and removing hash to see how the difficulty compensates. I'll probably try and simulate some 51% attacks too to see where the potential weaknesses are.

Git commit

Code:

$ git show
commit 6838ff79025fb31c83ed9940cf22e8bc56448532
Date:   Sun Sep 4 00:50:45 2016 -1000

    Implement CalcPastMedianTime

Log lines for testing

Code:

I0904 00:46:38.012788 core/block_validator.go:347] parent block: 14191, bigTime: 1472985286, bigParentTime: 1472985197, medianTime bigTime: 1472984245
I0904 00:46:38.013697 core/blockchain.go:523] Block 14192 Time: 1472985286
I0904 00:46:38.013732 core/blockchain.go:523] Block 14191 Time: 1472985197
I0904 00:46:38.013748 core/blockchain.go:523] Block 14190 Time: 1472984716
I0904 00:46:38.013761 core/blockchain.go:523] Block 14189 Time: 1472984595
I0904 00:46:38.013775 core/blockchain.go:523] Block 14188 Time: 1472984531
I0904 00:46:38.013792 core/blockchain.go:523] Block 14187 Time: 1472984249
I0904 00:46:38.013804 core/blockchain.go:523] Block 14186 Time: 1472984245
I0904 00:46:38.013817 core/blockchain.go:523] Block 14185 Time: 1472984158
I0904 00:46:38.013833 core/blockchain.go:523] Block 14184 Time: 1472984013
I0904 00:46:38.013845 core/blockchain.go:523] Block 14183 Time: 1472983959
I0904 00:46:38.013859 core/blockchain.go:523] Block 14182 Time: 1472983651
I0904 00:46:38.013875 core/block_validator.go:347] parent block: 14192, bigTime: 1472985345, bigParentTime: 1472985286, medianTime bigTime: 1472984249
I0904 00:46:38.014785 core/blockchain.go:523] Block 14193 Time: 1472985345
I0904 00:46:38.014823 core/blockchain.go:523] Block 14192 Time: 1472985286
I0904 00:46:38.014835 core/blockchain.go:523] Block 14191 Time: 1472985197
I0904 00:46:38.014846 core/blockchain.go:523] Block 14190 Time: 1472984716
I0904 00:46:38.014856 core/blockchain.go:523] Block 14189 Time: 1472984595
I0904 00:46:38.014867 core/blockchain.go:523] Block 14188 Time: 1472984531
I0904 00:46:38.014878 core/blockchain.go:523] Block 14187 Time: 1472984249
I0904 00:46:38.014888 core/blockchain.go:523] Block 14186 Time: 1472984245
I0904 00:46:38.014903 core/blockchain.go:523] Block 14185 Time: 1472984158
I0904 00:46:38.014914 core/blockchain.go:523] Block 14184 Time: 1472984013
I0904 00:46:38.014924 core/blockchain.go:523] Block 14183 Time: 1472983959

[jyap]

Round 8 - Decred stake pool payments made

8.255 DCR sold for 0.0200081 BTC
203.82203886 JBS bought for 0.02000791 BTC

Sign up today at: http://dcrstakepool.getjumbucks.com

If you require assistance with getting started at the pool, we are always happy to help in Jumbucks Slack.

Sign up to Jumbucks Slack to be a part of a growing community of over 610 crypto enthusiasts and Jumbucks fans!

[jyap]

New difficulty adjustment algorithm update

I'm currently working on porting the Digishield v3 difficulty adjustment algorithm to an Ethereum code base. Need to port some additional functions from Bitcoin over such as BIP 113 "Median time-past as endpoint for lock-time calculations" https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki

This is a pretty standard and "safe" difficulty algorithm as it has a fixed up and down adjustment percentage and mostly works based on time and difficulty medians.

This algorithm was also chosen for Zcash after they evaluated a few options.

alright i have the new difficulty adjustment pretty much working. simulated the numbers against the existing running testnet chain and it looks good.

need to double check my numbers/formulas and clean up some code and push out the next alpha release.

zzz, 1:35am on a sunday night/monday morning.

[jyap]

Reducing Uncle rewards

Here is something I am strongly considering as well. With a larger block time network lag shouldn't be as much as an issue. There should also be far fewer orphaned/uncle blocks so the current reward scheme seems excessive.

Currently we have under Ethereum:
The miner will also receive an award of 1/32 per Uncle block included. Uncles are stale blocks with parents that are a maximum of six blocks back from the present block. Valid Uncle blocks are rewarded to halt network lag (time to propagate a valid block to the whole network). Uncles included in a block receive 7/8 of the static block reward – or 4.375 Ether- with a maximum of 2 Uncles allowed per block.

The paper Uncle Mining, an Ethereum Consensus Protocol Flaw suggests "Reduce the maximum uncle reward to 1/2."

Further notes/links:

https://forum.ethereum.org/discussion/4736/formula-for-block-reward-when-the-block-contains-uncles
https://github.com/ethereum/go-ethereum/issues/1591
http://ethereum.stackexchange.com/questions/569/why-am-i-getting-less-than-5-ether-per-block

[jyap]

New difficulty adjustment algorithm update - Working great

As an update the difficulty algo is working great in my own private testing against the currently running Alpha chain.

Below is an example.

In the example you can see the current Difficulty calculation is shown as "CalcDifficulty" and the new algo is "CalcDifficulty2" with extra debugging lines.

As mentioned in previous posts, the current difficulty algo for Ethereum and forks is very simple and just looks at the previous block time. In this example the difficulty slightly increases as the previous block was found under the target time of 88 seconds.

The new algorithm inspects a defined window of 21 blocks, which with 88 second block times defines the setting AveragingWindowTimespan as a baseline.  This gives FAR greater difficulty adjustment accuracy as we are looking back at a window of an average 30.8 minutes.  If there is a large hash rate increase the longer window means we can more accurately compensate and prevent instamining and 51% attacks.

Expect a new Alpha build very soon which will include an all new difficulty algorithm based on Digibyte's Digishield. All new code and a first for Ethereum clones!

[jyap]

Jumbucks Ethereum Edition - Alpha 3 released

Here we present you the third "pre-launch" release. This is the best release yet and comes complete with hours of development work and testing in the newly implemented Difficulty adjustment algorithm for this Ethereum fork.

This release has quite a bit of extra debugging in the console, especially when new blocks are found. Also as there is new code that is still in testing, we are keeping it closed source until it's closer to release time.

We are also researching further changes which could assist in preventing malicious 51% attacks on the network.

This Alpha 3 is running really well as we can see the difficulty retargeting of a recent block:

Code:

I0907 22:38:21.676831 core/block_validator.go:338] parentNumber: 458 parentDiff %!(EXTRA *big.Int=488558)
I0907 22:38:21.676960 core/block_validator.go:354] CalcDifficulty2 nActualTimespan = 2108  before dampening
I0907 22:38:21.676975 core/block_validator.go:361] CalcDifficulty2 nActualTimespan = 1913  before bounds
I0907 22:38:21.676986 core/block_validator.go:371] CalcDifficulty2 nActualTimespan = 1913 up or down
I0907 22:38:21.676996 core/block_validator.go:374] parentDiff:488558
I0907 22:38:21.677006 core/block_validator.go:375] AveragingWindowTimespan:1848
I0907 22:38:21.677015 core/block_validator.go:378] parentDiff * AveragingWindowTimespan:902855184
I0907 22:38:21.677024 core/block_validator.go:381] x / nActualTimespan:471957

In this example, the difficulty algorithm looks back at a window of 21 blocks (21 block * 88 second block times = AveragingWindowTimespan:1848) and is able to compensate based on that.  As the calculated timespan observed (nActualTimespan) is 1913 seconds, the algorithm intelligently DECREASES the difficulty from 488558 to 471957.

We have been performing some tests with scaling the hash rate up and down, renting hash rate and observing.

If you are running Alpha 1 or 2, please delete everything in your data directory except for the keystore directory.

This Alpha 3 release has the Genesis Block and Boot node built in. Just run it.

Testnet addresses will have Testnet coins already pre-allocated in the Genesis block.

The Alpha 3 changes are incompatible with the Alpha 1 and 2 network.

Expect this network to have several changes before the actual launch. You can participate in Jumbucks Slack in the #jumbucks channel. Testing is going really well with many participants.

You can find the release here:

https://github.com/jumbucks/go-jumbucksee/releases/tag/1.4.11-alpha3

Changes

• Upgrade codebase to upstream Geth 1.4.11
• Modify block reward. Now 8 coins per block. This change wasn't committed in Alpha 2.
• Reduce rewards for including uncles in blocks.
• This eliminates a possible attack vector in targeting the mining of uncles.
• Modify Difficulty calculation to be based on Digibyte's Digishield. This is a huge improvement over the current Ethereum Difficulty calculation, especially for longer block times.
• Implement CalcPastMedianTime (BIP 113)

Start the console and connect to my boot node:

Code:

gjbsee console

Optionally: Running on a separate console

On one screen:

Code:

gjbsee

On another screen:

Code:

gjbsee attach ipc:/Users/julian/Library/JumbucksEE/gjbsee.ipc 

Binaries (compiled by Julian)

Code:

$ shasum -a 256 gjbsee-darwin-amd64.zip gjbsee-linux-amd64.tgz gjbsee-windows-4.0-amd64.exe.zip 
95f9f88b581b418bfa8a65a65e3d52f7f4bb00edf91d2613d89da46b3a2c0f6d  gjbsee-darwin-amd64.zip
b388c2df32904ae41daff5cd291dc96595c2bf5d45dbecf95c66f7d3b7e039bd  gjbsee-linux-amd64.tgz
63dfd7da23acf520734ed18bc59c4a1ba6e02f7550f50d96e406f60a8fdf76fb  gjbsee-windows-4.0-amd64.exe.zip

[jyap]

In this screen shot below, I rented some hash for 12 hours and pointed it at a pool.

Targeting for 88 second block times is working extremely well.

As mentioned in my previous post, we are also researching further changes which could assist in preventing malicious 51% attacks on the network.

One of these happens to be hard coded checkpoints. This is something which exists in Bitcoin and hard coded checkpoints would just be manual coded points in time.

It's strange that Ethereum doesn't have this already (or maybe I haven't looked far enough in the code) but it can help in the case of an unforeseen fork.

"Other" checkpoints which are more centralized in nature would require more thought/code and tend be semi-controversial.

Vitalik tweeted something recently:

If the centralized checkpoints confirm months of existing decentralized consensus, then imo they are totally okay

Essentially this is what we are trying to achieve while avoiding any scenario/solution that is overly centralized.

[nyo_x]

This is looking very interesting looking forward to next updates. Just one question it will be POW/POS hybrid or just POW?
Good Luck

[jyap]

This is looking very interesting looking forward to next updates. Just one question it will be POW/POS hybrid or just POW?
Good Luck

This will just be PoW for now.

We will definitely be considering all options in the future such as full PoS and PoW/PoS hybrid.

Thank you for your interest!

[ocminer]

In this screen shot below, I rented some hash for 12 hours and pointed it at a pool.

Targeting for 88 second block times is working extremely well.

As mentioned in my previous post, we are also researching further changes which could assist in preventing malicious 51% attacks on the network.

One of these happens to be hard coded checkpoints. This is something which exists in Bitcoin and hard coded checkpoints would just be manual coded points in time.

It's strange that Ethereum doesn't have this already (or maybe I haven't looked far enough in the code) but it can help in the case of an unforeseen fork.

"Other" checkpoints which are more centralized in nature would require more thought/code and tend be semi-controversial.

Vitalik tweeted something recently:

If the centralized checkpoints confirm months of existing decentralized consensus, then imo they are totally okay

Essentially this is what we are trying to achieve while avoiding any scenario/solution that is overly centralized.

Easiest anti 51% attack protection :

Don't allow more than X blocks from the same node / same coinbase address at an interval of X minutes... No need to fuss with checkpoints,  checkpoint server etc..  Keep it simple.


I'll host a pool for you guys as well when you're ready, great work

[Bitice]

Those staking JBS at home will have to do.. what when this swaps to EE edition? and when, roughly?

Will it be easiest to send it to Bittrex and let them deal with it?

[Radent]

JBS i feel to be high price this week or this month. Dev still very active.
God Job Dev of Jumbuck $JBS

[jyap]

Easiest anti 51% attack protection :

Don't allow more than X blocks from the same node / same coinbase address at an interval of X minutes... No need to fuss with checkpoints,  checkpoint server etc..  Keep it simple.


I'll host a pool for you guys as well when you're ready, great work

Hi ocminer. Thank you for the vote of confidence with your pool and suggestion.

I am looking into implementing a new solution for long range reorg attacks that Vitalik has suggested to me.

[jyap]

Those staking JBS at home will have to do.. what when this swaps to EE edition? and when, roughly?

Will it be easiest to send it to Bittrex and let them deal with it?

Hi Bitice,

You can keep staking until the swap.

Briefly there will be 2 methods for swapping. Claiming or using an exchange which will perform a claim and adjust on-exchange balances accordingly.

The off-exchange claim process will involve and consist of:

• Generating receiving address/addresses (a fork of the MyEtherWallet web site will be provided to generate addresses)
• An online form to enter JBS addresses mapped to a receiving JBS EE address
• This form will be provided in both clear net URL and TOR URL form to retain anonymity
• You will need to sign a message to prove ownership of the JBS address
• JBS address balances will be snapshot at a defined block. This prevents double claims
• JBS EE balances will be programmed into the Genesis Block of the JBS EE chain. Be a part of history!
• You will be able to perform a claim at a later date as well after the network has been launched. The intention is not to screw people over with a claim process with a short time window
• At some point we intend to send any unclaimed funds to a multisig address which will require multiple party approval to process any later claims

There will be further details in the upcoming PRE-ANN thread.

We intend to make this claim process as transparent as possible and it can therefore be audited on the blockchain

To maintain a healthy staking network we recommend people participate in the off-exchange claim process for the bulk of their holdings

You may want to consolidate some of your holdings to a smaller number of JBS addresses leading up to the swap

[gigabyted]

Easiest anti 51% attack protection :

Don't allow more than X blocks from the same node / same coinbase address at an interval of X minutes... No need to fuss with checkpoints,  checkpoint server etc..  Keep it simple.


I'll host a pool for you guys as well when you're ready, great work

Hi ocminer. Thank you for the vote of confidence with your pool and suggestion.

I am looking into implementing a new solution for long range reorg attacks that Vitalik has suggested to me.

I will be watching this pool like an eagle!

[jyap]

This question has come up a few times.

Will JBS EE switch to 100% Proof of Stake when Ethereum's Proof of Stake Casper is released?

A switch to PoS isn't definite but we will evaluate and monitor Ethereum's Proof of Stake when it is released and had time to iron out any issues that may arise. A switch to PoS depends on the overall health of the JBS EE network and other factors such as ongoing distribution. It can make sense to just stay on PoW or a hybrid PoW/PoS network.

Another thing to factor in is that when Ethereum switches to PoS there will be excess mining capacity, so that can be another pro for sticking with PoW or a PoW/PoS hybrid.

[crypto-trade.net]

We added your cryptocurrency.
With respect, the development team of Crypto-trade.
Crypto-Trade – Official Announcement https://bitcointalk.org/index.php?topic=1604225.0

[jyap]

We added your cryptocurrency.
With respect, the development team of Crypto-trade.
Crypto-Trade – Official Announcement https://bitcointalk.org/index.php?topic=1604225.0

Your exchange site looks like it's a scam and it doesn't run HTTPS.

[crypto-trade.net]

We added your cryptocurrency.
With respect, the development team of Crypto-trade.
Crypto-Trade – Official Announcement https://bitcointalk.org/index.php?topic=1604225.0

Your exchange site looks like it's a scam and it doesn't run HTTPS.

We use ssl.


Step 1 (The user tries to go to an insecure protocol.)
http://i68.tinypic.com/2qdu3pt.png
Step 2 (Automatic redirection to https)
http://i66.tinypic.com/2s0zqq8.png