Yup

Given a set of active witnesses,  the witness that goes next can be calculated as:

  ACTIVE_WITNESSES[ HASH(BLOCK_TIME)%NUM_ACTIVE_WITESSES ]

This approach means witnesses cannot influence the schedule at all and that the order of witnesses will be deterministic yet random.   

In which case if I have 2 or 3 bad witnesses I can identify times in the future where I'll control 3 or 4 or 5 blocks in a row (because witnesses could be repeated) and time my attack for that pre-determined time window.  You can't really do sha256(xyz)%ACTIVE_WITNESS as that mod operation is difficult to calculate correct?


A = NUM_ACTIVE_WITESSES
What if for every A blocks the SHA256(LAST A blocks full block data) is the seed to a PRNG that is used to cycle through all witnesses in a random non-repeating order.  The last witness can influence the order of the next A blocks but only by brute forcing a ton of hashes (by slighting changing the transactions he's including i.e. a transaction back to himself) to get a couple colluding witnesses in order.  (Someone will have to run the numbers on if I have 3 colluding witnesses, how many hashes do I have to do to have a 50% chance of finding a way to get them next to each other in the upcoming block order. 

You can get maximum coverage of witness nodes, but each time you run through the witnesses it's in a unique/random order that is influenced by 100% of active nodes so the randomness can't be controlled.  The last node has some additional power here.....   You can make it so that the last node of each of these super blocks can't include any transactions but can only include a random # from 1 - 10000, or something like that.  So if the last node of a super block is a good node he will use a real random number and screw up any badness from the previous node assuming the second to last node is a bad node.  However, if the opposite is true, the last node is a bad node, he only has 10000 different combinations to pick from to try and manipulate the witness order for the next A blocks.  Additionally if the last witness can't include any transactions, then the only naturally repeating witness occurrence would be when the last and first are the same witness but only in one of those blocks would he be able to include transactions.(because of the additional restriction on being the last block) 

Then you just tweak your maintenance interval to happen on these superblock intervals so that the number of Active witness doesn't change mid superblock. 

Maybe that's too complicated.  That's the best I could come up.

if the --resync-blockchain is specified, does that prevent the witness form signing blocks?  I coudn't get my witness to start signed by then tried removing that and it seemed to work.  Also, if it has to resync from scratch (like empty folder) then it also doesn't seem to sign blocks.    Not 100% sure but it seems I have to:

get the witiness all synced up.. then shutdown gracefully with a ^C (which doesn't always work btw, it sometimes says DB is corrupt and restarts from scratch) , then start it again , at which point it then starts to sign blocks.

The engineer in me says make the system work for 1s but then actually use 10s order of magnitude sadety

Bytemaster just pushed a new commit with a tag of test1.  That is available as a docker image at sile16/graphene-witness:test1

Just woke up,
tried to restart withe the --checkpoint option , have a mix of not producing because we are stale and then some serving up block.  pretty sure it's not right...  I won't be able to change anything until late tonight.

530999ms th_a       witness.cpp:240               block_production_loo ] slot: 21412 scheduled_witness: 1.6.5249 scheduled_time: 2015-08-20T13:08:51 now: 2015-08-20T13:08:51
530999ms th_a       witness.cpp:211               operator()           ] Not producing block because production is disabled until we receive a recent block (see: --enable-stale-production)
531999ms th_a       witness.cpp:240               block_production_loo ] slot: 21413 scheduled_witness: 1.6.5246 scheduled_time: 2015-08-20T13:08:52 now: 2015-08-20T13:08:52
532999ms th_a       witness.cpp:240               block_production_loo ] slot: 21414 scheduled_witness: 1.6.0 scheduled_time: 2015-08-20T13:08:53 now: 2015-08-20T13:08:53
533999ms th_a       witness.cpp:240               block_production_loo ] slot: 21415 scheduled_witness: 1.6.1536 scheduled_time: 2015-08-20T13:08:54 now: 2015-08-20T13:08:54
534999ms th_a       witness.cpp:240               block_production_loo ] slot: 21416 scheduled_witness: 1.6.5245 scheduled_time: 2015-08-20T13:08:55 now: 2015-08-20T13:08:55
535999ms th_a       witness.cpp:240               block_production_loo ] slot: 21417 scheduled_witness: 1.6.1525 scheduled_time: 2015-08-20T13:08:56 now: 2015-08-20T13:08:56
536999ms th_a       witness.cpp:240               block_production_loo ] slot: 21418 scheduled_witness: 1.6.1 scheduled_time: 2015-08-20T13:08:57 now: 2015-08-20T13:08:57
537604ms th_a       application.cpp:487           get_blockchain_synop ] reference_point: 0000000000000000000000000000000000000000 number_of_blocks_after_reference_point: 0 result: ["00001fc61a621678e92fc941b58b08d13afa2268","00005fc6559ab7b6f2b0035b0accec1ca7bb9110","00007fc615d686c893fe81c7b3790565bd3ccac3","00008fc6ef374fa2e6b8a03a490dfc6f274d1b8c","000097c68746555744ecea0a5753eabbb540cb4b","00009bc6d4d50fefd8cca7e61cf243a1820d8add","00009dc666f08e568fddfe6ef99968363b649c16","00009ec6b4958ad1910cfd3d3d5451634b8c948a","00009f46f5a6a32bbe673fb3990ae69d80d29779","00009f863b8da93c16cd47c9a591d7a9071e92e1","00009fa6414eb1adf2e7a4e0ec81fa58bb2f0802","00009fb612985adcce921f4e1e47326e45b088dd","00009fbe0bbfc979683d479ba4abd6242dd0b7b0","00009fc2c4081a76afbad31337249726a2d06515","00009fc4a66df9d134e85476353bae7af2715909","00009fc50fe983dde2e975f6aed7d69f4f2cd952","00009fc6d4e24db66e13af461b94063165999bfa"]
537999ms th_a       witness.cpp:240               block_production_loo ] slot: 21419 scheduled_witness: 1.6.4435 scheduled_time: 2015-08-20T13:08:58 now: 2015-08-20T13:08:58
538115ms th_a       application.cpp:487           get_blockchain_synop ] reference_point: 00009cb4e54f640a0cef1aeab7aab0dfc955d333 number_of_blocks_after_reference_point: 0 result: ["00001fc61a621678e92fc941b58b08d13afa2268","00005fc6559ab7b6f2b0035b0accec1ca7bb9110","00007fc615d686c893fe81c7b3790565bd3ccac3","00008fc6ef374fa2e6b8a03a490dfc6f274d1b8c","000097c68746555744ecea0a5753eabbb540cb4b","00009bc6d4d50fefd8cca7e61cf243a1820d8add","00009dc666f08e568fddfe6ef99968363b649c16","00009ec6b4958ad1910cfd3d3d5451634b8c948a","00009f46f5a6a32bbe673fb3990ae69d80d29779","00009f863b8da93c16cd47c9a591d7a9071e92e1","00009fa6414eb1adf2e7a4e0ec81fa58bb2f0802","00009fb612985adcce921f4e1e47326e45b088dd","00009fbe0bbfc979683d479ba4abd6242dd0b7b0","00009fc2c4081a76afbad31337249726a2d06515","00009fc4a66df9d134e85476353bae7af2715909","00009fc50fe983dde2e975f6aed7d69f4f2cd952","00009fc6d4e24db66e13af461b94063165999bfa"]
538276ms th_a       application.cpp:438           get_item             ] Request for item {"item_type":1001,"item_hash":"00009cb5f3657547f191efd666aa7aaca57b3a8f"}
538276ms th_a       application.cpp:446           get_item             ] Serving up block #40117
538276ms th_a       application.cpp:438           get_item             ] Request for item {"item_type":1001,"item_hash":"00009cb5f3657547f191efd666aa7aaca57b3a8f"}
538276ms th_a       application.cpp:446           get_item             ] Serving up block #40117
538467ms th_a       application.cpp:487           get_blockchain_synop ] reference_point: 00009cb4e54f640a0cef1aeab7aab0dfc955d333 number_of_blocks_after_reference_point: 0 result: ["00001fc61a621678e92fc941b58b08d13afa2268","00005fc6559ab7b6f2b0035b0accec1ca7bb9110","00007fc615d686c893fe81c7b3790565bd3ccac3","00008fc6ef374fa2e6b8a03a490dfc6f274d1b8c","000097c68746555744ecea0a5753eabbb540cb4b","00009bc6d4d50fefd8cca7e61cf243a1820d8add","00009dc666f08e568fddfe6ef99968363b649c16","00009ec6b4958ad1910cfd3d3d5451634b8c948a","00009f46f5a6a32bbe673fb3990ae69d80d29779","00009f863b8da93c16cd47c9a591d7a9071e92e1","00009fa6414eb1adf2e7a4e0ec81fa58bb2f0802","00009fb612985adcce921f4e1e47326e45b088dd","00009fbe0bbfc979683d479ba4abd6242dd0b7b0","00009fc2c4081a76afbad31337249726a2d06515","00009fc4a66df9d134e85476353bae7af2715909","00009fc50fe983dde2e975f6aed7d69f4f2cd952","00009fc6d4e24db66e13af461b94063165999bfa"]



my witness node stopped producing blocks as well.