Bitcoin Forum
July 26, 2017, 07:04:09 AM *
News: BIP91 seems stable: there's probably only slightly increased risk of confirmations disappearing. You should still prepare for Aug 1.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 »  All
  Print  
Author Topic: [JBS] Jumbucks - No IPO/ICO - Proof of Stake - Slack - DCR Stake Pool - 2+ Years  (Read 44523 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
jyap
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
August 25, 2016, 01:08:43 AM
 #201

Here are the priority items in the next few weeks.

Launch of new coin

All the technical details are being worked on as well as co-ordination with exchanges.

PRE-ANN thread

The details are being written up.

Swap system

We are working on the technical details. This will be fully outlined in the PRE-ANN.

Code modifications

Implementing and testing out a new difficulty adjustment algorithm. May also take a quick look at the Ethereum Zcash implementation.

Logo and branding

We are working with some designers currently.

1501052649
Hero Member
*
Offline Offline

Posts: 1501052649

View Profile Personal Message (Offline)

Ignore
1501052649
Reply with quote  #2

1501052649
Report to moderator
1501052649
Hero Member
*
Offline Offline

Posts: 1501052649

View Profile Personal Message (Offline)

Ignore
1501052649
Reply with quote  #2

1501052649
Report to moderator
1501052649
Hero Member
*
Offline Offline

Posts: 1501052649

View Profile Personal Message (Offline)

Ignore
1501052649
Reply with quote  #2

1501052649
Report to moderator
Decentralized search
Search for products or services and get paid for it
pre-sale Token CAT
25 July 50% discount
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1501052649
Hero Member
*
Offline Offline

Posts: 1501052649

View Profile Personal Message (Offline)

Ignore
1501052649
Reply with quote  #2

1501052649
Report to moderator
jyap
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
August 25, 2016, 08:27:35 AM
 #202

Decred stake pool payments sent out.

9.41955692 DCR sold for 0.02414832 BTC
275.22793876 JBS bought for 0.02408795 BTC

So far 1656.5543822 JBS has been bought back off the market.

The pool is slowly growing and represents 3.269% of all live Decred staking tickets.

So far the pool has paid out over 2492.35106093 DCR in total stake subsidy.

The pool was officially announced and opened on July 18, 2016, 11:18:29 AM. A bit over a month ago!

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

If you require assistance, 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
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
August 30, 2016, 01:09:10 AM
 #203

New difficulty adjustment algorithm

One of the code changes we will definitely be implementing with JBS EE is a new difficulty adjustment algorithm.

As a background, the Ethereum protocol is set to adjust its mining difficulty so that it targets a 15 second block time.  The formula that it uses isn't very complicated but the main inputs it takes are the the parent block time, parent block difficulty and the block time of the recently found block.  The difficulty algorithm makes fractional adjustments either up or down depending on whether the block is above or below the target time.

At a large scale this works just fine and with sufficient hash, this gives sufficient security. With a relatively stable hash rate, the difference in block time with 15 second blocks is negligible.  Proportionally, it's not as discernible when the block time is 7 seconds or 20 seconds over the span of a few hours.  Small fractional difficulty adjustments however become greatly amplified when you have a longer block time.

Where you run into issues with this difficulty adjustment approach is a) Smaller hash rate b) Greater fluctuations in network hash rate due to Smaller hash rate c) Longer block times.  Longer block times mean that any fractional adjustments (found in the Ethereum protocol) do not adequately compensate for changes in hash rate in a timely enough basis.  You end up with very fast or very slow blocks.  This is commonly referred to as instamining (fast blocks) or slow stuck blocks.

Provisional code changes have been made and are in the testing phase for a new difficulty adjustment algorithm for the JBS EE chain.  This will be a first for Ethereum fork which have comparatively made adjustments to the parameters to the existing Ethereum difficulty adjustment.

We will take into account the difficulty window of a range of past blocks when calculating the difficulty change.  Every modern difficulty algorithm such as Dark Gravity Wave v3, DigiShield v3, Monero and Kimoto's Gravity Well all work on the principle of making adjustments according to a difficulty windows of past blocks. Below is the output of some testing log lines which shows the refactored code processing the headers of the past 10 blocks when running the difficulty calculation function.


This will allow us to write a more modern difficulty adjustment algorithm similar to other blockchains which have taken in the lessons of multipools and 51% attacks.

In summary, the Ethereum protocol difficulty adjustment is inadequate for our needs.  The JBS EE chain will have a more accurate difficulty targeting algorithm suitable for an 88 second block time, will be able to handle fluctuations in hash rate more effectively and these changes will also ultimately bring more security to the chain.

* This is a good thread which discusses some modern difficulty adjustment issues https://github.com/zcash/zcash/issues/147

jyap
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
August 31, 2016, 01:10:46 AM
 #204

Decred stake pool payments sent out.

8.7 DCR sold for 0.02218239 BTC
225.82152027 JBS bought for 0.02227907 BTC

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

If you require assistance, 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
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
September 01, 2016, 02:33:10 AM
 #205

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.

jyap
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
September 02, 2016, 07:31:36 AM
 #206

I have renewed the Block explorer hosting for another 6 months:

https://chainz.cryptoid.info/jbs/


BoscoMurray
Sr. Member
****
Offline Offline

Activity: 438


View Profile
September 03, 2016, 08:28:48 PM
 #207

thanks for the regular updates jyap. they are appreciated.
jyap
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
September 04, 2016, 10:59:06 AM
 #208

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
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
September 05, 2016, 07:33:19 AM
 #209

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
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
September 05, 2016, 11:37:18 AM
 #210

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
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
September 06, 2016, 08:02:23 AM
 #211

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
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
September 06, 2016, 10:11:58 AM
 #212

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
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
September 08, 2016, 09:33:48 AM
 #213

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
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
September 09, 2016, 08:51:34 AM
 #214

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
Full Member
***
Offline Offline

Activity: 156


View Profile
September 09, 2016, 08:37:49 PM
 #215

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
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
September 10, 2016, 12:07:27 AM
 #216

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
Legendary
*
Online Online

Activity: 1806



View Profile WWW
September 10, 2016, 12:19:25 AM
 #217

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

suprnova pools - reliable mining pools - #suprnova on freenet
https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
Bitice
Member
**
Offline Offline

Activity: 65



View Profile
September 10, 2016, 09:16:49 AM
 #218

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
Full Member
***
Offline Offline

Activity: 229


Bit Hunter


View Profile
September 11, 2016, 03:41:52 AM
 #219

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

jyap
Hero Member
*****
Offline Offline

Activity: 482


I support $UBQ #ubiq


View Profile WWW
September 11, 2016, 04:48:44 AM
 #220


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.

Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!