I know that users of Bitcointalk are very resourceful when it's necessary to find weak points of a system. There is a list of attacks that could be attempted against Qubic, I hope u help me to devise more attacks:
Isolation attack
Severity: Medium.
Description: An attacker blocks traffic of all providers except controlled ones trying to make the quorum to be statistically incorrect.
Counteraction: Setting a threshold for percentage of non-responded requests to suspend payment acceptance.
Sabotage attack
Severity: Low.
Description: An attacker sends incorrect information about validity of qubics trying to disrupt normal functioning of the system.
Counteraction: Setting the quorum to values below 90% makes the attacker to have at least 10% of the total weight to reach the goal.
Sybil attack
Severity: High.
Description: An attacker creates a lot of providers trying to get the majority of the network to be able to create qubics out of thin air.
Counteraction: Weighting (with proof-of-work) lets to assign weights to each provider, so it's necessary to have a lot of computing power to get a big share of the total weight.
Tunnelling attack
Severity: Medium.
Description: An attacker creates a lot of providers trying to validate non-existent qubics, so it becomes statistically feasible that one of the legitimate providers will consider such qubics as valid ones and will spread incorrect information to other nodes.
Counteraction: Constant validation of all valid qubics.
Read more: http://qubic.boards.net/thread/15/attacks-on-qubic
Topic: Qubic - Quorum-Based Coin - page 3. (Read 25283 times)
Small topic that could be interesting (http://qubic.boards.net/index.cgi?action=display&board=theconcept&thread=9&page=1):
Fighting the scam
Internet is full of scammers because anonymity lets to evade punishment with no or little effort. Qubic does its best to support anonymity, but it provides users with a tool that protects them against scammers.
Every transaction is processed in a 2-step manner:
1. Every owner of input qubics signs the transaction.
2. After a while they commit it.
A transaction can't be rolled back, this means that input qubics of an uncommited transaction are lost forever. How does this protect against scammers?
Imagine that Alice wants to buy an electronic book from Bob for 10 QBC.
She signs a transaction:
10 QBC [owned by Alice] => 10 QBC [owned by Bob]
Then Bob sends the book to Alice via e-mail.
And finally Alice commits the transaction.
If Bob didn't send the book, Alice wouldn't commit the transaction, so Bob wouldn't get the money.
What if Alice didn't commit the transaction? She already got the book, why bother with the rest?
Let's change our transaction:
15 QBC [Alice] => 10 QBC [Bob] + 5 QBC [Alice]
In this transaction Alice paid 15 QBC but got 5 QBC back. If she didn't commit the transaction, she wouldn't get part of the money back. In this situation 5 QBC is a pledge.
What about a case when Bob is just a kid who likes to mock at people?
OK, our transaction should be:
15 QBC [Alice] + 25 QBC [Bob] => 35 QBC [Bob] + 5 QBC [Alice]
Now both Alice and Bob have to sign and commit the transaction. If one of them doesn't do it they will lose the money - 15 QBC of Alice and 25 QBC of Bob.
Let's change the scenario. Alice wants to buy a usual book made of paper. Bob sends it to Alice via good old postal service. Unfortunately, someone in Good Ole Postal Service (GOPS) loses the book. After a week of waiting Alice is angry so she decides to never commit the transaction. Of course, she loses 15 QBC, but Bob loses more, let it be a lesson for him! And only GOPS, which deserves punishment, loses nothing...
...But such a transaction would fix the issue:
15 QBC [Alice] + 25 QBC [Bob] + 20 QBC [GOPS] => 35 QBC [Bob] + 5 QBC [Alice] + 20 QBC [GOPS]
In this case GOPS would do its best to deliver the book.
In examples above all numbers can be adjusted. If Bob has a good reputation he could pay 10 QBC instead of 25 QBC. If he has no reputation yet GOPS could lower their pledge from 20 QBC to 5 QBC (because they don't know for sure if Bob can print the book in time).
This is just an example of a simple scenario. It's possible to create more sophisticated schemes using 2-step transactions.
Fighting the scam
Internet is full of scammers because anonymity lets to evade punishment with no or little effort. Qubic does its best to support anonymity, but it provides users with a tool that protects them against scammers.
Every transaction is processed in a 2-step manner:
1. Every owner of input qubics signs the transaction.
2. After a while they commit it.
A transaction can't be rolled back, this means that input qubics of an uncommited transaction are lost forever. How does this protect against scammers?
Imagine that Alice wants to buy an electronic book from Bob for 10 QBC.
She signs a transaction:
10 QBC [owned by Alice] => 10 QBC [owned by Bob]
Then Bob sends the book to Alice via e-mail.
And finally Alice commits the transaction.
If Bob didn't send the book, Alice wouldn't commit the transaction, so Bob wouldn't get the money.
What if Alice didn't commit the transaction? She already got the book, why bother with the rest?
Let's change our transaction:
15 QBC [Alice] => 10 QBC [Bob] + 5 QBC [Alice]
In this transaction Alice paid 15 QBC but got 5 QBC back. If she didn't commit the transaction, she wouldn't get part of the money back. In this situation 5 QBC is a pledge.
What about a case when Bob is just a kid who likes to mock at people?
OK, our transaction should be:
15 QBC [Alice] + 25 QBC [Bob] => 35 QBC [Bob] + 5 QBC [Alice]
Now both Alice and Bob have to sign and commit the transaction. If one of them doesn't do it they will lose the money - 15 QBC of Alice and 25 QBC of Bob.
Let's change the scenario. Alice wants to buy a usual book made of paper. Bob sends it to Alice via good old postal service. Unfortunately, someone in Good Ole Postal Service (GOPS) loses the book. After a week of waiting Alice is angry so she decides to never commit the transaction. Of course, she loses 15 QBC, but Bob loses more, let it be a lesson for him! And only GOPS, which deserves punishment, loses nothing...
...But such a transaction would fix the issue:
15 QBC [Alice] + 25 QBC [Bob] + 20 QBC [GOPS] => 35 QBC [Bob] + 5 QBC [Alice] + 20 QBC [GOPS]
In this case GOPS would do its best to deliver the book.
In examples above all numbers can be adjusted. If Bob has a good reputation he could pay 10 QBC instead of 25 QBC. If he has no reputation yet GOPS could lower their pledge from 20 QBC to 5 QBC (because they don't know for sure if Bob can print the book in time).
This is just an example of a simple scenario. It's possible to create more sophisticated schemes using 2-step transactions.
So, it's a sort of built-in escrow? Neat!
I don't know when Litecoin ASICs will come to the market, but owners of GPU farms could earn coins even after that - http://qubic.boards.net/thread/12/workers.
We all know how inflation graph of Bitcoin looks. Follow this link - http://qubic.boards.net/thread/11/qubic-supply-growth - and u'll see the same thing for Qubic.
For those who are too lazy
:
For those who are too lazy
:
Small topic that could be interesting (http://qubic.boards.net/index.cgi?action=display&board=theconcept&thread=9&page=1):
Fighting the scam
Internet is full of scammers because anonymity lets to evade punishment with no or little effort. Qubic does its best to support anonymity, but it provides users with a tool that protects them against scammers.
Every transaction is processed in a 2-step manner:
1. Every owner of input qubics signs the transaction.
2. After a while they commit it.
A transaction can't be rolled back, this means that input qubics of an uncommited transaction are lost forever. How does this protect against scammers?
Imagine that Alice wants to buy an electronic book from Bob for 10 QBC.
She signs a transaction:
10 QBC [owned by Alice] => 10 QBC [owned by Bob]
Then Bob sends the book to Alice via e-mail.
And finally Alice commits the transaction.
If Bob didn't send the book, Alice wouldn't commit the transaction, so Bob wouldn't get the money.
What if Alice didn't commit the transaction? She already got the book, why bother with the rest?
Let's change our transaction:
15 QBC [Alice] => 10 QBC [Bob] + 5 QBC [Alice]
In this transaction Alice paid 15 QBC but got 5 QBC back. If she didn't commit the transaction, she wouldn't get part of the money back. In this situation 5 QBC is a pledge.
What about a case when Bob is just a kid who likes to mock at people?
OK, our transaction should be:
15 QBC [Alice] + 25 QBC [Bob] => 35 QBC [Bob] + 5 QBC [Alice]
Now both Alice and Bob have to sign and commit the transaction. If one of them doesn't do it they will lose the money - 15 QBC of Alice and 25 QBC of Bob.
Let's change the scenario. Alice wants to buy a usual book made of paper. Bob sends it to Alice via good old postal service. Unfortunately, someone in Good Ole Postal Service (GOPS) loses the book. After a week of waiting Alice is angry so she decides to never commit the transaction. Of course, she loses 15 QBC, but Bob loses more, let it be a lesson for him! And only GOPS, which deserves punishment, loses nothing...
...But such a transaction would fix the issue:
15 QBC [Alice] + 25 QBC [Bob] + 20 QBC [GOPS] => 35 QBC [Bob] + 5 QBC [Alice] + 20 QBC [GOPS]
In this case GOPS would do its best to deliver the book.
In examples above all numbers can be adjusted. If Bob has a good reputation he could pay 10 QBC instead of 25 QBC. If he has no reputation yet GOPS could lower their pledge from 20 QBC to 5 QBC (because they don't know for sure if Bob can print the book in time).
This is just an example of a simple scenario. It's possible to create more sophisticated schemes using 2-step transactions.
Fighting the scam
Internet is full of scammers because anonymity lets to evade punishment with no or little effort. Qubic does its best to support anonymity, but it provides users with a tool that protects them against scammers.
Every transaction is processed in a 2-step manner:
1. Every owner of input qubics signs the transaction.
2. After a while they commit it.
A transaction can't be rolled back, this means that input qubics of an uncommited transaction are lost forever. How does this protect against scammers?
Imagine that Alice wants to buy an electronic book from Bob for 10 QBC.
She signs a transaction:
10 QBC [owned by Alice] => 10 QBC [owned by Bob]
Then Bob sends the book to Alice via e-mail.
And finally Alice commits the transaction.
If Bob didn't send the book, Alice wouldn't commit the transaction, so Bob wouldn't get the money.
What if Alice didn't commit the transaction? She already got the book, why bother with the rest?
Let's change our transaction:
15 QBC [Alice] => 10 QBC [Bob] + 5 QBC [Alice]
In this transaction Alice paid 15 QBC but got 5 QBC back. If she didn't commit the transaction, she wouldn't get part of the money back. In this situation 5 QBC is a pledge.
What about a case when Bob is just a kid who likes to mock at people?
OK, our transaction should be:
15 QBC [Alice] + 25 QBC [Bob] => 35 QBC [Bob] + 5 QBC [Alice]
Now both Alice and Bob have to sign and commit the transaction. If one of them doesn't do it they will lose the money - 15 QBC of Alice and 25 QBC of Bob.
Let's change the scenario. Alice wants to buy a usual book made of paper. Bob sends it to Alice via good old postal service. Unfortunately, someone in Good Ole Postal Service (GOPS) loses the book. After a week of waiting Alice is angry so she decides to never commit the transaction. Of course, she loses 15 QBC, but Bob loses more, let it be a lesson for him! And only GOPS, which deserves punishment, loses nothing...
...But such a transaction would fix the issue:
15 QBC [Alice] + 25 QBC [Bob] + 20 QBC [GOPS] => 35 QBC [Bob] + 5 QBC [Alice] + 20 QBC [GOPS]
In this case GOPS would do its best to deliver the book.
In examples above all numbers can be adjusted. If Bob has a good reputation he could pay 10 QBC instead of 25 QBC. If he has no reputation yet GOPS could lower their pledge from 20 QBC to 5 QBC (because they don't know for sure if Bob can print the book in time).
This is just an example of a simple scenario. It's possible to create more sophisticated schemes using 2-step transactions.
Just want to say well done on having something new with the network based proof. It's great to see a new innovation. I'll buy into this when it's ready just to support it I think.
I read about this before but it wasn't clear in the main descriptions. I think it would have had more attention if that was so.
I read about this before but it wasn't clear in the main descriptions. I think it would have had more attention if that was so.
I'm considering a scenario where split is 50/50, but 25 more providers appear in Moscow so that quorum is reached.
If I understand correctly, anti-Sybil measures such as weighting fix this situation: it isn't possible to create more providers in a short period of time.
Thus weighting is what protects the network from double-spend attacks. Am I right?
If I understand correctly, anti-Sybil measures such as weighting fix this situation: it isn't possible to create more providers in a short period of time.
Thus weighting is what protects the network from double-spend attacks. Am I right?
Even better:
+25 providers means only (50+25)/(50+50+25)=60%, we must add 100 providers more to get (50+100)/(50+50+100)=75%. Paranoic sellers can set the quorum to 90%. Too high quorum value makes them vulnerable to the sabotage attack, so very high values shouldn't be used though.
The list of providers is updated with arbitrary delay (depends on a provider settings, something like 12-36 hours, can be set to any period), so only a few legit providers will see new 100 providers as soon as they appear. The others will see them in 6-18 hours.
You are right. The weighting works similar to proof-of-work in Bitcoin, it protects the system.
I'm considering a scenario where split is 50/50, but 25 more providers appear in Moscow so that quorum is reached.
If I understand correctly, anti-Sybil measures such as weighting fix this situation: it isn't possible to create more providers in a short period of time.
Thus weighting is what protects the network from double-spend attacks. Am I right?
If I understand correctly, anti-Sybil measures such as weighting fix this situation: it isn't possible to create more providers in a short period of time.
Thus weighting is what protects the network from double-spend attacks. Am I right?
This seems to be a form of ripple ?
No. Similar but still different.
What's about double-spending?
Suppose there is a sudden loss of connectivity between Moscow and Petersburg, but my friend has a full copy of my wallet in Moscow while I'm in Petersburg.
We both can spend same qubic, can't we?
Well, I hope your software can detect that network is split and delay confirmation of payment.
However, this is where Sybil attack comes to play: without anti-Sybil measures, Moscow providers could impersonate Petersburg providers to make it seem like network isn't split.
Suppose there is a sudden loss of connectivity between Moscow and Petersburg, but my friend has a full copy of my wallet in Moscow while I'm in Petersburg.
We both can spend same qubic, can't we?
Well, I hope your software can detect that network is split and delay confirmation of payment.
However, this is where Sybil attack comes to play: without anti-Sybil measures, Moscow providers could impersonate Petersburg providers to make it seem like network isn't split.
Moscow providers can't pretend they are Petersburg ones, coz all traffic between providers is encrypted with a secret key. Each pair of providers has its own key. Moscow providers can spoof IP addresses but they can't guess the key.
Let's imagine that you spend 10 QBC to buy a car and your friend spends the same 10 QBC to buy a house. Both sellers get signed transactions and publish them into the different parts of the Qubic network. The transactions look like "destroy 10 QBC and create 10 QBC with other public key". After a minute both sellers begin to ask arbitrary providers if 10 QBC with new public key exists and count weighted voices. The seller in Moscow tries to ask providers in both cities, the same the seller in Petersburg. If the network is split close to 50/50 but sellers set the quorum as 75% then none of them will ship the purchased item because no reply == "the qubic doesn't exist". Let's assume that Moscow has 80% of all providers. In this case only one of the sellers will ship the item. And after the network is merged, info that old 10 QBC is destroyed will be propagated among Petersburg providers so they invalidate the transaction with double-spent qubics.
In Qubic a successful Sybil attack lets to mint qubics out of thin air or sabotage normal functioning of the network.
What's about double-spending?
Suppose there is a sudden loss of connectivity between Moscow and Petersburg, but my friend has a full copy of my wallet in Moscow while I'm in Petersburg.
We both can spend same qubic, can't we?
Well, I hope your software can detect that network is split and delay confirmation of payment.
However, this is where Sybil attack comes to play: without anti-Sybil measures, Moscow providers could impersonate Petersburg providers to make it seem like network isn't split.
This seems to be a form of ripple ?
For those who asked about the Sybil attack (from http://qubic.boards.net/index.cgi?board=theconcept&action=display&thread=7):
Quote
The Sybil attack is an attack wherein an attacker forges identities (providers in our case). In Qubic a successful Sybil attack lets to mint qubics out of thin air or sabotage normal functioning of the network.
There is only one point vulnerable to the Sybil attack - validation of qubics. Validation is used by a provider that joined the network AFTER a particular qubic was minted. The only way to make sure that this qubic is legitimate is to ask other providers and count their voices. If an attacker controls most part of the providers he can easily "validate" his fake qubics.
The proposed solution is based on "weighting". A weight should be assigned to every provider and decisions should be made according to weighted quorum. It's important that each provider does "weighting" by itself, the knowledge about weights is not shared and hence can't be forged. Once a day or two a provider distributes cryptographic puzzles among other providers. They must send back as many solutions as possible within certain period of time. The weight of each provider is set proportionally to number of solutions. The proof-of-work concept of Bitcoin can be used for puzzles.
Weighting helps to counteract against the Sybil attack. An attacker can easily fill the network with identities but these identities will get very low weights unless he has a lot of processing power, which will be economically unfeasible after the Qubic network becomes big enough.
There is only one point vulnerable to the Sybil attack - validation of qubics. Validation is used by a provider that joined the network AFTER a particular qubic was minted. The only way to make sure that this qubic is legitimate is to ask other providers and count their voices. If an attacker controls most part of the providers he can easily "validate" his fake qubics.
The proposed solution is based on "weighting". A weight should be assigned to every provider and decisions should be made according to weighted quorum. It's important that each provider does "weighting" by itself, the knowledge about weights is not shared and hence can't be forged. Once a day or two a provider distributes cryptographic puzzles among other providers. They must send back as many solutions as possible within certain period of time. The weight of each provider is set proportionally to number of solutions. The proof-of-work concept of Bitcoin can be used for puzzles.
Weighting helps to counteract against the Sybil attack. An attacker can easily fill the network with identities but these identities will get very low weights unless he has a lot of processing power, which will be economically unfeasible after the Qubic network becomes big enough.
Seems so. ISP = "Google Inc."
But why 10 bots at once?..
But why 10 bots at once?..
Googlebot?
maybe it's just a coincidence that google is based in mountain view
Hello, Stranger(s) from Mountain View, I noticed that u were visiting Qubic Forum a lot of times using different IPs. I'm curious if u r a search bot or a real person...
I've published a new version of the provider prototype. Now it's possible to test how qubics r minted.
Everyone is welcome to join, u must have 443 port opened on ur computer. Also http://aws.amazon.com/free/ can be used as free hosting.
PS: http://qubic.boards.net/index.cgi?board=technicalbase&action=display&thread=2
Everyone is welcome to join, u must have 443 port opened on ur computer. Also http://aws.amazon.com/free/ can be used as free hosting.
PS: http://qubic.boards.net/index.cgi?board=technicalbase&action=display&thread=2
"Solution of the biggest disadvantage of Bitcoin" - http://qubic.boards.net/index.cgi?action=display&board=socialissues&thread=6
In short, "print moar moneyz".
-MarkM-
"Solution of the biggest disadvantage of Bitcoin" - http://qubic.boards.net/index.cgi?action=display&board=socialissues&thread=6
a very interesting read. Im very excited to see how you plan on ingratiating all of these ideas into a currency.
"Solution of the biggest disadvantage of Bitcoin" - http://qubic.boards.net/index.cgi?action=display&board=socialissues&thread=6
Jump to: