Jump to content

NEWS
  • WELCOME TO CRYPTOCURRENCYTALK!
  • We've upgraded the website with a lot of new features!
  • 3 NEW THEMES! Click on the + Themes button above!
  • Notice about SOCIAL LINKS: UPDATE YOUR SOCIAL LINKS
  • New video section, add your videos: VIDEO SECTION
  • Advertising will be available shortly, hold tight.
  • If you have any issues with the new site, please submit a support ticket: SUPPORT

Should we Re-Base Gridcoin using this proposal, or should we stay with current codebase and fix it using the Roadmap 4.0 proposals?  

36 members have voted

  1. 1. Should we Re-Base Gridcoin using this proposal, or should we stay with current codebase and fix it using the Roadmap 4.0 proposals?

    • Re-Base Gridcoin using this proposal (a variation of Dash-Evolution/Bitcoin Core Nov 2017 with a Stakeminer)
      24
    • Stay with Current Code Base and fix it Piecemeal using Roadmap 4.0 Proposals
      9
    • Abstain (I do not wish to be involved)
      3


Recommended Posts

 

JRINGO:

"

By my current understanding, masternodes centralize control of development with early adopters and financially wealthy entities.  This actively excludes the main target audience of the product from influencing the product's development.  To me, the target audience of Gridcoin is researchers, both by the literal definition and by our definition (people who contribute their Idle Processing Potential to BOINC).

 

6. Neural Network is hype.  If at some point the mechanism becomes a true neural network, we can always change the name back.  As it stands now, it is a buzz word that makes it difficult (impossible) to pitch Gridcoin to reputable research facilities, universities, and their researchers.  They know better.

"

 

You are welcome to your opinion on masternodes, but in Gridcoins case I believe our Neural Network will be a cross section of : Our GRC Researchers (70%) who happen to have high balances, and some investors (30%) who either BOINC themselves in the past, or just like the idea about Gridcoin.  Yes there will be some that come to Gridcoin to just earn ROI, but I see no reason those would be "the elite" representation of our neural network.  Maybe you can run a report from RTMs block explorer that grabs 50 balances > 500K and see if they trace back to CPIDS.  Ill bet you 70% trace back to CPIDs.

 

Regarding the Neural Network, no, we can do it the other way around.  I named it the neural network because I envision it to be a decentralized credit gathering system that provides historical reports.  If it did that now, and intelligently merged the data and then provided  consistent service, I guarantee the most advanced research facilities would support what we call "our  neural network".  But, I take your Single Opinion into account, and CMs single opinion into account, and realize both of you hold a vote of 2 out of our BROAD Cross Section of thousands of users.  And I politely disagree with your assessment.  Its called the Neural Network, so please, vote the proposal down.

 

Regarding POW, please read above; its not POW its a green CPU miner.  Its proof-of-lack-of-work.

 

Regarding "proof of research", that is exactly what this proposal does.  The Neural network votes to prove the current boinc stats are accurate and the client emits a superblock.  If we want to call our CPU miner POR by grabbing a Neural Network daily guid and adding it to the mining hash, that would be great, I dont mind calling our miner a POR miner and our POSE POSE.  

 

Regarding scaling, I have a PDF here somewhere where dash was audited.  To the best of my knowledge, one superblock could scale to about 10000 recipients without a problem.  Thats the entire boinc network anyway (with RAC > 0 and Payment owed > 0), but even If we reach near the cap we can have more than one superblock per day.  I already tested that, and it works, by changing the block modulus frequency.  Not something we need to worry about.

 

Yes, I actually have code for my testing that I performed.  Its not documented in a formal document.  

 

 

 

 

Share this post


Link to post
Share on other sites
3 minutes ago, Rob Halförd - (Gridcoin) said:

Maybe you can run a report from RTMs block explorer that grabs 50 balances > 500K and see if they trace back to CPIDS.  Ill bet you 70% trace back to CPIDs.

 

RTM's block explorer is dead.  Also I'm not sure you're correct on that 70% number.  Maybe 50%.

 

Quote

But, I take your Single Opinion into account, and CMs single opinion into account, and realize both of you hold a vote of 2 out of our BROAD Cross Section of thousands of users.

 

Add my opinion to that list too.  A lot of people feel the name "Neural Network" is a buzzword.

 

Quote

Regarding POW, please read above; its not POW its a green CPU miner.  Its proof-of-lack-of-work.

 

This is dishonest at best and you know it.  There is no such thing as "green" Proof of Work.

Edited by barton26

Share this post


Link to post
Share on other sites
9 minutes ago, barton26 said:

 

RTM's block explorer is dead.  Also I'm not sure you're correct on that 70% number.  Maybe 50%.

 

 

Add my opinion to that list too.  A lot of people feel the name "Neural Network" is a buzzword.

 

 

This is dishonest at best and you know it.  There is no such thing as "green" Proof of Work.

 

 

Ok, Research Statistics Network RSN is really not bad, but I dont want to give up on Neural Network yet, because RSNs don't sound to me like good terminology for masternodes, it sounds like a drab term for a small subset of nodes that do stats.  Neural has some type of intelligence and alludes to receiving information, and the masternodes will definitely vote and communicate with each other.  But I do respect your opinion and it has potential to change my mind, but I think the neural network is still good in the sense of re-branding the masternode network.

 

On the 50%, maybe so, but also consider the total percent who have had cpids at one point.  

 

On the POW, I partially agree with you here.  I dont want anything in the client that is misleading or close to POW.  Either way, this proposal is based on a green cpu miner that is not using classic proof of work, which is solving a block based on the most hashes done.  Its either using reverse proof of work, or in its core something similar to POS3.0.  

 

 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

Good to see you again Rob, I think we have been desperately in need of your presence over the last little while. 

 

Regarding the proposal, would we not be open to a greater possibility of 51% attack with masternodes assuming the attacker was willing to pony up the grc to become the masternodes? This seems like a step backwards in terms of security as well as decentralization. 

 

Regarding the new green pow mechanism, would this actually result in a net decrease of cpu/computing power required for running the grc network? 

Share this post


Link to post
Share on other sites

Rob:

 

Thank you for all of your efforts regarding the Gridcoin blockchain.

 

I have a few questions,

 

How would implementing all of these proposed changes at once be preferable over doing them piecemeal?

 

I see the Masternode idea as a step backwards creating a more centralized system, I.E. one where significant resources are required to participate and the only way to benefit is with having an economy of scale.  What are your thoughts on this?

 

If the credit delta idea is to be implemented, how would this change the payout mechanism and the payouts rewarded? Please provide an example using 4,000 GRC and a 75 magnitude under current system.

 

Regarding the voting mechanism, I think that the balance+magnitude method of share determination allows for those who hold a great deal of coins or magnitude to be unfairly represented. Usually that would make sense to allow for those who have the most to lose have the most say. However in this case, voting in this manner might alienate the rest of us in this community. I would propose that the poll be redone based on the CPIDcount or ParticpantCount to have an accurate view of what each stakeholder considers to be the correct course of action. I will use the current poll regarding this subject as an example, did 4 voters with 250,000 magnitude+balance  respond no and 1 voter with 18 million magnitude+balance respond yes? Is there a way to determine this? If this technology is suppose to be innovative, should it not act in an innovative way? (I.E. not like the current system that is prone to abuse by those with higher resource access.) Thoughts?

 

I just staked a block with 1.5 difficulty for the first time. (Usually this would crash my wallet). I feel a sense of pride helping to secure the network and it feels even better to be rewarded for it. In contrast, I spent months downloading the Ethereum block chain and received nothing but a full HDD. How can I continue to help  without having to spend ~4,000 - 16,000 USD? In addition, could you please provide an amortization schedule of the return on investment on the Masternode idea?

 

I agree that taking 661MBs of physical memory to run the wallet is absurd. How would your proposal address this?

 

Final Thought:

 

As a influential individual in the Gridcoin community please increase the visibility of this proposal by posting this discussion on Steemit, where many Gridcoin stakeholders go for information.

 

Best Regards,

 

Prescott

Share this post


Link to post
Share on other sites
2 minutes ago, Gridie said:

I would propose that the poll be redone based on the CPIDcount or ParticpantCount to have an accurate view of what each stakeholder considers to be the correct course of action. I will use the current poll regarding this subject as an example, did 4 voters with 250,000 magnitude+balance  respond no and 1 voter with 18 million magnitude+balance respond yes? Is there a way to determine this? If this technology is suppose to be innovative, should it not act in an innovative way? (I.E. not like the current system that is prone to abuse by those with higher resource access.) Thoughts?

 

First off, the 1 user with 18 million GRCs who voted yes was Rob's Investor wallet.  Secondly, we cannot have a poll utilizing CPIDcount or ParticipantCount as a means of deciding anything because they are easily gamed.  A user could create multiple wallets with multiple CPIDs and vote as many times as they wanted.

Share this post


Link to post
Share on other sites
1 minute ago, barton26 said:

 

First off, the 1 user with 18 million GRCs who voted yes was Rob's Investor wallet.  Secondly, we cannot have a poll utilizing CPIDcount or ParticipantCount as a means of deciding anything because they are easily gamed.  A user could create multiple wallets with multiple CPIDs and vote as many times as they wanted.

 

First, that makes sense. Second, I can see that occurring, but there could be some controls put into place to account for this potential situation. One I am aware of is that have to be present in the chain for a certain amount of time before you can vote on something. @barton26 you are right though that it can be easily gamed if someone was prepared to do it. Thanks for the reply.

Share this post


Link to post
Share on other sites
9 hours ago, Rob Halförd - (Gridcoin) said:

PoSE mining does not reduce the security of the blockchain, since difficulty still exists.  If one were to increment nonces faster and go for the lower reward, the diff would rise and they would be unable to continue doing that on the next block. 

I think we only need two rules to implement POSE mining:  a sliding 1-9% reward based on the nonce value (lower is higher payout meaning you can solve the block by waiting for seconds to tick by), and a decreasing difficulty ADJUSTMENT [to the current difficulty] for each minute elapsed from pblocklast->pblockcurrent.  Since we have 2.5 min block targets, the block would be in a range of 0% - 90% easier to solve per minute that ticks by, increasing in easiness by 10% per minute.  This pblockcurrent-pblocklast diff adjustment parameter is a hard parameter - it is Not a security problem to do this, we just have to enforce block max elapsed to be 15 mins max in the future.  These two rules should implement POSE quite well.  So far I have not heard anything alarming here.

There is no difficulty re-targeting algorithm that could keep up with the sudden hashrate changes an attacker could bring. Especially not if the attacker mines selfishly and then quickly releases his found blocks without other miners even noticing and being able to compete with him on the same level (as was done in a livenet attack as well). 


But lets go through a likely scenario for arguments sake and even disregard selfish mining. Someone is mining much faster than everyone else, finds a block with a low blocktime and therefore greatly increases the difficulty. Now two things can happen. He either stops mining and waits for the difficulty to decrease sufficiently again and then starts his attack again, with little cost to himself and potentially large disruption to everyone else, since the next block after his high diff block will take very long to be mined.


Or, he makes use of that it is unexpected to iterate into higher nonces (as it was the case in pre V8 gridcoin and then successfully exploited). His modified miner would potentially be orders of magnitude faster than any built-in miner of gridcoin and able to outperform others even with increased difficulty. Again, this is what happened already this year and clearly demonstrated, that building in a weak proof of work nonce  into the consensus mechanism will lead to successful attacks against the network.

Edited by TheCharlatan

The Charlatan

Share this post


Link to post
Share on other sites

First of all I would like to point out that the proposed 400000 GRC needed for a masternode are not burned or anything. This was mentioned several times on slack and it is simply not true. To run a Dash Masternode you simply have to hold a balance of 1000 dash in your wallet. You can move/sell your coins at any time but once your balance drops below the threshold your node isn't considered a masternode anymore.

 

Rob, I don't think the decision about the number of coins a masternode needs to hold is trivial. I don't think dash just picked a randomn number. It is a way to control the number of masternodes. For Dash the possible number of master nodes is about 7000 and for PIVX (a Dash fork) it is 5000. I think Gridcoin should use these numbers as an orientation. With 780000 GRC we can get about 5000 Masternodes at the current coin supply. For Gridcoin the limitation of masternodes is very important to reduce the load on BOINC servers.

 

I have not looked into PoSE but would gridcoin be the first currency to implement it for block creation? I think we should stick to well tested concepts for the consensus algorithm. PIVX(a Dash fork) uses PoS so it should be easy for us to switch to PoS with the Dash code base.

 

Regarding the name "Neural Network", I am in favour of "Magnitude Network" since it describes the purpose of gathering the users magnitudes. 

Edited by huppdiwupp

Share this post


Link to post
Share on other sites
6 hours ago, Gridie said:

Rob:

 

Thank you for all of your efforts regarding the Gridcoin blockchain.

 

I have a few questions,

 

How would implementing all of these proposed changes at once be preferable over doing them piecemeal?

 

I see the Masternode idea as a step backwards creating a more centralized system, I.E. one where significant resources are required to participate and the only way to benefit is with having an economy of scale.  What are your thoughts on this?

 

If the credit delta idea is to be implemented, how would this change the payout mechanism and the payouts rewarded? Please provide an example using 4,000 GRC and a 75 magnitude under current system.

 

Regarding the voting mechanism, I think that the balance+magnitude method of share determination allows for those who hold a great deal of coins or magnitude to be unfairly represented. Usually that would make sense to allow for those who have the most to lose have the most say. However in this case, voting in this manner might alienate the rest of us in this community. I would propose that the poll be redone based on the CPIDcount or ParticpantCount to have an accurate view of what each stakeholder considers to be the correct course of action. I will use the current poll regarding this subject as an example, did 4 voters with 250,000 magnitude+balance  respond no and 1 voter with 18 million magnitude+balance respond yes? Is there a way to determine this? If this technology is suppose to be innovative, should it not act in an innovative way? (I.E. not like the current system that is prone to abuse by those with higher resource access.) Thoughts?

 

I just staked a block with 1.5 difficulty for the first time. (Usually this would crash my wallet). I feel a sense of pride helping to secure the network and it feels even better to be rewarded for it. In contrast, I spent months downloading the Ethereum block chain and received nothing but a full HDD. How can I continue to help  without having to spend ~4,000 - 16,000 USD? In addition, could you please provide an amortization schedule of the return on investment on the Masternode idea?

 

I agree that taking 661MBs of physical memory to run the wallet is absurd. How would your proposal address this?

 

Final Thought:

 

As a influential individual in the Gridcoin community please increase the visibility of this proposal by posting this discussion on Steemit, where many Gridcoin stakeholders go for information.

 

Best Regards,

 

Prescott

Hi Gridie, 

Doing the rebase all at once removes a lot of IT overhead and barriers and straightens the path for some of the higher challenges.  For one, we have to implement the piecemeal solutions in more of a custom coded way using the old codebase as it has veered off from the latest bitcoin base.  Two the Dash base with the right abstraction design for Gridcoin solves almost every fundamental issue on the complaint list.  Three doing it all at once, split between a few core devs means it would actually meet a deadline - I think we could hunker down for 30 days and come back and have a version for Testnet (for all of us to test) and then actually make it into a release. 

 

I dont view the masternodes as a step back- I do view them as a step forward (speaking in a non-biased fashion).  They primarily enforce a proof-of-service backbone, something we dont have now, and provide a mechanism for secure voting for the total credit delta file, something that is currently tricky- the ROI portion of this proposal is similar to replacing our current POS interest rewards with a different mechanism for investors.  The success level of Various Masternode coins (not just dash) has been great also, giving me the impression that when investors have a propensity to leave the GRC invested in the escrow lease, and receive ROI they tend to not withdraw and spend it which in turn is good for our price.  These are 3 big pluses compared to other possible solutions.

 

(On a side note someone above asked about Burning the GRC and being able to take it out and stll be a masternode.  Heres how that part works.  When you want to be a GRC neural node, if the requirement is 250,000, you issue some commands (we will have a wiki) to generate a Neural keypair, IP address and port, a wallet address, and a command to send your own GRC to your own escrow address that you control. The funds get locked when you boot and coin control wont let you spend it by default.  As long as your IP is up and those exact funds are sitting in the same TX, you receive neural rewards.  To relinquish your seat, you go into coin control and Unlock the funds and deliberately spend them back to yourself.  Now you have your money back, but the neural network removes you from the list at that point during the next Pose bulldog event).

 

On Credit Delta, we aim to simplify the entire payment system.  If you had 4000 grc and a 75 mag currently, lets say you just boinc Rosetta.  If your day 1 credit is 1000, and on day 2 it is 2000, the network would log a +1000 gain over 24 hours for your CPID.  Lets say that results in a 77 mag for your cpid on day 2 (and it was 75 on day 1).  The TCD system will write a file with every CPID, PubKey Payment Address, Magnitude and Amount and send that into the core of the NN for sigs.  So what happens is we divide the 50,000 GRC daily reward by all those participants in the file, and lets say that gives you 25 GRC for the day.  The superblock would contain a payment to you that is dropped right into your wallet (even if you are not online) for 25 grc.  Since this is similar to a POR reward it is signed by the NN and doesnt need sign by you- it is exactly like receiving GRC from a friend while wallet is offline.  So you can see how efficient this gain would be for us.  It moves all the work to the NN from the core of the wallet.    

 

This is in response to another post I just read, about taking the escrow requirement seriously.  Ive actually created a program that did that, and ran the numbers, and it turns out that regardless of what escrow level is decided  (IE 50,000 for a seat or 500,000 for a seat) the GRC price gets canceled in the equation, and the Node Count ends up being determined by "average cryptocurrency investor appetite for ROI" believe it or not.  So is a fallacy to think that if I pick 50,000 its going to make an insecure network, or if I pick 500,000 now we are insecure because we have less nodes.  No, avg investor ROI drives the NN node count with external full IPs.  Any number over 250 nodes is going to make us a strong global network, and it appears the averages will bear out to be 250+, since we have been around for a few years we already have a large distribution footprint (of GRC per distinct user).  Regarding the ROI, that ends up being purely a function of node participation count. (BTC price and exchange price are canceled in this equation).   So in a nutshell, no matter what escrow we pick, we are going to have about 200-500 NN nodes due to the charactestic above, and regardless of actual entry price.  Entry price and complexity of the system will slow the adoption and go  live rate however, yes.  Thats true with anything.

 

Note that in this rebase, if you are a researcher, one does not need to have a minimum GRC balance to get paid (except 1 grc for iFoggz associator page).  You do not need to be part of the NN.  You would run boinc and receive 60% of every block, allocated by magnitude automatically.  And you would occasionally receive up to 10% of the 'mined blocks' while online (randomly mining an actual block).  

 

 

Share this post


Link to post
Share on other sites
3 hours ago, huppdiwupp said:

First of all I would like to point out that the proposed 400000 GRC needed for a masternode are not burned or anything. This was mentioned several times on slack and it is simply not true. To run a Dash Masternode you simply have to hold a balance of 1000 dash in your wallet. You can move/sell your coins at any time but once your balance drops below the threshold your node isn't considered a masternode anymore.

 

Rob, I don't think the decision about the number of coins a masternode needs to hold is trivial. I don't think dash just picked a randomn number. It is a way to control the number of masternodes. For Dash the possible number of master nodes is about 7000 and for PIVX (a Dash fork) it is 5000. I think Gridcoin should use these numbers as an orientation. With 780000 GRC we can get about 5000 Masternodes at the current coin supply. For Gridcoin the limitation of masternodes is very important to reduce the load on BOINC servers.

 

I have not looked into PoSE but would gridcoin be the first currency to implement it for block creation? I think we should stick to well tested concepts for the consensus algorithm. PIVX(a Dash fork) uses PoS so it should be easy for us to switch to PoS with the Dash code base.

 

Regarding the name "Neural Network", I am in favour of "Magnitude Network" since it describes the purpose of gathering the users magnitudes. 

Hi Hupp, 

 

Thanks!  I agree.  I ran a sim on the escrow entry level (please see Gridies post above).  

 

We would Not be first for PoSE.  Dash invented PoSE, and enforces it in prod.  I am running it now in my testnet and it does securely enforce PoSE by placing a node at the tail end of the payment queue if they violate it.  (On a side note here is an example of violating PoSE: If you decide to lease a neural node and set up your home dynamic IP as the static IP, lets say your kids start playing games on that server and reboot it, once you miss the PoSE call, that node gets placed to the back of the payment queue).  So its recommended we have a wiki page with complete instructions on compiling gridcoind on a brand new vultr rented node for $10 a month, and adding both of our programs to it and running it that way in the cloud).

 

Im thinking in the future, once we get to HTLC transactions we might be able to get the Neural Network node to run a lightning network server for us and share bitcoins price in the local database, so Im stll leaning towards a more intelligent neural network that can do things as "gridcoin assets" to give us more future VAR.

 

 

Share this post


Link to post
Share on other sites
7 hours ago, donkeykong9000 said:

Good to see you again Rob, I think we have been desperately in need of your presence over the last little while. 

 

Regarding the proposal, would we not be open to a greater possibility of 51% attack with masternodes assuming the attacker was willing to pony up the grc to become the masternodes? This seems like a step backwards in terms of security as well as decentralization. 

 

Regarding the new green pow mechanism, would this actually result in a net decrease of cpu/computing power required for running the grc network? 

You too, thanks!  

The 51% attack is primarily an issue for coins where the miners who are owned by an unfair minority control a massive amount of the hashpower, such as those large mining groups mining against bitcoin.

 

We on the other hand start with a minimum of 2000 distinct users, and lets suppose we translate that base into 500 masternodes.  This is a very, very accurate guess based on the ROI simulation.  (Based on the fact that if we only had 250 neural nodes in year 1, some investors would come out of the woodwork to fill the void to achieve the 2 year ~ ROI figure roughly).  

 

With that many distinct masternodes, the cost of the attack would be prohibitive by an outsider.  The outsider would have to buy enough GRC to control more than 125 masternodes if we had 250.  Then they would need to deliberately vote superblocks in that were fraudulent, in order to gain 50,000 GRC they would have exceeded that cost per day running the masternodes themselves that they bought, so it appears to be a fruitless endeavor.

 

I believe the reason for that is we have never had a mining environment subject to control by a minority of hashers - since the avg boinc account seems to be 2-15 servers etc, so that part is awesome.

 

On the green miner, Charlatan just raised a good point and Ill go into that part in a minute, but theoretically the cpu consumption would be the same as the existing stakeminer in the current client.  

 

 

Share this post


Link to post
Share on other sites
6 minutes ago, Rob Halförd - (Gridcoin) said:

On Credit Delta, we aim to simplify the entire payment system.  If you had 4000 grc and a 75 mag currently, lets say you just boinc Rosetta.  If your day 1 credit is 1000, and on day 2 it is 2000, the network would log a +1000 gain over 24 hours for your CPID.  Lets say that results in a 77 mag for your cpid on day 2 (and it was 75 on day 1).  The TCD system will write a file with every CPID, PubKey Payment Address, Magnitude and Amount and send that into the core of the NN for sigs.  So what happens is we divide the 50,000 GRC daily reward by all those participants in the file, and lets say that gives you 25 GRC for the day.  The superblock would contain a payment to you that is dropped right into your wallet (even if you are not online) for 25 grc.  Since this is similar to a POR reward it is signed by the NN and doesnt need sign by you- it is exactly like receiving GRC from a friend while wallet is offline.  So you can see how efficient this gain would be for us.  It moves all the work to the NN from the core of the wallet.    

 

Total Credit Delta, TCD, is awesome! Please see Brod's suggestion with regard to bunkering and TCD. Finally, note that TCD can be implemented without Superblock Payments. 

 

10 hours ago, Rob Halförd - (Gridcoin) said:

I have a PDF here somewhere where dash was audited.  To the best of my knowledge, one superblock could scale to about 10000 recipients without a problem.  Thats the entire boinc network anyway (with RAC > 0 and Payment owed > 0), but even If we reach near the cap we can have more than one superblock per day.  I already tested that, and it works, by changing the block modulus frequency.  Not something we need to worry about


Regarding the scaling of Superblock Payments, does this mean that it is possible to scale in terms of block size? Can it also scale to this level in terms of computation required to calculate everything required for each of the 10 000 recipients? Could you, please post (or link) the pdf of the Dash audit?

Share this post


Link to post
Share on other sites
4 hours ago, TheCharlatan said:

There is no difficulty re-targeting algorithm that could keep up with the sudden hashrate changes an attacker could bring. Especially not if the attacker mines selfishly and then quickly releases his found blocks without other miners even noticing and being able to compete with him on the same level (as was done in a livenet attack as well). 


But lets go through a likely scenario for arguments sake and even disregard selfish mining. Someone is mining much faster than everyone else, finds a block with a low blocktime and therefore greatly increases the difficulty. Now two things can happen. He either stops mining and waits for the difficulty to decrease sufficiently again and then starts his attack again, with little cost to himself and potentially large disruption to everyone else, since the next block after his high diff block will take very long to be mined.


Or, he makes use of that it is unexpected to iterate into higher nonces (as it was the case in pre V8 gridcoin and then successfully exploited). His modified miner would potentially be orders of magnitude faster than any built-in miner of gridcoin and able to outperform others even with increased difficulty. Again, this is what happened already this year and clearly demonstrated, that building in a weak proof of work nonce  into the consensus mechanism will lead to successful attacks against the network.

I do agree with you, that we need to prevent any replay of these things you raise, such as the inherent vulnerability of POS2.0 (where attacker creates hundreds of UTXO VOUTS by splitting their coins into tiny coins), and preventing childish attacks against the network to gain the 10% mined block autonomously.  And I dont want to make the assumption that if we lower the mining reward down to 1% that everything is "solved", nor is it a good solution to turn us into a hybrid POW coin with the "option" to mine if you want to.

 

The entire proposal is solid,  and this particular green-cpu-miner issue is the only piece of it that is still in its "conceptual" phase.  

 

Let me go to the drawing board and propose a more detailed plan for this so we can work out this remaining issue along the way.  Everyone be advised this green-cpu miner with 1% proc utilization will become a reality in testnet and we will find a solution to make it secure and not a nuisance before going to prod.

 

Im going to raise a quick idea and then do a little research but here is a new conceptual solution to the problem now :

 

Let us make the assumption that the X11 algorithm suite have now been modified to Not run in an asic (this is to assume that on day 1-365 in prod the entire system starts by running on CPUs) and the hash is now called a POR hash (not x11) since it has been fundamentally modified.

iFoggz CPID association system requires a successful burn of 1grc to associate a beacon.  It also includes a feature to not allow the burn to enter the chain unless the CPID is found to be valid by every foreign node in the memory pool (meaning attackers cannot just create random burns with fake cpids) and spam the list. 

Let us assume to mine a block, one must sign it with a scriptSig that is associated to a burned beacon (if one wants to mine a block in a green fashion).

Let us assume the wallet keeps a map of BeaconScriptSigs ordered by <int height, Beacon-ScriptSig> descending, meaning we know how recent a CPID mined a block.

Let us assume the hashtarget is influenced by the Age of the last mined BeaconScriptSig for the researcher.

Meaning that the longer it has been since a CPID mined a block, the easier it is for that CPIDs script sig to mine a block.

An empty BeaconScriptSig (IE for an investor) would be treated as Age Max, meaning it would be similar to brute force attack on the block (IE pure POW).

An associated BeaconScriptSig would result in influencing the targethash by age of the last paid BeaconScriptSig.

Brute forcing a block through POW would require computing power of let us say, one day of work on the reference machine, while Beacon associated work would influence the hash to be one hour.

 

In this way, blocks would be solved in 2.5 mins consistently, with the existing DGW diff, however targethash is modified by Researcher Last Paid age,

and would result in block payments iterating mostly in the order of researcher paid age, and this would offer no advantage for one to create a new key to try to mine outside of the researcher scope.

Creating multiple CPIDs: Make a new CPID equal to max age.  It will not hurt the researcher as their payments are airdropped anyway.  Removing new CPID attack vector from this.

 

So I think in light of what you raised Charlatan, this would be the enhancement we would add to our green miner and we could then call it a green-POR-miner, since it is primarily CPID based and would have a custom POR hashes.

It would allow mining at minimum speed, and would result in payments iterating in order of payment age.

 

The diff level could be set in a way to ensure brute forcing the blocks is very tough.

 

Thank you for reminding us of the complexity of the problem, and I am committed to solving this in a novel and secure way for our community!

 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

By using CRYPTOCURRENCYTALK.COM, you agree to our Terms of Use.