Topic: oPoW (optimized Proof of Work) (Read 498 times)

1: You can't build blocks sooner than the previous block was broadcasted as you need the hash of that block. But even if you got hash rate winning you 100 blocks and you also was the creator of the proof block and you ordered yourself inline (eg. your 100 blocks are one after each other) you still can't do much. You can stop doing anything and someone else will (see point two). You can create the 100 blocks in advance of course (I mean right after the -1 block's hash is available), but who cares? I mean building the block needs you PrivKey and the transactions only at this point of time.

2: As long as there is one single honest miner you can't delay as all miners have to right to produce (and broadcast) the next block if the PoW pre-selected/prof-block included miner failed to do so at the right time range.

It's simple as this:
If you find a good enough hash to get you the right to mine one block that's it. There is no reason find "stronger" hash. Why would you do/need that?
You broadcast what you found and continue working to find the second hash which gets you the right to mine one more block. No reason to split your hashrate unless you have 1000x more than needed, but shouldn't be the case as difficulty would have adjusted. If this is a one time case when you fired up 1000x times more ASICs (how?) than the previous diff was based on than yes, you can work on 1000x hashes and gain the right to mine 1000x blocks in that period. But this is the same as today's PoW.
[mnp] can only do this if he has way more hashrate than 51%. Interesting point though, as in this proposal adjusting for hashrate changes could be a big problem. As you only see the winning hashrate included in the winning proof-block that miner can hide <50% hashrate by not including them at all.
But: I believe PoW solves this as % wise the smaller hashrate miner will win the right to create the proof-block and include too. So I think PoW would solve the lower hashrate problem as random hash distribution should even out and the larger hashrate will loose whole(!) proof blocks if disregarding competitor good enough hashes. By doing so he will delay the time he has all the 2016 hashes and the lower/honest miner has more chance to find a good enough hash and broadcast his own proof-block.

i said HM will have 1
you said 'no as [HM] would have more then one' but then you explained it by saying no one said [hm] should stop when getting a 'good enough' hash..
.. weird explanation.. because by your suggestion.. not stopping means continuing 1 hash but even stronger
.. you then said no point splitting hashrate.. meanign you also suggest not working on second hash

meaning you ended up explaining yourself into a scenario where [hm] does infact end up with 1 key:hash proof of block 2008
(you talked yourself into agreeing with what my scenario suggested in the first place)

sooo.. going with my first scenario suggestion of [hm] sticking with one key:hash proof of block 2008 that is super strong. rather than splitting his hash for multiple attempts of the 1hour 2008 proof of weaker key:hash

as you then say the special 'proof block' lists 2016 key:hash by hashrate.
so knowing [MMP] has been making 2016key:hash
[mmp] gets more listings in the special block and [hm] only has 1 chance

..
then when forming the special block.
[hm] templates his own list 1key. and his preferred 2016 keys he has had relayed to him from competitors
and he makes his own attempt at special block
[mmp] template ignoring competitors relayed to them.. and just list their own 2016 keys, meeting min diff.
and they pool mine [mmp1to8] and make their own special block with more combined hash than [hm]

thus [mmp] win as they done most work on the special block
thus their listed preferred key:hash of 2016 keys get to be the PoS signers for the next fortnight

and now mmp can do their own gaming of the system in secret.

..
again for a reminder all the 2016 keys of the next session of the winning special block are [mmp] managed
meaning only their listed keys can make blocks.
this opens up 2 attacks
1. PoS mine all blocks in 7 hours secretly. broadcast publicly at prescribed times
2. because they're the only miners allowed to mine for next fortnight.. they can just all NOT broadcast anything for whole fortnight

(yes 2 means loss of reward revenue due to not making blocks to have rewards)
but its still a stall event for a fortnight

There can not be no missing blocks. If the original winner won't broadcast a valid block in the proper time range the next minute will allow for miners of the prev/next block to do so the next minute allows any miners in the epoch.

I believe no as [HM] would have more than one as no one said that you as an HM should stop mining when you found one good enough hash. So no point splitting your hashrate as one private key can have more than one blocks or you can create separated PK for all blocks you intend to mine.
Because of this a proof hash's accumulated and listed in the proof block would be distributed by hashrate. If your hashrate is too low [AJ] you should join a pool as happens today.
Because of this there is no reason to withhold as hashes will be coming relatively quick, so if you don't create a proof block as fast as possible someone else will and that will be the block => you lost.

I think the idea is an interesting one. I think it could likely work. However, the benefits are limited. Yes, you'd save some electricity, but as has been previously mentioned, miners will always be willing to spend up to the amount of the block rewards in order to mine blocks. So this wouldn't save money, because miners would buy enough extra mining equipment to offset the cost they would be spending on electricity. It would also mean that miners would use their ASICS for something else the rest of the time, if possible, which might mean that electricity isn't actually saved. In order to actually save electricity, the PoW algorithm would need to be designed such that the ASICS could not be used for other things (not sure how possible that is).

The mining scheme should be workable tho. Let me recount the way I would do this:

1. At the beginning of each retargetting period, the first block mined is basically the starting gun,

2. then everyone mines a receipt on top of that block at greatly reduced difficulty (1/2016th the difficulty) for 10 minutes,

3. as soon as anyone collects 2016 receipts (adding up to a full normal block of work) they put those receipts into a block and hash that until its been mined at the normal difficulty. This step should exist so the race continues, rather than having a point of failure of the miner that mined the first block in the retargetting period (what if they refuse to sign and broadcast a list?). Also, this ensures that its difficult to create a different list of receipts.

4. once the step 3 block has been mined, it locks in the receipts, and therefore the order of the next 2016 blocks

5. The miner who owns the first receipt in the list must include the hash of the commitment block containing that list as its previous block.

6. For each of the next 2015 blocks, the miner will basically have a time limit to mine their block (rather than racing). If they create their block within the time limit, they get to create that block. If they miss their window, the next miner in the lineup can broadcast their block on top of whatever the most recent block is.

While in normal PoW, miners are racing to mine and broadcast as fast as possible. In the pre-ordered block creation, miners actually have an incentive to wait until their time is almost up to broadcast their block, because they want to include the highest-value transactions they can (and they want as many mempool options as possible before committing to a block). However, because the next miner can skip them if they miss their window, they also have an incentive to broadcast their block well enough before their window ends that they don't risk being skipped. So miners would probably wait until say 10 seconds before their window ends to broadcast their block, but if the previous miner missed their window, they would probably broadcast ASAP (at the beginning of their window) to capture the transactions that miner missed.

An interesting thought experiment is: what should honest miners do when they see conflicting chains? Like, lets say one chain has block receipt 300 skipped but contains a block for receipt 301 and the other chain doesn't have 300 skipped but doesn't contain block 301? Which chain should that miner choose? I suppose this would be like any orphan situation where the miner would choose the chain they saw first, since they're both the same length. Maybe there isn't a problem here.

In any case, this is an interesting idea and was fun to think about. But I don't think the benefits are enough to make it worth the effort and risk of other issues.

but thats a good hash of a single block in the entire fortnight.. block number 2008 (your special block minus X)
which you PRESUME can only be mined at the 13th day at the 22:50 hour.. not before or after
which you PRESUME honour of only making 1 attempt per miner to have a utopia of 2016 different miners listed

ok tweaking the scenario
still the same problem

lets make some assumptions
[AJ]average joe hashrate : 330thash+ (3 asics+) (-9,000x of MMP each)
[MMP1to8]malicious mine partner1to8: 2.97Ehash(27,000 asics) each
                                                          23.76Ehash(216,000 asics) combined
[HM]honourable miner: 19.8Ehash(180,000 asics)(+6x of MMP each)(0.83x of MMP combined)
also assume
the difficulty of hash of block2008 'list entry requirement' would be lower than the special block hash difficulty
(to ensure there is always over 2016 possible entries to choose/include(give all the AJ's & HM's a chance))
also assume
the special block maker has full discretion of who he chooses to include, what order, etc

..
so lets run the scenario again

before next session (day 13 hour 22:50 of prev session)
[MMP1to8][HM][AJ] all are working on block 2008 hash
[MMP] have 9,000x each more then [AJ],
  but whilst [AJ] is making 1 hash for an hour
  [MMP1to8] split their efforts
  so [MMP1to8] split their 216k asics into 107 asics per hash attempt for each new entry
  ensuring they have 2016 key:hash primed with hashpower, each over 100x more then [AJ]
  (sorry AJ youll never be a normal PoS block maker)
 
at day 13 hour 23:40 prev session
[MMP] made 2016 key:hash associated to block2008 to be used as nest session block maker keys
[HM]and all the [AJ's] have 1 key/hash associated to block 2008.. [AJ] is too low. [HM] has one super strong

at day 13 hour 23:40:05 prev session
there are thousands of different [AJ]'s with 1 key:hash each and 1 [HM] key:hash with a acceptable difficulty
[HM] (main competitor) adds is own single key. and 2014-5 keys of next highest..
                                   AKA [MMP] keys to his [HM] template (such an honourable man)

[MMP] ignores [AJ]&[HM] keys associated with block 2008.(like pools ignore transactions currently)
[MMP] special block template includes 2016 [MMP] key:hash with 100x hashpower attached to each

at day 13 hour 23:40:10 of prev session
[MMP1to8] combine hashpower as a pool to work on a 10minute hash of special block using 23.76Ehash
[HM] spends 10minutes hashing his special block template using 19.8Ehash
hundreds of [AJ] spending 10 minutes on their special block using 330Thash

[MMP][HM][AJ] all are working on special block 2016 hash. for 10minutes(all honourable mining)

at day 13 hour 23:59:55 of prev session
[MMP] have a hash for special block(with preferred strong keys). and broadcast it
at day 13 hour 23:59:59
[MMP] got lucky their 'special block' got accepted to the network as valid win with 23.76Ehash effort
(stronger then [HM] 19.8e special block)
....
note if MMp lost and [HM] won. honourably [HM] would add the highest difficulty keys it seen
(aka MMP keys)
so even if MMP losses this session ability to be special block creator. he still has alot of blocks in the next session. which if [hm] added them consecutively, [MMP] can still make several blocks ahead of broadcast..
especially if [HM] put a long batch of keys preceeding/leading upto and including block2008-2015
now im digressing
...
at next session day0 hour0 - assuming still [mmp] won
[MMP] makes 60 blocks in 10minutes from his list and share them in secret only with [MMP1to8]
[MMP] only broadcasts block1 at the 10th minute to [AJ] [HM]
[MMP] makes another 60 blocks in 10 minutes share them in secret only with [MMP1to8]
[MMP] only broadcasts block2 at the 20th minute ([MMP]now secretly 118 blocks ahead)
.. and so on and so on, building up a buffer of blocks before required broadcast times

at day0 hour5:35
the rest of the network[HM]&[AJ] has only received 33 blocks at their prescribed times so far
[HM][AJ] treat them as valid, because the list of miner keys in the special block match the signed blocks
and they were broadcast at the right time

[MMP] has made 2008 blocks.. (secretly)
[MMP] can now make lots of concurrent hashes of block 2008 for his key:hash of next session listing
[MMP] split their 2016 public key associated with block 2008 attempts into each key has 107 asics and runs for 2 days meaning each entry for the next session list is over 5000x stronger hash then [AJ]
(again sorry to all the AJ's youll never get to be a miner)
(sorry HM even you are not the highest has for your key:hash entry)

at day2 hour 05:36.
[MMP] have now all 2015 blocks of the session waiting secretly.. and all very strong keys of block 2008
[MMP] has only broadcast by now 312 blocks to [HM]&[AJ]
[HM][AJ] treat them as valid, because the list of miner keys in the special block match the signed blocks
and they were broadcast at the right time

at day2 hour 05:36.
[MMP] can start hashing the special block template including their preferred keys
[MMP] for 11 days and 18 hours they can make the special blocks hash with a super strong hash
which due to them combining as a pool can have a hash of 23E running for 11 days. will be alot stronger than [HM] 10min 19.8Ehash effort later on
...
note MMP have been continuously hashing for 11 days to beat HM 10min hash
..
at day 13 hour 22:50
[MMP] finally gives out block 2008 to [HM]&[AJ]
[HM] & [AJ] can finally start their 1 hour hash of block 2008 to get a public key for possible list entry
[MMP] has already got all prefered keys with strong hash each and a 11day strong hash for special block

thus [MMP] win the next round
now MMP has full control and win every block and every session

..
now here is the thing
because you made it a point that only the 2016 key owners inside special block get to be miners
you have caused this opening to malicious miners to do empty block, for fast block creation
especially if each block(bar2008 and special) is PoS
note: to win a special block. does not require a 51% attack. malicious pools can just get lucky with less hashpower. or combine efforts to pool higher hashpower to increase chances.. worse case. they just have to wait another 2 weeks and try and get lucky before implementing their strategy

..
now imagining they got lucky and implemented their strategy
now if you were to put a rule in that invalidates 'empty block'.. but whereby all malicious miners are the listed miners for the session
you end up stalling the network. because the only people able to mine are also the only people your rejecting. and no one else outside your special block list can take over..

so you are going to need a second rule where if there is a network stall. you have to orphan all blocks back to and including the special block. so that someone else can have a chance to make a honourable special block

but here is then the next error in this rule
the malicious pool could have another hash of another special block of slightly less than first (now orphan win) but still higher then if [HM] was given another chance

That's something I didn't think this way. Not easy to increase XXXX MW capacity, but doable with time and money for sure. We could end up with 100x times more load used by 100x more miners with huge intermittent load for the grid  So my idea looks good for mining manufacturers only at the end (which I am not). As most of the time it's better to stick with the devil/algo you know.

This is still prone to Sybil attacks though. Bitcoin avoids this by having the timestamp protected by PoW.



I doubt it would save miners money. Remember that mining -- even if "optimized" -- always reaches an equilibrium of money being spent vs money to be made. So as long as there's money to be saved -- which in the end is profit to be made -- miners will pour in. Accordingly even if a workable system could be conceived that would reduce constant mining to just a few hours every two weeks, miners would simply spent all the resources they'd use over two weeks in just those few hours. So you end up with a system that not only does not use less resources, but to make matters worse, uses the resources it does have at its disposal way less efficient than it could (ie. stress on hardware and infrastructure due to mining operations going on and offline, assuming they don't simply switch to a different blockchain during "idle" periods).

I agree this is a tough/impossible problem. Although I think that all the nodes have a decentralized time of it's own. Attacking all the NTP servers at once (especially as the clients don't update too often probably once a day, and use their own internal clock always) is probably impossible.

Implementing this on bitcoin is impossible for several reasons (never thought that), also risky and I would hate it myself.

But as an idea it has some validity IMHO. So maybe battle testing for years on a testnet/alt would would be interesting as this is not a huge change and would save a lot of money for miners.

For the grid though it would be worse than the current continuous 100% load as this is probably much easier to handle than having all the miners firing up for a few hours/months.

The creator of the special block would not be a special or selected entity, but pure PoW selected. So to get right to mine a block you would need to find a hash and assuming you collected enough PoW hashes AND you find a 2000-3000-10000 times larger hash you (or anyone else who finds a good enough has) can create this block.


The block creator is PoW selected for each epoch/proof-block not designated by anyone.


The whole process is PoW so if you have more hash power you will be able to mine more blocks just as today. The only way to be added to the special block is mine a good enough hash.


Non mining nodes have their own internal clock (thousands of independent clocks) so they would simply refuse to accept in advance/too late/invalid signature. And as a punishment for cheating the prev/next/any? signer would have to right to send the block with this blockheight in the right timeframe.

No honor system in this proposal just pure PoW and nodes for consensus enforcement (~as today).

The clock is an oracle in fact.
All protocols that require exact time measurement and the consensus of users as to whose clock gives the correct time are inevitably centralized.

or more simply
(imagining difficulty started at GPU solomining levels again(another utopian dream))

user has beenn selected randomly as slot 2016 honourably
he has  10,000x more then average joe and when he seen block 2008 he ran
2016 concurrent PoW processes using 4x average joe hashpower.
because he has specil block status he also ensures he gets to be special block manager each session
meaning al blocks become his. forever

or he and 15 friends with 10,000x average joe colluded to have
126 concurrent PoW of 80x more then average joe
16 people getting 126 blocks per session. where they are 80x more power then other solominers
at the end of their session one of them is specila blocker. to ensure inclusion of all 16 for each session

i thoroughly understand the premiss of the utopian honour system you imagine. but put the blackhat/collusion competition hat/bug finding hat on and run scenarios on your algo where by users are trying to game the system

i know you are living on the assumption of utopian honour of how the algo SHOULD work.
but when it comes to finding bugs and loop holes. dont assume utopian honour by default.
assume competing adversaries finding any efficiency possible for own selfish gains.
including assumptions of collusion of multiple parties. or replication of single parties multiple times

bitcoins beauty is the assumption of competition. and so bitcoins current algo solves the competition in a way that makes them play by the rules(byzantine generals rule, and other game theory)
your assumption is they play honourably by default to make your rules work.. (the opposite)

so under as natural assumption of competition. you do need to consider bad actors and also groups colluding.
and then try to see where the bugs/loopholes in your algo are

so possible assumptions you do need to consider:
1. when nodes get the 2008th block (special block-7) the assumption is any/all nodes can start a PoW process on that 2008 header and attach their address to be included in next special block
whereby the special blocker adds in the highest 2016 hashrate proofs
-assume that all parties wanting to be in special block will want as early a head start as possible
-assume the special blocker can select and ignore anyone he wants, even if they have good hashrate
(EG tx fee. paying most fee does not guarantee you access into next block. the block maker decides)

2. assume those wanting to be added to special block will have more hash power than average joe. and able to do more then one PoW process concurrently to have more then one address committed to special block

3. assume the special block creator (address listed for position 2016) will not want to lose its control and continue to put his address and PoW proof at the next 2016th slot to remain in control as list manager

4. assume the special block creator chooses which slot listers to have as he is the one writing the block template and signing it.


you also have to assume other competitions. where by your utopian narrative THINKS alice will only broadcast at her prescribed time to avoid bob from stealing her slot. where your utopian honour thinks your algo works.. however if alice and bob are the same person. or alice and bob are friends collaberating.
your algo wont work

...
so now run the scenario.. imagine there are 1million users. and say 10,000 elite users with more then average hashpower
and of the 10k there are 504 super 'farms' that want to collude together..(corporate/buddy group)
imagine they have 10,000x more power then average joe
so each of the 504 use the scenario in which i played out in my previous post.

all secretly handing each other their blocks ahead of time to make all 2016 blocks in about 7 hours.
non-mining nodes know nothing of this,
non-mining nodes only given the blocks at the prescribed time

so lets dig deep into the scenario
so these 504 have all 2016 blocks early.. and have 13days and 17 hours SPARE to make their PoW proofs of block 2008 which they already have waiting..

they can use all 10kxAJ hashpower consecutively in 4 attempts of 3 days each.. so that they all have 4 listings each when it gets time to submit their proofs
where the hashrate will be of 3days work at 10,000x more then average joe, per address.. to secure 4 slots in the special block each

or they can split their 10,000x hashpower into 4xof 2500x and run 4 concurrent runs of 2500x for 13 days

either way. this group of 504 users are now guaranteed 4 blocks a month. and average joe has no chance of being a miner in the future

..
and now assume the miner at listing 2016 (special block) gets to pick which 504 miners to be listed in the block. as he is the one that creates the template and signs it..

.
i thoroughly understand the premiss of the utopian honour system you imagine. but put the blackhat/collusion competition hat/bug finding hat on and run scenarios on your algo where by users are trying to game the system

I believe this is not the case. As soon as 0001 was broadcasted (and signed) early all honest nodes disregard (doesn't matter what the timestamp is as all node know the time). In addition Aliceminer's signature and right to mine would be banned (by the honest nodes) because of cheaiting and the next/prev miner would have the mint the block around the correct time.

Of course not, I am not -this- dumb . The miner creating the proof block can only decide the order of the miners not who mines. This is PoW so each miner needs a signature AND a PoW proof of hashrate (hash as today). So the builder of the proof block can only build a block if collected all the mined hashes (PoW) and ordered them properly. This PoW would be the same as Bitcoin's today meaning adjusting to mining power. So the proof-block would take an approx. 60 minutes to mine. Could be more or less, but needs enough PoW attached. Miner of the PoW block would be forced to be honest (eg. not delaying broadcast to show it was harder) by the fact that anyone else can build this block who finds a good enough hash (again PoW) so delaying the block would risk loosing the block reward.

firstly there is no 'absolute' in regards to a 10min rule.
bitcoin has a special mechanism to control this. which this topic is missing

but anyways lets play the topics scenario out:
so delaying a broadcast of a block that can be made in 10 seconds. and telling it to wait another 9minutes 50 seconds is meaningless.  and not really achievable

as the next block signer onlist will happily love to see the previous block header early. because they can then start their own block signing before they should.
thus starting a chain of events where the next inlines get their blocks accepted by the next in line.
and the other nodes are then the ones waiting
EG if order was
0001 Aliceminer  12:00
0002 Bobminer   12:10
0003 Chadminer 12:20
0004 Daveminer 12:30
0005 EricMiner   12:40
0006 Fredminer  12:50

alice makes block at 11:50:10.. (timestamped 12:00) send to bob at 11:50:11
bob makes block at 11:50:20..(timestamped 12:10) send to Chad at 11:50:21
chad makes block at 11:50:30..(timestamped 12:20) send to Eric at 11:50:31
eric makes block at 11:50:40..(timestamped 12:30) send to Fred at 11:50:41

now lets say fred is the 'honourable one
its still only 11:50:41 so fred has the opportunity to make his own block by 11:50:50 based on eric header.
 
but now he is just honourably ignoring and pretending A,B,C,D,E dont exist yet(pretend ignorance for honour). and is waiting pretty much an hour twiddling his thumbs before he 'honourably' admits they already exist to then honourably broadcast his block at 12:50

reality is that all the 2016 designated miners would just make all 2015 blocks within 5 and a half hours of their first block session. and the rest of the network are then waiting upto 2 weeks before admitting the blocks already exist

this is a mega "empty" blocker risk/opportunity.. of 2015 blocks scheme in under 6 hours for the designated miners.. and then 2week self 'only seen at set time' pretend delay. for the rest of the network


.....
next flaw
 the person listed to be the 2016 blocker. who accumulates all the 'willing participants' of the next fortnight session. can easily put in his own 2016 (looks random) public keys as the list of 'who' gets to make the next blocks
thus winning all rewards
or
at very least ensure he puts his own key as the last key (the next 2016th block) to remain in control of the list each time(many exploits can be done here)

heck he could even do his 1 "hour" mining 13 days 19hours and 20 minutes before his special block is to be accepted. and already be working on the next 2016 block session he designated to himself. way way way before the rest of the network decide to admit the blocks existed for most of the fortnight
his only job for over 13 days is to just re-broadcast the set at the right time

and before you say it.. the 'special' blocker can have 2016 GPU(i presume you also trying to devolve back the hashpower to solo mining gpu) so that he can make all 2015 designated keys attached to an hours worth of hash labour each
and do that all within an hour(concurrent) of the 2008th block(end-7) which was created only under 7 hours from the start of the new 2016block cycle


in short
the designated miner(s) have the future 2015 blocks and the 2016th 'special block' with its 2016 separate 1 hour mining hashpower work.. all waiting in under 7 hours of the start... where the rest of the network are playing ignorant and only updating their blockheight in a slow timely manner over 2 weeks. finding out each block is an empty block in most cases

To clarify my point any miner could thrick the timestamp on the proof-block and all the nodes may not agree on what time it was posted so we may end up with a consensus problem. I think the solution is a PoW/PoS hybrid system where all the coins have to be mined in the first place then every holder has a vote on the next block. Unfortunately, Bitcoin's cultist can't understand that simple concept and Bitcoin's cultist don't like PoS for no reason but they can't stop anyone from creating a fork and call it "Bitcoin" because it'supposedly decentralized

No, the miner of the proof-block have collect all the hashes mined by all the others and order it (as he likes as order is not there until, well ordered). He needs all the hashes miners broadcasted in this one hour to produce a proof-block with all the 2016 blocks and attach the correct PublicKey of each miner to the select blockID. The incentive could be to have the right to mine first block of 2016 inlcuded to this miner of the proof-block. If this miner delays broadcasting the proof-block other will seconds later and he looses.

Indeed, miners could move to other SHA256 chains. But I doubt that any other chains can offer nearly enough reward to accommodate such a huge hash rate. I think most miners would just wait for the next proof-of work period to start in two weeks.

Indeed, I forgot the quotes around brilliant. But I added a smiley .

No it's not removing PoW. Current PoW is genius and is simple and is elegant, not to be replaced (maybe improved). It has some issues like fluctuation in block time and lot of work which I believe could be replaced without weakening the PoW. Again you would need the same amount of miners to earn the same amount of coins as today.