Bible Pay

Read 1781 times

  • Rob A.
  • Administrator

    • 1219


    • 20
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #15 on: February 18, 2018, 09:18:30 am »
Yes 51% attacks exists in any coin, only you propose to make the required CPU-power only 5.1% by asking 90% of the cycles to go to non-direct blockchain related workloads. Don't patronise me, I know very well what I am talking about, you might disagree with me but that doensn't make you right. I will help you with PODC by telling you, don't implement PODC in this way, and I have told you this often with valid reasons.

No sir, you dont know what you are talking about, because you are confusing reward levels with decreased security, while security has a 1:1 relationship to how much hash power is supplied against the front line network at a given time, and you continue to disregard DGW.  Do you have any experience with any of the top 50 cryptos, such as having multiple developers working for you?

Dont mislead our investors, and dont snap back and speak to me that way.  You've been warned.



  • Swongel
  • Newbie

    • 14


    • 1
    • January 29, 2018, 02:03:22 pm
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #16 on: February 18, 2018, 09:34:11 am »
No sir, you dont know what you are talking about, because you are confusing reward levels with decreased security, while security has a 1:1 relationship to how much hash power is supplied against the front line network at a given time, and you continue to disregard DGW.  Do you have any experience with any of the top 50 cryptos, such as having multiple developers working for you?

Dont mislead our investors, and dont snap back and speak to me that way.  You've been warned.

"Do you have any experience with any of the top 50 cryptos, such as having multiple developers working for you?"
No, neither do you.

Stay classy Rob.


  • Rob A.
  • Administrator

    • 1219


    • 20
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #17 on: February 18, 2018, 09:46:00 am »
"Do you have any experience with any of the top 50 cryptos, such as having multiple developers working for you?"
No, neither do you.

Stay classy Rob.


I do.





  • Swongel
  • Newbie

    • 14


    • 1
    • January 29, 2018, 02:03:22 pm
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #18 on: February 18, 2018, 09:53:46 am »

I do.

Well please enlighten me with which top 50 crypto project you have been working and what your contribution has been, which of their developers did you work with?


  • Rob A.
  • Administrator

    • 1219


    • 20
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #19 on: February 18, 2018, 09:59:54 am »
Well please enlighten me with which top 50 crypto project you have been working and what your contribution has been, which of their developers did you work with?

No.  I don't lie, and this is not about me.  Stick to the subject, and admit you were wrong about the 51% vector.
We have 12,000 miners now mining 202 blocks per day.
In the future, we promote CPID mining.
We will have 1000 miners (those are people that have access to the CPID signature), mining on controller wallets.
A reduction of 90% of the hashpower, means the POW difficulty will drop to Exactly its average.

All additional hashpower requires a SIGNED cpid.  With magnitude.  Meaning there is No random hashpower, which means we have a Decrease in volatility to the coin, and hence its risk. 

Therefore your analysis for a 51% above is incorrect.




  • Swongel
  • Newbie

    • 14


    • 1
    • January 29, 2018, 02:03:22 pm
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #20 on: February 18, 2018, 10:26:56 am »
No.  I don't lie, and this is not about me.  Stick to the subject, and admit you were wrong about the 51% vector.
We have 12,000 miners now mining 202 blocks per day.
In the future, we promote CPID mining.
We will have 1000 miners (those are people that have access to the CPID signature), mining on controller wallets.
A reduction of 90% of the hashpower, means the POW difficulty will drop to Exactly its average.

All additional hashpower requires a SIGNED cpid.  With magnitude.  Meaning there is No random hashpower, which means we have a Decrease in volatility to the coin, and hence its risk. 

Therefore your analysis for a 51% above is incorrect.

Yes and when 90% is off mining Rosetta@Home by simply sharing a single CPID with magnitude the botnet will mine with full capacity simply funneling their hash power through a single CPID giving them a huge advantage.

Yes the dificulty will drop indeed, but that's my whole argument, lower dificulty = easier for bot net to mine. Even with this "DGW" thich will do nothing but make the botnet have a single CPID. They could also just use CPID of other accoutnts and use that in their block, the blocks would still be valid; they wouldn't get a reward but they'd still only need 5.1% (relative to current hashrates) to launch a double spend.

I won't concede my argument, because it's a good argument, it is not an argument from authority, it is not a fallacy it is math.


  • Rob A.
  • Administrator

    • 1219


    • 20
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #21 on: February 18, 2018, 10:34:51 am »
Yes and when 90% is off mining Rosetta@Home by simply sharing a single CPID with magnitude the botnet will mine with full capacity simply funneling their hash power through a single CPID giving them a huge advantage.

Yes the dificulty will drop indeed, but that's my whole argument, lower dificulty = easier for bot net to mine. Even with this "DGW" thich will do nothing but make the botnet have a single CPID. They could also just use CPID of other accoutnts and use that in their block, the blocks would still be valid; they wouldn't get a reward but they'd still only need 5.1% (relative to current hashrates) to launch a double spend.

I won't concede my argument, because it's a good argument, it is not an argument from authority, it is not a fallacy it is math.

Ok conversation has improved slightly, thanks.

This vector is not possible because the Botnet would funnel all power to one cpid, then after they solve block #1, they will be unable to solve block 2,3,4, or 5.  (Because we have a rule in now that enforces Distinct CPIDs per set of 5)....   There will be a one in 1000 chance for each distinct researcher to jump in and solve block #2, partially because we limit each individual miner to 250 hashes per second (in prod now).  Yes I agree that botnet could then switch to CPID #2, but that  would raise difficulty up (as it is now, to 2500) choking themselves, and as I mention, our low nonce rule is Global:  Its not per machine - so You or anyone globally cannot solve a block at a rate of more than 250 HPS.  Meaning that each and every block gives the other 1000 participants a very high chance, a higher chance than your run of the mill crypto to solving that block.

Low Nonce + DGW + More private hashing = Lower volatility

It is a true statement that if a botnet were to attempt to share CPIDs, they would no longer be able to carry a 93% domination level....  Because we require distinct CPIDs per set of 5..... (CPIDs with magnitude....)

Bottom line is you should realize the setup here:  this ecosystem is safer than bitcoin...  in regards to 51% attacks...



  • Swongel
  • Newbie

    • 14


    • 1
    • January 29, 2018, 02:03:22 pm
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #22 on: February 18, 2018, 10:55:39 am »
Ok conversation has improved slightly, thanks.

This vector is not possible because the Botnet would funnel all power to one cpid, then after they solve block #1, they will be unable to solve block 2,3,4, or 5.  (Because we have a rule in now that enforces Distinct CPIDs per set of 5)....   There will be a one in 1000 chance for each distinct researcher to jump in and solve block #2, partially because we limit each individual miner to 250 hashes per second (in prod now).  Yes I agree that botnet could then switch to CPID #2, but that  would raise difficulty up (as it is now, to 2500) choking themselves, and as I mention, our low nonce rule is Global:  Its not per machine - so You or anyone globally cannot solve a block at a rate of more than 250 HPS.  Meaning that each and every block gives the other 1000 participants a very high chance, a higher chance than your run of the mill crypto to solving that block.

Low Nonce + DGW + More private hashing = Lower volatility

It is a true statement that if a botnet were to attempt to share CPIDs, they would no longer be able to carry a 93% domination level....  Because we require distinct CPIDs per set of 5..... (CPIDs with magnitude....)

Bottom line is you should realize the setup here:  this ecosystem is safer than bitcoin...  in regards to 51% attacks...

So they'll need 5 CPIDs not really solving the problem just making it a little harder. Even still they could just announce other people their CPIDs.
Also you cannot limit hashes/s, only valid blocks get announced therefor hashrates are not public knowledge, changing that 250 to a 250000 is trivially easy.


  • Rob A.
  • Administrator

    • 1219


    • 20
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #23 on: February 18, 2018, 03:25:38 pm »
So they'll need 5 CPIDs not really solving the problem just making it a little harder. Even still they could just announce other people their CPIDs.
Also you cannot limit hashes/s, only valid blocks get announced therefor hashrates are not public knowledge, changing that 250 to a 250000 is trivially easy.

Im flabbergasted that Im still talking to you.  Your credibility is really close to zero.

First, they cant announce their CPIDs, because you cant sign a CPID unless you own it.  So thats incorrect.  They can just share 5 across 10,000 machines and watch for the last used cpid.  It gets them nowhere.  Why would it?  Its just the legal way to heat mine across 5 cpids? So what.  Its not going to last as the reward is too low.  Its not a 51% attack vector!  You dont even know what that means.

Next, if we have the 12000 machines from the botnet sharing the 5 cpids, now what we have done is limited those 12000 machines to 1/5th the size in hashing power, (because only one botnet machine can solve a block every 5 blocks).  Which, will in itself not be sustainable for long periods, becuse the reward is too low, but even if it did, all that would do is lower our botnet average difficulty to 1000 from 5000.  What are they achieving?  Nothing.   But I just proved it *increased* security vs. the bitcoin model.  (With your own example).

You said I cant limit hashes?  Incorrect.  We do limit hashes in prod.  A block hash can only change with a timestamp or a nonce change.  Its more work to create a new block than update its hash (so much more work, that its not worth recreating a block for every hash change).  So now you are limited to 250 nonces per second, Or a timestamp change.  We have a timestamp limiter in the code, meaning that is not a vector.  So yes, we do limit the hashes per second.   




  • Swongel
  • Newbie

    • 14


    • 1
    • January 29, 2018, 02:03:22 pm
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #24 on: February 18, 2018, 04:05:45 pm »
Im flabbergasted that Im still talking to you.  Your credibility is really close to zero.

First, they cant announce their CPIDs, because you cant sign a CPID unless you own it.  So thats incorrect.  They can just share 5 across 10,000 machines and watch for the last used cpid.  It gets them nowhere.  Why would it?  Its just the legal way to heat mine across 5 cpids? So what.  Its not going to last as the reward is too low.  Its not a 51% attack vector!  You dont even know what that means.

Next, if we have the 12000 machines from the botnet sharing the 5 cpids, now what we have done is limited those 12000 machines to 1/5th the size in hashing power, (because only one botnet machine can solve a block every 5 blocks).  Which, will in itself not be sustainable for long periods, becuse the reward is too low, but even if it did, all that would do is lower our botnet average difficulty to 1000 from 5000.  What are they achieving?  Nothing.   But I just proved it *increased* security vs. the bitcoin model.  (With your own example).

You said I cant limit hashes?  Incorrect.  We do limit hashes in prod.  A block hash can only change with a timestamp or a nonce change.  Its more work to create a new block than update its hash (so much more work, that its not worth recreating a block for every hash change).  So now you are limited to 250 nonces per second, Or a timestamp change.  We have a timestamp limiter in the code, meaning that is not a vector.  So yes, we do limit the hashes per second.   

Because the person mining the block can decide what transactions can be in it, he can just fork off the main branch and undo transactions... The whole point of a 51% attack. So even if he couldn't get his hand on 5 CPID's which is trivially easy.

So the goal of the attacker isn't to get those coins, it's the goal of the attacker to race the main branch so they can un do transactions and thus double spend their coins. I know very well what a 51% attack is thank you very much.

Further more shuffeling around transactions every 250 hashes isn't a limitation, it's merely a simple shuffle attackers could easily create just 100 transactions each block to shuffle around a bit, thus changing the outcoming hash (even without being able to change the nonce).

I don't know why I'm even arguing with you either, it's not like you're going to listen. Maybe you should ask a security expert about this stuff, I would be dumbfounded if there's any security expert willing to go on record saying that this is even remotely safe for a crypto currency.


  • Rob A.
  • Administrator

    • 1219


    • 20
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #25 on: February 19, 2018, 07:24:23 am »
Because the person mining the block can decide what transactions can be in it, he can just fork off the main branch and undo transactions... The whole point of a 51% attack. So even if he couldn't get his hand on 5 CPID's which is trivially easy.

So the goal of the attacker isn't to get those coins, it's the goal of the attacker to race the main branch so they can un do transactions and thus double spend their coins. I know very well what a 51% attack is thank you very much.

Further more shuffeling around transactions every 250 hashes isn't a limitation, it's merely a simple shuffle attackers could easily create just 100 transactions each block to shuffle around a bit, thus changing the outcoming hash (even without being able to change the nonce).

I don't know why I'm even arguing with you either, it's not like you're going to listen. Maybe you should ask a security expert about this stuff, I would be dumbfounded if there's any security expert willing to go on record saying that this is even remotely safe for a crypto currency.

Unfortunately you havent proven anything new here, and most of this is incorrect.

A 51% attack would require more than 51% of the CPIDs, that was the statement I wanted you to make and you didnt.  Its literally impossible.

They cant fork off to another branch because of setbestchain, no client will follow that branch.

You discount the hardness to maintain a CPID with RAC.  Its not easy, try it, it takes a full node 1 day of work to get enough rac to be in the block.

Shuffling 250 transactions, Im sorry, wrong terminology, not possible, not related to what is in our code.  We deliberately only have left two fields in the getblockhash that can change the hash: nonce and timestamp.  Timestamp has an allowable window of 5 minutes in either direction from getadjustedtime, meaning we only allow 300 values (in seconds).  Nonce is limited (CheckNonce()) to 250 HPS globally.  You cannot submit a block to our network with a nonce > 251 for a block that is less than 61 seconds old.  Transactions have nothing to do with it.  This is indeed a security feature, and affects the conversation by 90%.  This alone + DGW prevents a 51% attack.  Were basically allow 99% of the hashes to pass through biblepay with no effect when they exceed the noncelimit.  To discount this effect to zero would be like ignoring the cornerstone of the building, its absolutely relevant as part of the base calculation for a 51% attack.

Regarding security expert, I am still working with Martin, but any real security expert is invited to take a look at the POW code, Im confident we are much more secure than the average POW implementation with the CPID restriction and the nonce limit in place, but this person will have to admit the weaknesses inherent in POW in the first place and make an honest comparison, not one that is biased towards removing the credibility for the other facets of PODC.  I admitted where the risks were in PODC, and Im basically telling everyone, we know the SQL database inside Rosetta is the weak point.  Lets find a way to create a tamperproof pill bottle for it, and make it more reliable.  I continue to say, I would rather live with Rosettas quirks than the current bitcoin status quo where 93% of the heat miners are now hogging the rewards and we have no control over upgrades.  Its a disaster, whereas PODCs environment is quite favorable.



  • Swongel
  • Newbie

    • 14


    • 1
    • January 29, 2018, 02:03:22 pm
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #26 on: February 19, 2018, 10:14:39 am »
Unfortunately you havent proven anything new here, and most of this is incorrect.

A 51% attack would require more than 51% of the CPIDs, that was the statement I wanted you to make and you didnt.  Its literally impossible.

They cant fork off to another branch because of setbestchain, no client will follow that branch.

You discount the hardness to maintain a CPID with RAC.  Its not easy, try it, it takes a full node 1 day of work to get enough rac to be in the block.

Shuffling 250 transactions, Im sorry, wrong terminology, not possible, not related to what is in our code.  We deliberately only have left two fields in the getblockhash that can change the hash: nonce and timestamp.  Timestamp has an allowable window of 5 minutes in either direction from getadjustedtime, meaning we only allow 300 values (in seconds).  Nonce is limited (CheckNonce()) to 250 HPS globally.  You cannot submit a block to our network with a nonce > 251 for a block that is less than 61 seconds old.  Transactions have nothing to do with it.  This is indeed a security feature, and affects the conversation by 90%.  This alone + DGW prevents a 51% attack.  Were basically allow 99% of the hashes to pass through biblepay with no effect when they exceed the noncelimit.  To discount this effect to zero would be like ignoring the cornerstone of the building, its absolutely relevant as part of the base calculation for a 51% attack.

Regarding security expert, I am still working with Martin, but any real security expert is invited to take a look at the POW code, Im confident we are much more secure than the average POW implementation with the CPID restriction and the nonce limit in place, but this person will have to admit the weaknesses inherent in POW in the first place and make an honest comparison, not one that is biased towards removing the credibility for the other facets of PODC.  I admitted where the risks were in PODC, and Im basically telling everyone, we know the SQL database inside Rosetta is the weak point.  Lets find a way to create a tamperproof pill bottle for it, and make it more reliable.  I continue to say, I would rather live with Rosettas quirks than the current bitcoin status quo where 93% of the heat miners are now hogging the rewards and we have no control over upgrades.  Its a disaster, whereas PODCs environment is quite favorable.

If you're not hashing transactions; then how can you even verify the transactions within an announced blocked were actually mined and not just announced by someone using the same hash? If you don't hash the transactions all your block chain is getting consensus about is the timestamp and nonce... except that in the current source the hashMerkleRoot also get's thrown in to the block, which  can be changed by shuffeling/adding/removing  transactions.

51% of CPIDs isn't required, unless magnitude constitutes discounted hashrate, in which case you'll have PoL, in which case you'll get the same problems as with PoL;  just build up magnitude and spend it all at once to get a row of blocks.

Furthermore, the "best chain" is the longest chain, the whole point of a 51% attack is to become the best chain by outpacing the other chain.


  • Rob A.
  • Administrator

    • 1219


    • 20
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: Proposal: Proof-Of-Distributed Computing as major reward algorithm
« Reply #27 on: February 19, 2018, 10:27:41 am »
If you're not hashing transactions; then how can you even verify the transactions within an announced blocked were actually mined and not just announced by someone using the same hash? If you don't hash the transactions all your block chain is getting consensus about is the timestamp and nonce... except that in the current source the hashMerkleRoot also get's thrown in to the block, which  can be changed by shuffeling/adding/removing  transactions.

51% of CPIDs isn't required, unless magnitude constitutes discounted hashrate, in which case you'll have PoL, in which case you'll get the same problems as with PoL;  just build up magnitude and spend it all at once to get a row of blocks.

Furthermore, the "best chain" is the longest chain, the whole point of a 51% attack is to become the best chain by outpacing the other chain.

Swongel,

You cant reshuffle the block without performing 100* the work of the biblehash.  The biblehash is intensive, but a PC can generate 1000 biblehashes per second, but cannot regenerate 1000 blocks per second, because of all the BIP checks for the memory pool transactions.  So this is incorrect.

We are hashing all transactions, of course.  Im saying we globally limit the nonce level per second.  In Checkblock.  So you cant get around it, and it does control how much hashing hits the front line activeChain best block.

Yes, 51% of the cpids are required, because we require a distinct signed CPID per block.  Meaning that the equivalent of a 51% hashpower attack requires control of 51% of the signed cpids.  Thats what a 51% attack is:  controlling the ability with the most liklihood to own the chain, and that would require 51% of the cpids.  Take a look at the requirements of a POW 51% attack before making assumptions that I am incorrect.

The reason a CPID with N magnitude does not need to equate to Y hashes per second for the CPIDs corresponding heat miners : is because one solved block with massive hashpower at that instance does not move the attacker closer to controlling our chain.  It moves them 1/CPID(Count) closer.  Which means my statement above, requiring you to control 51% of the cpids remains true.  Therefore the statement about POL is ignorant- POL is not necessary for this topic.  I am strictly addressing the inaccuracy of your original post: that this PODC implementation lowers security.  My response is:  No, it Raises security.

Higher magnitude does not give you a higher chance in solving blocks.  We require "A CPID with Magnitude" in each block, to solve the block at the current POW level (there are now two in the coin: PODC diff and POW diff).  So that is an incorrect statement that you can save up magnitude.  Your magnitude rewards come from the superblock daily, your heat rewards are what you receive when you solve a POW block.

Incorrect on the best chain.  The Best chain is the chain with the most chainwork.  See our chainwork algorithm.  The one in your attack with the alternate transactions has less chainwork, and is therefore not the best chain.  Thats why we stuck with POW for this implementation, to allow the core to follow the best chain easily and avoid the fork problems that *could be possible nuisances* with alternatives such as POS.