So let me now run a simulation over 1 year (I won't include each winner but I hope you can agree from the day example the calculations being made by the simulator are fine).

blocks = 525600
a: 10
b: 10
c: 10
d: 10
e: 10
f: 50
wins( a ) = 52004
wins( b ) = 51687
wins( c ) = 51995
wins( d ) = 51717
wins( e ) = 51370
wins( f ) = 266827
best_streak( a ) = 5
best_streak( b ) = 6
best_streak( c ) = 7
best_streak( d ) = 6
best_streak( e ) = 5
best_streak( f ) = 20

So once again "f" has roughly 50% of the best blocks but more interestingly he has now managed a "best streak" of 20 blocks in a row (double what we have currently being considering to be "safely confirmed").

Clearly if we do nothing about this situation then we would be facing a potentially rather nasty problem (especially as in these examples "f" only has 50% of the stake rather than >50% of it).

As maths and stats are not something so easily understood by everyone I've created a little simulation program to help visualise things.

It doesn't try to take into account timing and just works out the best block based upon a random number and your stake (so I set it up with some hard-coded balances and then each time I run it I get different output but always with similar results as you'd expect).

Here an example of a simulation of 1440 blocks (i.e. 1 day assuming max. number of blocks per day were found).

blocks = 1440
a: 10
b: 10
c: 10
d: 10
e: 10
f: 50
fafcfbffaefdfebfddffaafcffaffcfffacfebfedffffbffbfcfdfabfffdcffafcfbfcaccbecbdf eedffcbefafcffffbcffffffcfbffbffccbffffffffffffcffefd
cfafcbfdacbfeffffdcfeffefffafffcadcffabfbffffecfbfbdfdffffaecbdbffffffcddefffcf cefdebaeaffdbbfbcbcfafbdefafdffaffeffefbfffceaefffffb
ffabfffccbcdbbffceeccfbdefcffbfddbccfadffffffbffffbdabfcffacfbbdfafdffedffeefce ffbbfafcebefffffecfffffcdfaefabffbbfaffcffffffffebeef
ffbfbffdfdbabfecfeffefbacffcfbddefccdecfeeffbadfdfbadeddfecfccbcddbeaeffadabfec fcffffaafffaecfaffefffeebfffcffffbffffdaffffffafcfffb
fcdbfbcfdfffadccfefbdffffeffadaedfffabfdfcfcfaeaffedffddfffffcbdffdffdffdbfefff cabfefcafbeffdeabfdefdeffdfaddfacfdbfeebaccbffeefcfff
bfdfffefffffefffffbeffbbffceaafbfefcfbdcfdfcfdffffeffffedcfeffbfafffecfdfaffbce fafffffbbafffeccafffefafaffafffaaefffbbeefccddafefccf
efcfbfffbffbfcfffbffcffecffffffaafbfffeefeadaacffbfffdfebfcffffefffffdacdefdeac fbfffddfcafffefffffefcbbaadfdcafffefdfffefffffcfbfebb
bfdffcffbdbaafeffffcadfefbfcffbfeefcefbeefbddfdfffbdfffabcbafeddbfabfafeffdfffb efcfbeffffedfffaebedffbfffcfeffcbfafffbffdddfffaffcff
bffdffaeecfdfffbfffabfbaffffffffdeadffefbacdfdeffdfeeafffbffffcfdfdefedbccaffaf bebfeffcefffffdfffcedbbffecfacdefffeffcfeeccfedcccfdf
ffffceffceedddeffaeffebfefedfdfbffbfffbfcffffbfeffafccffffeffecffdffafcffefefff dfffffdafcafffeffffaffffffbfeffaffeffffcfcfdefcfcbaff
eeebbfcfffffccffbfcfaaeffafbffbbfffefeffcfbfbfefccdffbfbbffbcdeceffffffafcfcadf affdfdcfecffadffffdbbbffffafafbfcffeffbee
wins( a ) = 116
wins( b ) = 153
wins( c ) = 151
wins( d ) = 130
wins( e ) = 162
wins( f ) = 728
best_streak( a ) = 2
best_streak( b ) = 3
best_streak( c ) = 3
best_streak( d ) = 3
best_streak( e ) = 3
best_streak( f ) = 12

The wall of text is the "letter" that I've used to name the account holder who was the "lucky miner" and I've bolded the longest running "streak" of wins that have occurred.

So we can see that account "f" won 728 of the 1440 blocks which makes sense as that account has 50% of the stake.

Another interesting point is that in 1 day "f" was able to find the best block 12 times in a row (not something good at all if we are trying to avoid a so-called >50% attack).

Close but it doesn't show their stake (so a little tricky to quickly work out what I want to) although it is rather interesting if you click on a few of those to see their current balance.

The top generators one is closer although it would be better if it could be just "top generators for the last 30 days".

Whilst I am waiting for CfB to come online to discuss TF it would be very helpful if someone could create a blockchain statistical chart that specifically tells us the number of blocks found by the top 100 forgers along with their relative stake (over say the last 30 days) or has someone already got this on a website (I couldn't find this particular chart)?

Hmm...  I am thinking what might work is this sort of approach (not ideal but still could be useful).

An AT is created that can only send funds to 1 of 2 addresses with 1 of those being to "the void" (or a charity if preferred) and the other being to the person you are buying goods from with an AM (from only its creator) being used to instruct it to send to the vendor (and with a timeout to send to the void after x days/weeks/months).

So once you have funded that AT then the guy selling you the goods can see that your funds are "committed" (i.e. you can't get them back) then he sends you the goods and you release the funds to him.

You'd want to tie this in with a "rating" system I'd guess also but I think we do have another use case here (it's actually just a variation on the Dormant Funds Transfer technically).

This is why we *need* math rather than opinion - I've seen many suggestions put forward but not one of them has any "math" to back them up (so sorry to those who have put them forward but that is why I've not replied to most of them).

Oh - okay (you can see then why I want a "math" guy to help us) - so I am happy to "stand corrected" in that case.

My forte is "logic" (which is a small branch of math) but I even struggle with some "general math" little own going into "pure math" (which I tried to pick up but unfortunately didn't do very well at all at).

I did get the "gist" of the "unprovabilty theorem" of Goedel from reading "Goedel, Escher, Bach" but that was written by a *genius* who worked out how to explain the basics of math theory to a computer programmer (I would highly recommend others to *read* that book - it might just "change your life").

From my perspective the "fairness" or not is not even a consideration.

I am trying to "protect the network" and "the blockchain" only.

So far he has produced no mathematical proof and I've already shown that the very idea of being able to penalise the 90% stake holder (as a whole) is *impossible* (as the stake holder just divides up his stake into multiple accounts so only 1 account would get penalised for each block).

I am not going to propose any changes until I have some "math" to back them up (so I don't want people to "believe in me" any more than BCNext) and it will ultimately be up to the community to decide what path to take.

Is it? Just because it hasn't been attacked yet doesn't mean it "won't" or "can't".

We have had no mathematical analysis (which we are hopefully soon going to have).

I suggest the decisions are made upon "math" rather than "gut feelings" or "loyalty" to BCNext (he did say "not to trust him").

No - the pool controls x amount of accounts so has greater forging power (otherwise no point in being a "pool" - I don't think we should actually try and stop "pooling").

Also pools are necessary if we want to be able to create "interest bearing accounts" (which I think will be quite popular) and ramping up to 1000+ TPS will require some decent servers (which aren't free).

We are basically trying to work out if the "penalty" should even exist (IMO it should not) and try to make sure that small forgers still have a "reason" to forge (even if the rewards are not much).

Similar to what I had suggested earlier - effectively we change the "stake" to the number of >x balance accounts that you have (where we would set x at some low value like 1 NXT).

So a large stake holder will have to divide up their holding into many (millions?) of accounts to achieve the same "power" they currently have.

This works best with pooling of course (rather inconvenient otherwise) but without penalty still gives small forgers "a reason to forge".

Also note that I am wanting to work with the math guy on determining the best solution before I propose any *actual change* from BCNext's plan (I am not convinced about the 90% thing anyway and would like to see some "hard evidence").

Great - we are all very keen to see the results!

Yes - just checked with CfB it is the sum of 1 / "block target" for all blocks (although for the modelling purposes the sum of "block target" values would be fine as the use of fractions here is presumably just to deal with numerical limits).

So for each account we take the first 8 bytes of an SHA256 hash of the "previous block sig + your account #" to get a "base target" (so an unpredictable 8 byte value that changes with every block). We then multiply this by your account's balance and the time (in seconds) since the last block to come up with your "current target".

There is also a "minimum target" value set in order to prevent spam (i.e. we don't want the network clogged up with people broadcasting "losing tickets"). This value is not overly important so I wouldn't worry too much about including it in the model (or just pretend it is a constant maybe).

Note that the time multiplication is really just to "widen" everyone's chance so that it won't take more than 60 seconds for "someone" to have a "current target" > "minimum target" and then broadcast their block.

When considering what is a "better block" time would be removed from the equation (so best "block target" is always the "base target" multiplied by "account balance") so the whole "time" thing could be left out of the model (just want you to be clear how the system works).


The weight is simply the sum of each "block target" in the chain (as far as I am aware - will reply again if I've got anything wrong).


Each node will generally connect to as many nodes as it can within max. limits set and it will ask each node it connects to for that nodes connections also but of course a bad guy could choose to only connect to certain nodes.

A node will disconnect from another if that node "spams" it or has gone "quiet" for too long (to prevent wasting memory on non-functioning connections).

To be clearer about the 90% protection that "penalizing" is supposed to give us the problem is "how to you penalize the 90% if it has been split up into x accounts?" and the answer is "you can't".

So maybe the only result of such a penalty is that a huge stake holder won't "show the size of his stake" by keeping it all in 1 account (most likely he never would do that anyway).

Understand that if I had 1,000 accounts and say "10 of them" were being penalised then the other 990 are fine to keep on forging.

I was out watching the new Hobbit film (which is quite spectacular) so have been catching up with the posts regarding TF and forging rewards.

First to clarify something - as proposed by BCNext full TF *would* include the "did not forge" penalty, however, it is up to the community to decide whether or not to do this.

I am hoping the math guy who was taking some interest in this might be able to work out some calculations to help us come to a decision about that (as I think it would be best to trust in math rather than in our "gut instincts").

@2Kool4Skewl your idea of rewarding Hallmark nodes is unfortunately not really possible as there is simply no way the nodes could all agree who was "online" (the network topology problem you mentioned yourself).

Further update - it took a bit of time (to rework the use cases) but now there is no use of "unsigned integers" (except for some "prints") which should make porting to Java easier (most op code values have been changed so no op code > 0x7f).

The next stage is to get some tasks put up on CIYAM Open (http://ciyam.org/open/?cmd=view&data=20140220164742097000&ident=M100V137&chksum=065ecf7d) and organise some people to "put dibs" on them.

Indeed I wouldn't be holding my breath waiting for fiat but I think you'll find that crypto to crypto will be operating on Nxt within a few months.

So - there is a # in each block and a math op is performed with this # + the account # of the "forger" to provide a new #. You can just think of that # as being the "best account #" so the account who's # is closest to the "best" would be the "best choice" to forge the next block (so would have the max. "weight").

If that account doesn't forge then an account "near" it can forge it instead (how near is increased over time to ensure that a block should always appear every minute). So "later forgers" have less weight (the exact weight being determined by their account #).


An unsuccessful branch (or fork) just has "less weight" than the "main chain" so basically it would likely have been forged by nodes that actually can't see the whole network (perhaps due to IP blocking or the like).


The "correct" one is simply that with the most weight - so at any point a node could ask another node for the "height and weight" of their blockchain and if that answer is better than their own then they would ask for those blocks in order to "switch chains".


Exactly - we need those figures.


The whole penalty thing is something we are trying to figure out as it will inevitably penalise nodes that are not malicious and may "turn people off" helping the network by forging.

Once we have the math we can make a much better decision.