 Show Posts
|
|
Pages: [1]
|
You said we cant enforce blocks solved by a CPID as anyone can forge the CPID:
-> Sorry, but this is also not true. Here is proof:
A) User signs up for Rosetta, as a cancer-researcher, receives a CPID. B) User associates CPID with Biblepay using our UI - this creates a burn transaction signed by their public BBP key. B1) Burns do not enter the chain unless verified as Owned by the owner (see our CPID advertisement protocol). C) We require CPIDs to POW-mine in the future. D) User must sign the blockindex with their public key and CPID and signature. E) Other nodes reject blocks that are not signed. F) No CPIDs may be re-used for a minimum of 10 blocks.
A) Easily done
B) So far no problem for the bot net
B1) Still no problem
C) They still got plenty of CPU to PoW mine
D) They will have both so they can do this
E) They won't be rejected because they will have steps A-D
F) Not a problem they will have multiple CPIDs
Botnet Busted. They cant mine, and they cant perform a 51% attack (because of DGW and the limiter rule).
They can easiliy split their hash power among as many virtual nodes as they'd like completely bypassing any such limit and still launch a 51% attack.
Only now most of the CPU power in the network is working on BOINC and not protecting the network against 51% attacks.
Swongel, you are acting like we are all idiots here. Everyone here can see through your one sided view - and we know you hate distributed computing already. You arent giving an inch, and that proves its not an intelligent conversation to enter into, its one sided FUD. On your CPID example above, that the botnet can split up CPIDs, no they cant. Of course, trying to be succinct I didnt fully clarify above "all cpids must have a minimum of 10 rac" OK, let me clarify, then all CPIDs that are heat mining must have 10 RAC. Its just not going to happen, because every CPID will take a minimum of a few days to generate 10 RAC, then its not a valid advertised DCC until its associated in the chain, and they just are not going to do it. If they take the time to maintain 10 RAC, then there *is* a valid machine behind that cpid, researching cancer. Btw: that is the difference between "hard" and "easy". Your attack is not "easy" but "hard" now. The bot net consists of multiple machines, if their hash power is too great they can split by making virtual machines. This doesn't take away any of the concerns I have raised, you simply delete my post and ignore the problem. Valid concern is not FUD it is valid concern, saying I'm biased, not giving an inch, all my posts are FUD these are simply personal attacks, fallacies I won't consider them as a valid argument. You haven't provided any argument against the problems, nor will you be able to because decentralised consensus cannot depend on trust. You cannot centralise a crypto currency on a single organisation especially not if they did not accept the position of responsibility. I'll leave a link to a mirror of my previous post: https://web.archive.org/web/20180209120532/https://bitcointalk.org/index.php?topic=2388064.msg29924334 |
|
|
|
Please see inline:
FUD by Swongle:
- Bible pays can be used to set up Master Nodes effectifely granting voting rights to those who are able to mint coins.
-> The sanctuaries job is to vote on the authenticity of the distributed credit file(s) as a whole. Since the algorithm is ranked, no particular sanctuary could predetermine when it will be their job to perform the function. The chances as pointed out by Duffield for such attack are lower than .10%, because of the number required for a net yes. So the statement is misleading. The correct statement is "We as a network will trust 10% of the sanctuaries to verify the Distributed Computing files for authenticity". If one rogue actor fraudulently creates a file, 99% of the other sancs will vote it down. So in reality we are only going to assimilate the official file, created by the distributed boinc network. The users will be paid their fare share of cancer research based on this assimilated and voted file.
The sancturaties cannot tell a fake file from a real file since they cannot verify that the reasearch has actually been done.
->-> Your assumption is that Rosetta will approve 'hacked' work units, my assumption is there is no evidence that boinc work units have *ever* been hacked (for Rosetta), and that program, being 100* larger than the bitcoin miner, creates complex solutions that hackers are not going to replicate.
So therefore, yes, Sanctuaries *will* with 99.9% accuracy verify the credits presented in that file. You cant break a hash and falsify a file coming from a network of 1 MIL users. If you have evidence of this, post a link to how to crack a Rosetta work unit instead of spreading more FUD.
It still goes against the principle of decentralisation, BOINC doesn't even need to be hacked they can publish fraudulant number theirselves if they wish so, someone could black mail them to do so or they might not even notice being hacked and at this very moment be infiltrated the point is there is no way to know.
We cannot verify this, therefor we cannot trust this, therfor we should not use it in a trustless consensus protocol.
- Making BOINC a central authority for deciding who gets Bible pay subsidies making them a single point of failure and allowing for fraudulant non-verifiable transactions.
-> There will be no central point of failure in biblepay, because if the BOINC network or Rosetta goes down, Biblepay stays up while the heat-miners, the PoBH miners continue block checking. Next, there is a distributed web farm on the server side of Rosetta verifying the Cancer Solutions. (Not a single point of failure). We do not directly ask for your solution credit from those servers. Those servers have a backlog, and a proven 99.9% uptime, and simply approve work units in a queue. We actually ask the distributed network for the entire file so that those machines could be down and we could be UP on the DC side. The only way DC goes down is if 10% of our sanctuaries ALL fail to download the distributed computing credits, consecutively, once every 15 minutes for 23 hours. Then DC goes down. AND I Do Not have to send a Spork In to disable PODC. Its automatic. (More FUD).
A single point of failure in the research system is still a single point of failure. The single point being the BOINC organisation. Banks have great track records with security yet crypto currency chooses to not let them be the single point of failure to depend upon.
The network may switch to PoW the 90% reward will still be voted on by the sancturaties, who can as stated above not confirm the validity of the record file.
->-> In all of Gridcoins history BOINC has not gone down yet, ask them. They had a couple projects go down (the ones running out of their houses), but not Rosetta or World Community Grid or any of the top projects. Again, I dont care if the projects went down once a month, its still 93% better than Bitcoin Heat Mining with a BotNet in existence.
I would advice them the same thing for the same reasons, past results is no guarentee for future performance.
It is not better, the bot net would still own the same proportion of CPU-resources they can use in the evry same way they do now. Implementing BOINC does not solve this.
- Depending on the developer to spork whenever something goes wrong makes the sole developer a single point of failure.
-> Actually for issues like complete network failure of Instant Send, Soft Forking, and Enabling the switch for PODC and Disabling PODC, I do have the right to Execute a SPORK, but that is because I am the sole github contributor. I started the github, and there is a certain inherent level of trust you must assume, that I will not insert a Virus into github, or do anything nefarious that will kill Biblepay. You have my word that I will never do anything to hurt biblepay, and this is an issue in all baby cryptos that have just been birthed: How many years did it take Sunny King to turn control over to "the community", or BlackCoin? A few years. I am in the process of interviewing devs right now. I promise that eventually, we will have 7 devs with spork signing rights (the good ones who know what they are doing).
"certain inherent level of trust you must assume". No. Read Satohshi's white paper it cery clearly states crypto currency is about trustless consensus.
If we are willing to assume trust we might as well be using banks, they too have a very good security record by the way and 99.9% uptime.
->-> This proves you should move on, because the bottom line is Satoshi had this type of access for his original updates, and so did the core bitcoin devs. This is pure FUD.
Bitcoin is a protocol not a piece of software, from Bitcoins early days there have been multiple implementations of the Bitcoin protocol. Changing the protocol is something the community decides, if the community were to dissagree it is possible to fork. It is up to the users to choose which protocol they choose to honour. I'm advocating against changing the protocol in a harmful way.
- Giving the power to mint money to BOINC, an organisation which did not ask nor accepted this responsibility will automatically a target for hackers looking to earn crypto currency by hacking.
-> We will write reports in the RPC that we can export to the web to show the relationship between biblepay user, RAC, Magnitude, and ensure everything rolls up. There is a difference between blockchain coinbase minting and Distributed-Computing Rewards. The difference here is in the name of Cancer Research, I believe it is a Huge advantage for biblepay to reward DC users with blockchain rewards, in the form of our daily superblock. This question was posed as Risky and is also FUD. The answer paints a clearer picture of the intent of Biblepay.
Users cannot verify this record we cannot trust BOINC as a single data source (centralise) there is no other way than BOINC to get information about who did how much research.
->-> You can tell with total credit deltas in a forward only algorithm that things are lining up per researcher. You cant go backwards in time. Yes, we can write a report that detects nefarious activity with a tampered file in the same way we can hash a file and detect if you tamper with it. We have far more ability to do that than you think when we know yesterdays state, yesterdays total, a UTXO with a work unit, and the new total and new average. Your clearly biased, not open minded to performing real work and clearly have an objective to make the idea fail. This gives me more motivation and impetus to make this system succeed. We need to provide real world value - and we have a 50billion $ market to prove which algorithm is superior in certain use cases.
All this data comes from a single source, which is not verifiable and therefor requires trust, we cannot require trust to run a trustless consensus protocol.
"Your clearly biased, not open minded to performing real work and clearly have an objective to make the idea fail."
I am clearly biased as in I have an opinion, and I'm very much making that known yes.
Also, this is a personal attack fallacy I would not consider this a valid argument in a rational discussion about software protocols.
"We need to provide real world value - and we have a 50billion $ market to prove which algorithm is superior in certain use cases."
Bible Pay currently has real world value by providing payment services while sponsoring orhpans.
Bitcoin has a market cap far greater than any other coin,
Ethereum has a market cap far greater than any other coin besides Bitcoin,
together they are more than 50% of the market share, disregarding all other coins (nearly all of which use decentralised consensus algorithms) seem to dissagree that centralisation is the way to go.
And even when centralising the big ones choose platforms activly choosing to accept the position of trust for financial services, which cannot be said about BOINC.
- Reducing block chain securing mining subsidies by 90% will effecitvely make the resources required to launch a 51% attack 90% less.
-> Pure FUD. We use DGW, it was carefully designed to not include POL into the mix while reducing the reward, you cannot buy your way into a 51% attack in this scenario. You would certainly drive up the diff within 5 blocks of high hashpower, and you cannot take over biblepay with POW mining with our low nonce rule. It is a true and certain statement, that One Nefarious high hash individual who just hit us with 4 consecutive blocks, would NOT be able to solve block 5 because we only allow 200 hashes per second in the solution. Take a look at the code before making this heinously arrogant statement, and misleading everyone. The 51% attack liklihood on the POW side is more like : 80%, 33%, 11%, 1%, 0.10, .05, .001% for an individual with 75,000 PCs left dormant. Our diff would be : .50, 150, 2500, 8500, 65535, 256000, 1 million. They would not reach level 5 without failing in the attack.
By letting users spent 90% of their CPU towards something other than hasing you effectively make the collective hash rate 90% lower.
You cannot cap the hash rate of a single user since a user could simply split their hash power amount any amount of virtual machines (or implement their own software which would be more resource friendly).
->-> We can require a signed CPID to mine Biblepay. If you arent in the CPID list from a prior superblock, you cant mine. Problem solved.
It is possible for hackers to make an arbitrary amount of CPID's.
Lastly I make a very important argument that Currently our Botnet has 93% of our hashpower, and they are in a stronger position of controlling our chains future now than they would be with a consensus change. The current "status quo" is what is broken - and its a carryover of the problem existing in bitcoin supermajority pools and ASICs. DC is part of the solution.
Wheter the bot net is doing BOINC or PoW Bible Hash, their CPU share will remain 93%, therefor they will remain 93% of the network.
They can easily choose not to do BOINC and keep their current hashrates as mentioned above.
->->Absolutely false. With 100% certainty, the botnet would be boinc mining, not heat mining. And that is OK, they are no longer at botnet.
They don't have to do BOINC mining if they don't choose to do so, never the less they will remain a bot net even if they choose to help research.
The only thing changing is that CPU power will go to BOINC at the cost of centralising Bible Pay, making 51% attacks up to 90% easier and putting trust in an entity which does not this responsibility.
Maybe Swongle owns the botnet.
No way of telling, maybe you own the bot net. ->-> I wouldnt spend my time and energy to run biblepay to secretly run a botnet. However it is still a possibility that you run it, based on how anti-DC you are.
Words are cheap, we cannot verify you're not it, we cannot verify I am not it.
My stance on centralising Bible Pay is irrelevant as it would not negatively impact the owner of the bot net as explained above.
This change wouldn't matter to the bot net since they will keep their share of CPU power and therefor their part of subsidies. --> False.
Implementing Proof of Distributed Computing does not make their CPU resources less, their bot net will still have the same amount of calculating power, alowing them to use this regardles of Proof of Distributed Computing.
I however post this because I am invested in Bible Pay, I like the project and am invested therefor I want the best for Bible Pay. You could argue I'm acting out of pure self interest but even if so my self interest would be aligned with other investors and the orphans. This is not FUD, shouting FUD is the same as shouting fake news when they're actually real issues. Further more regarding politcal discourse, as a European I do not use the words fake news in reference to US-politics nor do I think this is the Forum to be discussing such things and will refrain from doing so. |
|
|
|
Please see inline:
FUD by Swongle:
- Bible pays can be used to set up Master Nodes effectifely granting voting rights to those who are able to mint coins.
-> The sanctuaries job is to vote on the authenticity of the distributed credit file(s) as a whole. Since the algorithm is ranked, no particular sanctuary could predetermine when it will be their job to perform the function. The chances as pointed out by Duffield for such attack are lower than .10%, because of the number required for a net yes. So the statement is misleading. The correct statement is "We as a network will trust 10% of the sanctuaries to verify the Distributed Computing files for authenticity". If one rogue actor fraudulently creates a file, 99% of the other sancs will vote it down. So in reality we are only going to assimilate the official file, created by the distributed boinc network. The users will be paid their fare share of cancer research based on this assimilated and voted file.
The sancturaties cannot tell a fake file from a real file since they cannot verify that the reasearch has actually been done.
- Making BOINC a central authority for deciding who gets Bible pay subsidies making them a single point of failure and allowing for fraudulant non-verifiable transactions.
-> There will be no central point of failure in biblepay, because if the BOINC network or Rosetta goes down, Biblepay stays up while the heat-miners, the PoBH miners continue block checking. Next, there is a distributed web farm on the server side of Rosetta verifying the Cancer Solutions. (Not a single point of failure). We do not directly ask for your solution credit from those servers. Those servers have a backlog, and a proven 99.9% uptime, and simply approve work units in a queue. We actually ask the distributed network for the entire file so that those machines could be down and we could be UP on the DC side. The only way DC goes down is if 10% of our sanctuaries ALL fail to download the distributed computing credits, consecutively, once every 15 minutes for 23 hours. Then DC goes down. AND I Do Not have to send a Spork In to disable PODC. Its automatic. (More FUD).
A single point of failure in the research system is still a single point of failure. The single point being the BOINC organisation. Banks have great track records with security yet crypto currency chooses to not let them be the single point of failure to depend upon.
The network may switch to PoW the 90% reward will still be voted on by the sancturaties, who can as stated above not confirm the validity of the record file.
- Depending on the developer to spork whenever something goes wrong makes the sole developer a single point of failure.
-> Actually for issues like complete network failure of Instant Send, Soft Forking, and Enabling the switch for PODC and Disabling PODC, I do have the right to Execute a SPORK, but that is because I am the sole github contributor. I started the github, and there is a certain inherent level of trust you must assume, that I will not insert a Virus into github, or do anything nefarious that will kill Biblepay. You have my word that I will never do anything to hurt biblepay, and this is an issue in all baby cryptos that have just been birthed: How many years did it take Sunny King to turn control over to "the community", or BlackCoin? A few years. I am in the process of interviewing devs right now. I promise that eventually, we will have 7 devs with spork signing rights (the good ones who know what they are doing).
"certain inherent level of trust you must assume". No. Read Satohshi's white paper it cery clearly states crypto currency is about trustless consensus.
If we are willing to assume trust we might as well be using banks, they too have a very good security record by the way and 99.9% uptime.
- Giving the power to mint money to BOINC, an organisation which did not ask nor accepted this responsibility will automatically a target for hackers looking to earn crypto currency by hacking.
-> We will write reports in the RPC that we can export to the web to show the relationship between biblepay user, RAC, Magnitude, and ensure everything rolls up. There is a difference between blockchain coinbase minting and Distributed-Computing Rewards. The difference here is in the name of Cancer Research, I believe it is a Huge advantage for biblepay to reward DC users with blockchain rewards, in the form of our daily superblock. This question was posed as Risky and is also FUD. The answer paints a clearer picture of the intent of Biblepay.
Users cannot verify this record we cannot trust BOINC as a single data source (centralise) there is no other way than BOINC to get information about who did how much research.
- Reducing block chain securing mining subsidies by 90% will effecitvely make the resources required to launch a 51% attack 90% less.
-> Pure FUD. We use DGW, it was carefully designed to not include POL into the mix while reducing the reward, you cannot buy your way into a 51% attack in this scenario. You would certainly drive up the diff within 5 blocks of high hashpower, and you cannot take over biblepay with POW mining with our low nonce rule. It is a true and certain statement, that One Nefarious high hash individual who just hit us with 4 consecutive blocks, would NOT be able to solve block 5 because we only allow 200 hashes per second in the solution. Take a look at the code before making this heinously arrogant statement, and misleading everyone. The 51% attack liklihood on the POW side is more like : 80%, 33%, 11%, 1%, 0.10, .05, .001% for an individual with 75,000 PCs left dormant. Our diff would be : .50, 150, 2500, 8500, 65535, 256000, 1 million. They would not reach level 5 without failing in the attack.
By letting users spent 90% of their CPU towards something other than hasing you effectively make the collective hash rate 90% lower.
You cannot cap the hash rate of a single user since a user could simply split their hash power amount any amount of virtual machines (or implement their own software which would be more resource friendly).
Lastly I make a very important argument that Currently our Botnet has 93% of our hashpower, and they are in a stronger position of controlling our chains future now than they would be with a consensus change. The current "status quo" is what is broken - and its a carryover of the problem existing in bitcoin supermajority pools and ASICs. DC is part of the solution.
Wheter the bot net is doing BOINC or PoW Bible Hash, their CPU share will remain 93%, therefor they will remain 93% of the network.
They can easily choose not to do BOINC and keep their current hashrates as mentioned above.
Maybe Swongle owns the botnet.
No way of telling, maybe you own the bot net. This change wouldn't matter to the bot net since they will keep their share of CPU power and therefor their part of subsidies. I however post this because I am invested in Bible Pay, I like the project and am invested therefor I want the best for Bible Pay. You could argue I'm acting out of pure self interest but even if so my self interest would be aligned with other investors and the orphans. This is not FUD, shouting FUD is the same as shouting fake news when they're actually real issues. |
|
|
|
Swongel:
Please wait before posting FUD. I will edit this message with FUD rules in a minute.
It's not FUD, these are real issues about the development which should be addressed. Please stop removing my posts and rather reply to the critique so that people may decide for themselves if the critique is valid. |
|
|
|
Lets all hope best future for the coin.
I am moving all my servers to home.
ROB technical question. If I were to connect 10 servers 8vm each at home on home connections would my home connection suffice?
They are all on big internet from DC now
Not Rob; but I'm seeing spikes of about 600kbit/s (mostly download) for a single instance, totalling ~48mbit in your situation. Considering you don't need to sync instantly (taking a few ms extra is not an issue), I'd say it'd be no problem to mine from home so long as you have broadband connection. |
|
|
|
|
