Every two weeks, the difficulty adjustment algorithm compares the number of blocks over the previous two weeks with the expected number of blocks, given a target block interval of ten minutes, and adjusts the difficulty up if there's too many blocks or down if there are too few blocks.

My question is, what clock/calendar does the algorithm depend on to determine block times?

Would the developers trust time stamps in the block headers, or internet time servers? AFAIK, the only reliable information in a block about the block time is the nonce count, but it's not possible to calculate the block time without also knowing the miner's hash rate (block_time = nonce_count / hash_rate).

In any case, the DAA assumes that the next 2016 blocks will be the same as the last 2016 when they never are and that's why actual block times are all over the place, anywhere between 0.3 seconds to 3 hours.

Average time between blocks is just that, it approximates the target block interval.

Node clocks and calendars can differ by time zones, but even nodes in the same time zones can be a little fast or slow. Dedicated full-time miners tend to have the best internet connections and, with a good communications protocol, like QUIC, used by Solona, they can keep themselves synced in milliseconds. They will give each other a few seconds of tolerance, but they will know when blocks are too soon or too late.

Nobody is going to add your address to the list if you don't stake it first and win.

By 51% attack, I'm specifically referring to an attack in which an adversary with more than half the hash power of the network is able to double spend. No matter how high the hashrate is, the risk of a 51% is always there.

This turn-based mining eliminates the risk of a 51% attack because hash power no longer influences a miner's win rate. It introduces competition when necessary to deal with slow or non-responsive miners and employs POS to prevent spam. Here's the idea:

• Every block contains a list of miner payment addresses.
• Addresses are added to the bottom of the list from an address pool, similar to the mempool.
• When a miner's address reaches the top of the list, they get the opportunity to mine a new block.

When a node wants to mine, they must stake their address to get it added to the pool. When the next block is mined, the miner modifies the list from the last block by including any new addresses from the pool to the bottom of the list and removing their address, plus any addresses above theirs, from the top of the list.

If a miner takes too long, more than a single block interval, the second address is free to compete with the first address in the next block interval. Each block interval is a turn. If they both fail to produce a block in the second turn, the third address on the list is free to compete in the third turn. The pattern continues until a block is found. When a block is found, the next turn goes to the address after the one who produced the last block. For example, if the second address finds a block in the third turn, the next turn goes to the third address.

Turn based mining helps decentralize mining by eliminating the incentives for pool mining. Pool staking will be a thing though, increasing demand for the coin. Mining difficulty is still determined by the block rate, but the block rate is more consistent, and the difficulty will normalize to average solo mining speed. It also saves a lot of energy and improves efficiency.

I'm not saying we stop checking signatures. Only that they not be include in blocks, to save space. Signatures are big and excluding them would save a lot of space. The next block is only valid if it respects original transaction data, which nodes still have in their mempools, so I don't see how miners can steal anything. New nodes, or nodes that have been offline for a while, would only need to trust that the tip of the blockchain is as good without signatures as it is now, which it would be.

The Merkle tree permits pruning, but doesn't improve TPS. It requires you to download full transaction data before pruning which is a waste of bandwidth. And VOUT is just an index value. OGH is a checksum.

Transaction capacity per second (TPS) is block capacity divided by the block interval in seconds. The average size of a transaction is 350 bytes, so a 1 MIB block can contain 2,995 transactions and, with a block interval of 600 seconds:

• a 1 MIB block supports 4, maybe 5 TPS
• a 2 MIB block supports 9, maybe 10 TPS
• a 4 MIB block supports 19, maybe 20 TPS

What if blocks only contain TXIDs instead of full transaction data? An attacker might exploit the lack of transaction data by fabricating a false transaction history and then, for each phony transaction, iterate through the output payment address like a nonce until it's TXID matches one in the block. To fix this, each TXID is paired with it's output group hash (OGH). An output group hash is generated from a transaction's group of outputs. An attacker can't match both the TXID and OGH, so the block references can safely be used to validate full transaction data, which is queried separately.

If the OGH is also 256 bits:

• a 1 MIB block will support 27 TPS
• a 2 MIB block will support 54 TPS
• a 4 MIB block will support 109 TPS

Of course, it gets even better with a shorter block interval.

I just needed to sort out the fee.

No, he can't. The minority of honest nodes, even if it's just one, will have valid copies of both transactions proving the double spend. And any nodes that don't report both transactions are obviously participating in a Sybil attack and would be added to a block list.

If an attacker manages to flood the mempool with so many of his own addresses that he ends up owning all of the addresses in the priority list of an output that he also owns, despite random selection, he can attempt to double spend it. If cosigns them before he publishes them, they will be invalid and not even propagate. He must publish his signed transactions before he can cosign them, so everyone can see them. As soon as he cosigns one, the others are invalidated. If he cosigns more than one, he merely locks up his coins until he resolves the conflict, either by redacting all but one transaction, or by using one of the other addresses on his list to cosign just one of them.

Sybil attacks are used to subvert reputation and voting systems. The random selection of addresses into priority lists is not a reputation or voting system. As long as the opportunity to make the decision of "what transaction is valid" is randomly distributed among all addresses, and the network can never be stuck or fooled by any choice the decider makes, it doesn't really matter who makes the decision. So go ahead and grind out lists so you can flood the mempool with transactions that contain your addresses. Perhaps that's the work that's missing.

I just want to say thanks for all the insights and criticisms. In response, I have made substantial changes to my OP. Check it out. 

By using a verifiable random function.

It's only typical for consumers to create transactions that split coins. Merchants typically create transactions that merge the many smaller coins created by consumer activity into one or a few large coins. That means there will be times when the number of inputs is less than the number of outputs, which will delay cosigners, and other times when the number of inputs is greater than the number of outputs, which will delay confirmations, but there will always be a natural average of 1:1.

When a cosigner is nonresponsive, the sender must replace their address. They must redact the first or previous transaction before publishing a new one to avoid having more than one version of a transaction in the mempool at a time.

You have to cosign something before you can spend your coins.

Fake transactions are invalid, and nodes won't even propagate invalid transactions.

Option 1 is to sign nothing. When this happens, a sender can republish their transaction with a different address for the same UTXO. When that transaction is cosigned, the unsigned transaction is discarded.

There's at least one user per address, but there can be many addresses per user, so we can never know how many users there are. Only that the number of users is equal to or less than the number of addresses. In any case, it is highly unlikely for a new coin on an exchange to have such a small number of addresses for more than a fraction of a second.

There's no inflation because coins are not generated, so the coin supply is 100% premined.

(Not the same 'cosign' used in multisig) Transactions are confirmed individually as users randomly select each other to cosign their inputs. There are no fees, and there is no inflation because there is no blockchain, no blocks, and no coinbase transactions. It's fully decentralized, but there's no work or staking, so it has no measurable impact on the environment.

Before a sender publishes their transaction, they need to select a cosigner for each UTXO they're spending. Nobody can be trusted to select a cosigner at will, or they'll choose themselves or a friend, so they have to run a proof of randomness algorithm, PORA. The PORA selects a payment address at random from the pool of unconfirmed transactions. The owners of the selected addresses become the cosigners of the UTXOs being spent in the sender's transaction.

The outputs of a transaction can't be spent until the inputs are cosigned and each output address has been used to cosign an input in another transaction. Once the sender broadcasts their transaction, the first thing they want to do is cosign something, so they wait to be selected as a cosigner. Once selected, they have three options:

• cosign nothing
• cosign only one input, in one transaction, for the corresponding UTXO
• cosign every input they see

Options 1 and 3 are a waste of time for the cosigner because they won't unlock their outputs or aid in double spend attacks, which are obvious to everyone at that point.

Option 2 is the only option that unlocks their coins, protects their wealth, and secures the network.

I have finally addressed the glaringly obvious oversight of my previous scheme.

Because the work happens before the block is created. It eliminates the block interval and reduces confirmation time to a few seconds; the time it takes a block message to cross the network. Why does block creation need to be slow and predictable?

I have greatly altered the original idea.

Ideally, we want to tie every output to the input that spends it, so it can't be double-spent. But this can't be done before the input exists, so the output must be tied to an intermediary, which gets tied to the input when it's created. This introduces a degree of trust, and a degree of risk.

In this blockless consensus scheme, the intermediary is a ticket. Tickets are created by mediators, who serve the same role as miners. A ticket contains the txid and index of the target output, a confirmation public key, and a payment address. The mediator use a double-key algorithm to create their confirmation pubkey, similar to the one used to create a payment address. They have to scan over a range of private keys until they find one that produces a public key that contains at least one leading zero. They publish their ticket as proof, which everyone adds to their ticket pool.

When the owner of an unspent output creates a transaction to spend it, they must include, in each input, the most difficult pubkey available in the ticket pool for the corresponding output, and create a coinbase output with each mediator's payment address. These input/coinbase pairs always appear first in the transaction, with the same index values, and are sorted by difficulty in ascending order. The owner must sign each input independent of the others, in case any of them need to be replaced. After the owner publishes the transaction, the mediators confirm it by signing the inputs that contain their pubkeys. All but the last mediator signs their input independently. The last mediator signs everything. To minimize network traffic, inputs are signed in the order of their index values.

There's no limit to the number of tickets per unspent output, but an input can only have one unique confirmation pubkey, so pubkeys can't be used more than once, and cannot coexist in multiple tickets at once. There's no limit to the difficulty of a confirmation pubkey, so mediators can constantly work to upgrade their tickets with more difficult pubkeys. The effort required to upgrade a pubkey increases exponentially with it's difficulty, so the coinbase reward should scale exponentially as the zero count increases linearly. After an output is spent, all unused pubkeys can be presented in new tickets for other unspent outputs, so the work isn't wasted.

In the absence of a consensus protocol, a p2p network has no method of resolving double spend attacks consistently, by always accepting the same transaction. A simple decision is all the network requires. A miner performs this function by choosing which transaction to include in their block, while the mediator chooses which transaction to sign. The question is whether a signature is as secure as a block hash. Just as a block hash is a checksum on the block and every block before it. the last signature in a transaction is a checksum on the transaction, and every input is chained to a previous transaction. But a signature is still no iron-clad guarantee of the absence of a double-spend transaction, and neither is a block hash. Just as a malicious mediator can sign more than one input at a time, a malicious minor can solve more than one block at a time. With a good rule set that covers all possible outcomes, a network using either protocol can mitigate the misbehavior, but there is always a risk that a payee can be fooled. The only real difference between a signature and a block hash is the speed. A signature takes milliseconds, and only delays a single transaction, while a block hash can take hours, and delays everything.

Usually, all a mediator must do is sign the first input they see that contains their pubkey. If they sign more than one input for the same output, their ticket is destroyed because it can never happen by accident. If a mediator fails to sign their input within a reasonable time, a few seconds perhaps, the owner can simply replace the ticket for that input. If an attacker uses different tickets in each double-spend transaction, the pubkey with the lowest difficulty is discarded. This scenario might also happen unintentionally when a ticket is replaced. The more inputs a transaction has, the longer it takes to get confirmed because the more it has to travel around the network. If multiple transactions contain multiple double-spends, each with different tickets, the last mediator's should see all transactions before they have the opportunity to sign one, and they should sign only if the transaction that contains their pubkey also has the most combined difficulty. If a mediator sees a transaction that contains a weaker pubkey for the same output they have a stronger pubkey for, it serves as advanced warning.

Cryptographically secure hash functions are irreversible so that ciphertexts can't be decrypted by running the function in reverse. But none of the data in a block is secret, so the block hash is just a checksum, and shouldn't need to be cryptographically secure. Am I wrong?