Qubic - Quorum-Based Coin

[HanSolo]

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.

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?

[1714026298]

1714026298

[1714026298]

1714026298

[1714026298]

1714026298

[Come-from-Beyond]

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?

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://bitcointalk.org/index.php?topic=112676.msg1219095#msg1219095).

[HanSolo]

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?

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://bitcointalk.org/index.php?topic=112676.msg1219095#msg1219095).

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.

[Come-from-Beyond]

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.

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.

[HanSolo]

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.

[Come-from-Beyond]

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.

[fran2k]

Very interesting! Hope to see it running soon

[allwelder]

what is the recent situation ?

[Come-from-Beyond]

what is the recent situation ?

I'm still thinking about different aspects of Qubic.

[allwelder]

what is the recent situation ?

I'm still thinking about different aspects of Qubic.

wait to see...

[allwelder]

Hello CfB,
the web http://qubic.boards.net/ is always downtime recently.
What is wrong with it?

[Come-from-Beyond]

Hello CfB,
the web http://qubic.boards.net/ is always downtime recently.
What is wrong with it?

It's up for me.

[allwelder]

http://qubic.boards.net/  has been deleted?

[Come-from-Beyond]

http://qubic.boards.net/  has been deleted?

Yes. It contained too much outdated info.

[Momimaus]

And where is some information about Qubic?

[allwelder]

http://qubic.boards.net/  has been deleted?

Yes. It contained too much outdated info.

So where can find info of Qubic?

[Come-from-Beyond]

I'm going to create a decentralized forum.

[2Kool4Skewl]

I'm going to create a decentralized forum.

Using the NXT blockchain?

[chanc3r]

- Network-bound proof-of-work instead of CPU-bound one is used

DISCLAIMER: In advance apologies if I've got this totally wrong

Is the Network PoW similar I wonder in concept the the utility/network/importance participation proofs being proposed in some of the NEM forums.

If you are trying to achieve true decentralisation, how do you take into account that the internet is not decentralised, in fact it is becoming more and more centralised in terms of bandwidth and cpu with cloud based hosting centres...

If you are in a major city in a western country then you can participate well in a network based system, with more bandwidth, faster response times etc...

if you are in a rural area or a less well connected country then your participation will be lower...

This will lead to people in the US for example easily/quickly gaining better reputations than people in africa or eastern europe...

Or perhaps there would be regionalisation so a node in eastern europe would see more network local nodes with which it naturally does more transactions as having more of a reputation then a node in the US which it talks to seldom...
Or is the reputation for a node levelled and set network wide?

Or are you just trying to achieve a logical decentralisation and the whole network could exist on VPS in one data centre?

[Come-from-Beyond]

Using the NXT blockchain?

No idea yet.