Topic: Sybil Resistant Decentralized Consensus Mechanism (Read 740 times)
I need people to find logical/programming flaws in this blueprint. If it can be made flawless then this kind of mechanism can serve as a perfect consensus mechanism for future projects.
You could maybe use the hash of the data you are sending to produce the captcha and then solve it. This would at least prevent the generation of lookup tables and such for solutions, but he could still nonce that hash and attempt to generate those "easy" captchas.
Depending on how secure the container is for the captcha solutions, and whether its hash dependent (but even that might not be enough if the captcha has a small payload of 10 or so chars), he could even "sniff" data coming past him and use solved captchas he sees in his own data presentations to the network.
I have re-wrote my paper and now it's only hash based. Now the CAPTCHA will be generated from 3-4 nodes working together to create one and then send it to the miner to be solved.
- snip -
The miner has to manually enter the solution to that captcha, and send the solution over to the other 8 nodes. The verification of the CAPTCHA from the other 8 nodes is automatic since they have the database of CAPTCHAS on their computer just need to cross validate between each other.
- snip -
The miner has to manually enter the solution to that captcha, and send the solution over to the other 8 nodes. The verification of the CAPTCHA from the other 8 nodes is automatic since they have the database of CAPTCHAS on their computer just need to cross validate between each other.
- snip -
How do you keep the miners from having a database of CAPTCHAS on their computer? If they have the database, can't they just write a program to look up the entry in the database and return the correct answer?
Hmm interesting point, indeed if the random number is generated on the PC the miner knows and he can lookup the captcha solution for it in the database.
Any solutions how to fix this?
Maybe perhaps the captcha database should not exist, and the CAPTCHA should be generated on the go by the client, and then the CAPTCHA should be sent around, with the miner's answer, to all miners to validate and whatever answer reaches say 90% threshold accuracy, that will be the correct one, and every miner who answered the wrong question won't get a bonus.
You could maybe use the hash of the data you are sending to produce the captcha and then solve it. This would at least prevent the generation of lookup tables and such for solutions, but he could still nonce that hash and attempt to generate those "easy" captchas.
Depending on how secure the container is for the captcha solutions, and whether its hash dependent (but even that might not be enough if the captcha has a small payload of 10 or so chars), he could even "sniff" data coming past him and use solved captchas he sees in his own data presentations to the network.
- snip -
The miner has to manually enter the solution to that captcha, and send the solution over to the other 8 nodes. The verification of the CAPTCHA from the other 8 nodes is automatic since they have the database of CAPTCHAS on their computer just need to cross validate between each other.
- snip -
The miner has to manually enter the solution to that captcha, and send the solution over to the other 8 nodes. The verification of the CAPTCHA from the other 8 nodes is automatic since they have the database of CAPTCHAS on their computer just need to cross validate between each other.
- snip -
How do you keep the miners from having a database of CAPTCHAS on their computer? If they have the database, can't they just write a program to look up the entry in the database and return the correct answer?
Hmm interesting point, indeed if the random number is generated on the PC the miner knows and he can lookup the captcha solution for it in the database.
Any solutions how to fix this?
Maybe perhaps the captcha database should not exist, and the CAPTCHA should be generated on the go by the client, and then the CAPTCHA should be sent around, with the miner's answer, to all miners to validate and whatever answer reaches say 90% threshold accuracy, that will be the correct one, and every miner who answered the wrong question won't get a bonus.
- snip -
The miner has to manually enter the solution to that captcha, and send the solution over to the other 8 nodes. The verification of the CAPTCHA from the other 8 nodes is automatic since they have the database of CAPTCHAS on their computer just need to cross validate between each other.
- snip -
The miner has to manually enter the solution to that captcha, and send the solution over to the other 8 nodes. The verification of the CAPTCHA from the other 8 nodes is automatic since they have the database of CAPTCHAS on their computer just need to cross validate between each other.
- snip -
How do you keep the miners from having a database of CAPTCHAS on their computer? If they have the database, can't they just write a program to look up the entry in the database and return the correct answer?
I was thinking about a new consensus mechanism that offers decentralized authentication in terms of voting. A decentralized CAPTCHA system if you will.I think this is better than what Bitcoin currently has, and it can't be centralized like the mining, so it might be used in the future for consensus mechanism in bitcoin or altcoin projects.
VERSION 2: https://www.docdroid.net/1Nv5g3r/sybil-resistant-decentralized-consensus-mechanism.pdf.html
VERSION 2: https://www.docdroid.net/1Nv5g3r/sybil-resistant-decentralized-consensus-mechanism.pdf.html
- I have updated my paper, so that it doesn't rely on a database that can be easily bypassed as Fuserleer and DannyHamilton has suggested, now everything is based on hashes and it can be traced back to the genesis block
Jump to: