Quote from: Come-from-Beyond on May 12, 2013, 07:28:41 PM

Quote from: HanSolo on May 12, 2013, 07:11:25 PM

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?

Quote from: Come-from-Beyond on May 12, 2013, 07:28:41 PM

Quote from: HanSolo on May 12, 2013, 07:11:25 PM

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?