Topic: Qubic - Quorum-Based Coin - page 2. (Read 25283 times)
Very interesting! Hope to see it running soon
What would be most helpful in understanding Qubic would be if, like Bitcoin, the essential design decisions were documented in one reference doc. Also great would be some example narrative-transcripts/protocol-time-sequences of regular processes.
Right now not all technical issues resolved. That's why there is no one reference doc yet.
Very interesting. Is this based on any other consensus-finding system with any history or study behind it? Preference-aggregation/voting systems are hard.
Yes, it's based on Satoshi's assumption which is the base of Bitcoin security.
That seems a rather large leap. Satoshi relied on statically fixing some things, and single-threading others (one block wins), to avoid confidence-sapping complexity. You're suggesting a mesh of nodes with only local knowledge can, by a (totally novel?) negotiation protocol, converge on some global minting schedule that all respect.
That might be possible, in theory or in practice - it's an interesting idea. But Bitcoin doesn't provide supporting evidence, unless I'm missing something. Some sort of game-theory analysis, or simulation, or evolved precedents in working systems, would be more convincing.
What would be most helpful in understanding Qubic would be if, like Bitcoin, the essential design decisions were documented in one reference doc. Also great would be some example narrative-transcripts/protocol-time-sequences of regular processes.
I predict that will be problematic, for at least two reasons:
(1) In a large distributed system with many transient failure modes, there can be non-malicious errors that inadvertently create double-spends. Destroying the associated value is quite a harsh penalty.
(2) When arbitrarily many followup transactions depend on a double-spent value, and then some time later the double-spend becomes evident (requiring cancellation): (a) unwinding all followup transactions is hard and disruptive; (b) future compromise of private keys would seem able to retroactively cancel true, honest transactions the holder thought had already completed before the compromise.
(1) In a large distributed system with many transient failure modes, there can be non-malicious errors that inadvertently create double-spends. Destroying the associated value is quite a harsh penalty.
(2) When arbitrarily many followup transactions depend on a double-spent value, and then some time later the double-spend becomes evident (requiring cancellation): (a) unwinding all followup transactions is hard and disruptive; (b) future compromise of private keys would seem able to retroactively cancel true, honest transactions the holder thought had already completed before the compromise.
Maybe, we'll test this extensively.
Very interesting. Is this based on any other consensus-finding system with any history or study behind it? Preference-aggregation/voting systems are hard.
Yes, it's based on Satoshi's assumption which is the base of Bitcoin security.
Does this assume every provider generally knows about (and can judge the minting offers/actions of) every other?
No. It's enough to know only about a small fraction of other providers.
My hunch is that the large uncertainty of supply, and potential for disagreements to leave providers confused or seeking network partitions, could prevent the necessary critical mass of stakeholders and community norms from emerging.
Will see.
I can see that helping narrow the windows for problems, but it doesn't really answer what wins in disputes and how things resolve under network stress and malicious attacks.
Say the providers with transaction B are cut off for a few minutes around and after midnight, so they join the synchronization a little late. But they still have a 'valid' earlier timestamp. Did A get an advantage, becoming more likely to 'win', with its small head start?
Say the providers with transaction B are cut off for a few minutes around and after midnight, so they join the synchronization a little late. But they still have a 'valid' earlier timestamp. Did A get an advantage, becoming more likely to 'win', with its small head start?
With thousands nodes it doesn't matter if some of them have incorrect data. If u care about double-spending transactions, both transactions will be cancelled (http://qubic.boards.net/thread/14/double-spending).
I predict that will be problematic, for at least two reasons:
(1) In a large distributed system with many transient failure modes, there can be non-malicious errors that inadvertently create double-spends. Destroying the associated value is quite a harsh penalty.
(2) When arbitrarily many followup transactions depend on a double-spent value, and then some time later the double-spend becomes evident (requiring cancellation): (a) unwinding all followup transactions is hard and disruptive; (b) future compromise of private keys would seem able to retroactively cancel true, honest transactions the holder thought had already completed before the compromise.
Interesting, thank you, but I don't see an explanation how these peer-to-peer challenges result in a consensus determination of how many new qubics each provider receives. Is that in another thread/page?
Each provider decides how much QBC the other providers should get (https://bitcointalksearch.org/topic/m.1219095).
Very interesting. Is this based on any other consensus-finding system with any history or study behind it? Preference-aggregation/voting systems are hard.
Does this assume every provider generally knows about (and can judge the minting offers/actions of) every other?
My hunch is that the large uncertainty of supply, and potential for disagreements to leave providers confused or seeking network partitions, could prevent the necessary critical mass of stakeholders and community norms from emerging.
I can see that helping narrow the windows for problems, but it doesn't really answer what wins in disputes and how things resolve under network stress and malicious attacks.
Say the providers with transaction B are cut off for a few minutes around and after midnight, so they join the synchronization a little late. But they still have a 'valid' earlier timestamp. Did A get an advantage, becoming more likely to 'win', with its small head start?
Say the providers with transaction B are cut off for a few minutes around and after midnight, so they join the synchronization a little late. But they still have a 'valid' earlier timestamp. Did A get an advantage, becoming more likely to 'win', with its small head start?
With thousands nodes it doesn't matter if some of them have incorrect data. If u care about double-spending transactions, both transactions will be cancelled (http://qubic.boards.net/thread/14/double-spending).
Interesting, thank you, but I don't see an explanation how these peer-to-peer challenges result in a consensus determination of how many new qubics each provider receives. Is that in another thread/page?
Each provider decides how much QBC the other providers should get (https://bitcointalksearch.org/topic/m.1219095).
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?
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.
I can see that helping narrow the windows for problems, but it doesn't really answer what wins in disputes and how things resolve under network stress and malicious attacks.
Say the providers with transaction B are cut off for a few minutes around and after midnight, so they join the synchronization a little late. But they still have a 'valid' earlier timestamp. Did A get an advantage, becoming more likely to 'win', with its small head start?
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
Interesting, thank you, but I don't see an explanation how these peer-to-peer challenges result in a consensus determination of how many new qubics each provider receives. Is that in another thread/page?
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?
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
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?
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.
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?
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.
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?
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
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
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.
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.
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.
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.
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.
this projects surely needs more velocity
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 on the bill, so Bob will calculate 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
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
Code:
Keccak256(ABCDEFG)
.Read more: http://qubic.boards.net/thread/16/donate-tip
Jump to: