Qubic - Quorum-Based Coin

[Come-from-Beyond]

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?

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.

[1713582882]

1713582882

[1713582882]

1713582882

[jago25_98]

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.

[Come-from-Beyond]

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.

[Come-from-Beyond]

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 :

[Come-from-Beyond]

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.

[Francesco]

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.

So, it's a sort of built-in escrow? Neat!

[Come-from-Beyond]

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

[Come-from-Beyond]

How to donate and tip

With Bitcoin it's easy to start accepting donations, publish your BTC-address and check the balance time to time. With Qubic you can't publish a QBC-address because there is no such a thing, only one-time qubics. But you can publish your e-mail and check it or setup software to do it automatically. Such a way have an advantage over Bitcoin's approach. If Alice sends bitcoins to Bob, but he loses access to his BTC-address, then noone will be able to get the money. Though, if Alice sends qubics to Bob's e-mail and he loses access to it, she still will be able to check if the qubics are spent and redeem them if not.

Tipping works similar way. Imagine that Alice goes to a restaurant where Bob works as a waiter. If she likes the service she could generate a qubic using a mobile phone. This qubic should use a private key derived from a set of symbols. Alice will just write something like

Code:

Qubic tip: ABCDEFG

on the bill, so Bob will calculate

Code:

Keccak256(ABCDEFG)

to get the private key. Later she can check if Bob was smart enough to redeem the qubic and if not then redeem it by herself. She could even use her phone number as a key if Bob is a handsome man .

Read more: http://qubic.boards.net/thread/16/donate-tip

[K1773R]

this projects surely needs more velocity

[Come-from-Beyond]

this projects surely needs more velocity

Really? Well, I still need to solve some technical issues, so Qubic will be able to handle thousands of transactions per second.
Programming is not a problem, if I had all pieces of the puzzle I would write the code within a month.

[Come-from-Beyond]

In http://qubic.boards.net/thread/17/technical-details I posted some technical details about qubics, so it should become clear what the differences between Bitcoin and Qubic addresses are.

[codro]

One solution to the Sybil problem would be to only allow a certain amount of "providers" in the network. Say, not more than 10,000 (exact number to be determined, you could start with less)

Then, have some sort of proof of work system through which interested parties generate a "provider node" token *. Make it extremely difficult, exponentially, so that it is very hard to become a provider. Make provider nodes expire after say 1 month, but allow existing owners to renew their nodes once they have them.

Allow banning of nodes, effectively making them lose their provider node if they become untrustworthy, and return the node to the pool, giving someone else a chance to run a trusty provider node.

* As an example, you could start with a fork of bitcoin, allow people to mine coins which they can use to buy provider node tokens. Say the first provider node costs 100 qucoins, the second 200, the third costs 400, etc.

[Come-from-Beyond]

Then, have some sort of proof of work system through which interested parties generate a "provider node" token *.

How did u know?! It's already implemented that a provider has to do a lot of calculations to join the network.

[Come-from-Beyond]

Below u'll find a description how Qubic handles and distributes data of the ledger. Unlike Bitcoin, Qubic doesn't use a blockchain, so it doesn't need to store all transaction nor to prune some data:


Consistency of the ledger

All interactions between Qubic providers are non-deterministic. When a provider shares information about a transaction it sends the data to randomly chosen peers. This can lead to a situation when some providers don't see some transactions and hence don't destroy/create qubics. Unreliability of UDP, which is used to transfer data, makes the situation even worse, because some providers don't receive data, although transactions were sent to them. Obviously, the Qubic network must have a way to reach consistency at some point, otherwise differences between copies of the ledger will accumulate, leading to a collapse of the whole system.

Consistency is kept on a periodic basis. This synchronization process is a part of the bootstrapping process, because in the worst case scenario a provider has to download all data just like it's a brand new provider.

Once a day (at 00:00:00 UTC) every provider makes a copy of the ledger and calculates its root hash. This hash lets to compare all existing qubics using a 256-bit number, if there is a difference even in a small piece of two copies of the ledger then these hashes will be different. Every provider asks the others for the root hash and compares its hash to the hash of the quorum, and if there are any differences it requests data necessary to build identical ledger. If a provider is bootstrapped then it downloads entire set of qubics.

It should be noted that the ledger can contain billions of qubics, so the synchronization process can take a lot of time. During this time the provider keeps processing new transactions, working with the original ledger which is changed in real-time.

The synchronization relaxes requirements to Qubic providers. It's not necessary to have a high uptime percentage, a provider can be shut down for a maintenance without serious consequences.

Read more: http://qubic.boards.net/thread/18/consistency-ledger

[HanSolo]

Once a day (at 00:00:00 UTC) every provider makes a copy of the ledger and calculates its root hash. This hash lets to compare all existing qubics using a 256-bit number, if there is a difference even in a small piece of two copies of the ledger then these hashes will be different. Every provider asks the others for the root hash and compares its hash to the hash of the quorum, and if there are any differences it requests data necessary to build identical ledger. If a provider is bootstrapped then it downloads entire set of qubics.

If two providers have conflicting ledgers, which version wins?

[Come-from-Beyond]

Once a day (at 00:00:00 UTC) every provider makes a copy of the ledger and calculates its root hash. This hash lets to compare all existing qubics using a 256-bit number, if there is a difference even in a small piece of two copies of the ledger then these hashes will be different. Every provider asks the others for the root hash and compares its hash to the hash of the quorum, and if there are any differences it requests data necessary to build identical ledger. If a provider is bootstrapped then it downloads entire set of qubics.

If two providers have conflicting ledgers, which version wins?

If there are only 2 providers in the system then Qubic doesn't work. If more than 2 then it's necessary to ask other providers to make a decision.

[HanSolo]

Once a day (at 00:00:00 UTC) every provider makes a copy of the ledger and calculates its root hash. This hash lets to compare all existing qubics using a 256-bit number, if there is a difference even in a small piece of two copies of the ledger then these hashes will be different. Every provider asks the others for the root hash and compares its hash to the hash of the quorum, and if there are any differences it requests data necessary to build identical ledger. If a provider is bootstrapped then it downloads entire set of qubics.

If two providers have conflicting ledgers, which version wins?

If there are only 2 providers in the system then Qubic doesn't work. If more than 2 then it's necessary to ask other providers to make a decision.

Thank you for your quick answer!

How are the providers determined? Is it simple majority rule to resolve disputes?

If one transaction lands at one provider just before the midnight-synchronization starts, but then many other providers soon after midnight, if the one that landed before midnight a shoe-in to win, on timestamp alone?

[Come-from-Beyond]

How are the providers determined? Is it simple majority rule to resolve disputes?

Weighted majority rule. The weight is determined by available computing power, similar to Bitcoin.

If one transaction lands at one provider just before the midnight-synchronization starts, but then many other providers soon after midnight, if the one that landed before midnight a shoe-in to win, on timestamp alone?

Every transaction has a timestamp, providers take it into account instead of their local time.

[HanSolo]

If one transaction lands at one provider just before the midnight-synchronization starts, but then many other providers soon after midnight, if the one that landed before midnight a shoe-in to win, on timestamp alone?

Every transaction has a timestamp, providers take it into account instead of their local time.

OK, let's say a transaction 'A' arrives at one provider just before midnight, with a 1-minute-before-midnight timestamp. The synchronization process starts. Just after midnight, a conflicting transaction 'B' arrives at many providers, with a 2-minutes-before-midnight timestamp.

Is the more important factor B's earliest timestamp, the fact that only A was at any provider before the day's sync began, the relative computational power of the providers, or other arbitrary lags in the synchronization?

Also, how do providers demonstrate their relative computational power?

[Come-from-Beyond]

OK, let's say a transaction 'A' arrives at one provider just before midnight, with a 1-minute-before-midnight timestamp. The synchronization process starts. Just after midnight, a conflicting transaction 'B' arrives at many providers, with a 2-minutes-before-midnight timestamp.

Is the more important factor B's earliest timestamp, the fact that only A was at any provider before the day's sync began, the relative computational power of the providers, or other arbitrary lags in the synchronization?

There is a "dead" period from 23:59:00 to 00:01:00, any transaction with a timestamp within this period is ignored. When a provider receives a transaction it checks that difference between the timestamp and local time is less than 30 seconds. These tricks let to avoid the described problem.

Also, how do providers demonstrate their relative computational power?

Once a day (it's adjustable) every provider sends a cryptographic puzzle to the others. The puzzle contains two 256-bit numbers (first_number and second_number). Upon receipt a provider calculates

personal_puzzle1 = Keccak256(first_number, public_key_of_the_provider)
Then it tries to find a 64-bit nonce1 such as

personal_puzzle2 = Keccak256(nonce1, personal_puzzle1)

personal_puzzle2 <= second_number
When nonce1 is found the provider starts searching for nonce2

personal_puzzle3 = Keccak256(nonce2, personal_puzzle2)

personal_puzzle3 <= second_number
and so on.

Nonce1, nonce2, ..., nonceN must be sent back to the original provider within a specific timeframe. More nonces sent -> more work done -> higher weight of the provider is -> more qubics it earns.

Read more: http://qubic.boards.net/thread/12/workers