Quote from: Vorksholk on December 12, 2016, 06:52:55 PM

I'll make this a Christmas-themed thread

Quote from: JFC on December 12, 2016, 05:19:00 PM

Vorksholk, thanks for your insightful comments. My answers below.

Quote from: Vorksholk on December 11, 2016, 09:07:20 PM

Interesting. To start off with, a few questions:

1. What happens with P2Pool blocks?
P2Pool blocks (ex: https://blockchain.info/block/000000000000000001a1a36ada43fb03b4eb05f30cbe94a206a4a457fb4d71e5) pay out the coinbase + transaction fees to a bunch of addresses, proportional to each's contribution to mining the block. If a P2Pool block was included in the Tic phase, would all of those miners be signing new blocks in the system?
There should be a signature per block to avoid bloating the chain.
Alright, so P2Pool is probably incompatible with this system, correct?
Not necessarily. As long as they find a way to have a single signature for the block, maybe using the highest paid contributor?

2. Does the Bitcoin network enforce proper payouts to the miners of the 144-block Tic phase as a hard consensus rule?
It appears from your post ("The new block is considered valid if: ... 2. It transmits the newly generated coins and any fees due in a fair manner") that this is the case, but I wanted to make sure that this wasn't just the validity check that other miners do before signing the block.
It should be part of the block validation, although mining pools would not sign an unfair block for obvious reasons.]
Alright, cool.

3. Who initially assembles the block for the network to approve?
Whoever assembles the block gets an advantage (get authority over transaction inclusion, can choose to include their own zero-fee transactions). If you create a system where block n in the Tac phase is assembled by the miner who mined block (n mod 144) from the Tic phase, what happens if that miner is offline? If there isn't a particular miner/signer responsible for creating any particular block, how do nodes resolve which block to sign?
Miners should take turns. If the current one responsible fails to deliver a new block, the next one will take his place and so on.
How would that type of failover work? Would the network need a stricter timestamp?
If the miner responsible doesn't show up on time and produces a new block (let' say 10 minutes + 10%) the next in turn can sign and present another block for signing to the rest of the miners. After that the next has its chance and so on.
4. How is the 10-minute timing enforced?
Do peers on the network simply not accept a block_n+1 if the timestamp from the block_n plus 600 seconds isn't the same as the timestamp in block_n+1, and the timestamp of the new block is within a margin of error of their current (local) clock? What would prevent 'whiplash' where miners/signers see it in their best interest to sign the new block as soon as it is proposed (regardless of whether it has actually been 10 real minutes since the last block), which causes them to be creating blocks that, based on their embedded timestamp, appear as if they were made in the future? As they approach the (fairly unknown) maximum allowable clock drift that the large majority of the network will support, they slow down (or even halt) block creation for a while. Even worse, if they overstep the allowable clock drift such that some peers on the network see a new block as barely-in-range compared to their local timestamp, but other peers see the block as barely-out-of-range, is there a desynchronization problem? The cost of performing PoW generally mitigates this problem, since a miner's primary goal is getting the network to accept their block, but in this model (where producing multiple valid blocks has a cost of nearly zero, and a block that gets rejected could have the timestamp adjusted, or could just be re-broadcast later to the network again), these limits could be continually pushed without any significant cost to the miners/signers.

There is an incentive to keep mining blocks within a reasonable time delta. Generating blocks too quickly would leave fees for the next competition phase. Stalling the block generation would keep the miners from getting new rewards from the next Tic phase
As long as the block subsidy is significantly higher than the transaction fees, I could see miners generating blocks quicker than desired to get to the next Tic phase sooner (and more total coins per unit of time during Tac).
That is a good point. I am not sure of an easy solution for that. Maybe forcing a difficulty recalculation every time the system enters a new Tic phase will suffice. If miners produce the blocks too quickly all of them will be penalized with an increase in difficulty of the next phase, proportional to their sin.

5. What happens when the last block of a Tic phase is contested, with two equally-valid blocks proposed by different miners?
Is strong subjectivity lost? If the two miners who created competing blocks for the last block of the Tic phase both had significant mining power in the entire Tic phase, they would actively not vote for blocks that resolve the fork against their favor, which weakens the strength of the Tac blocks against reorganizations.
Once one of the two blocks is signed by the majority of the mining pools, the conflict is resolved. Some margin for collusion exists though.

6. If no block at height n reaches 51% mining approval, what happens?

Quote from: JFC on December 09, 2016, 09:31:37 AM

In case of conflict, the block with more valid signatures is considered the valid one.

What if two blocks are proposed, and one gets 40% approval, one gets 45% approval, and there is 15% (current) non-participation. The network decides, somehow, to accept the one with 45% approval. Then, 6 of the previously-non-participatory 15% comes online and signs the block that previously only had 40% approval (making it now 46% to the accepted block's 45%). Does the network then switch to the 46% block? What if another block has already been stacked on the 45% block; do we have any strong subjectivity to convince bootstrapping nodes of the invalidity of the rejected block despite its' higher approval?
A possible solution would be to accept a block with hash proof instead, but sharing the rewards in a similar manner. However a situation like this would imply most likely a cataclysm in the network since it is in the best interest of all of them keeping signing blocks
Even though it is likely in the best interest of all miners to keep signing blocks, I think it's reasonable that there would be times when, say, three blocks all split approval, particularly if some somewhat-adversarial party were to carefully introduce different blocks to different parts of the network simultaneously. How would the hash proof work?
I am not sure I understand the problem.. Any such attacks from within the miners would be obvious and have a great reputational cost for little if any benefit. Miners are nowadays anonymous but mining pools are not. I would only expect the miners failing to sign blocks in an orderly manner in case of a large attack. In that case the system would use the hashing proof as a fall back but with a penalty for the winner to discourage a miner attacking other pools (hacking their signing computers, for instance)

7. What about the opportunity cost for miners/signers to create deep reorganizations during the Tac period?
The opportunity cost of performing a deep reorganization is drastically lower and much easier to perform during the Tac period, as a majority signature power could collude to create a deep reorganization which they sign together. They could also get unfair leverage on their signature power, because they would not sign blocks for the entire period they intended to fork later, so that they don't compete against themselves. Miners might not be particularly opposed to signing onto a reorganization, because they don't forfeit their reward by doing so (the reorganization would still pay them the same amount as before).

Scenario: 25% of block signers all agree to, during the first few Tac blocks, send 1000 BTC total to an exchange and sell it. They wait for confirmations on the exchange, sell the BTC, withdraw the value in alt-coins. They then create new transactions which pay out those 1000 BTC differently (back to themselves, and some sent to the block signers who aren't part of the collusion), and create a new fork with these transactions instead. The non-colluding miners are enticed to accept the fork by signing it, because they get paid additional Bitcoin which they don't own under the current valid chain, and they don't lose their block rewards for doing so, because the new chain will still pay out the coinbase + fees proportionally to the miners. The miners also can't simply embed that spend transaction they benefit from in the current chain at a higher height, because it spends a transaction (or transactions) which were already spent in the legitimate chain.

This level of collusion and crooked behavior you imagine means that the miners are destroying the underlying value of the bitcoin from which they profit, so I would not expect this situation.
This might particularly be a problem if Bitcoin mining becomes unprofitable, and miners are desperate to cash out. I suppose the concern here is largely that a fork can be proposed which all miners benefit from particularly easily.
That is correct, I think. But if that is the situation, can really miners cash out by destroying the confidence in the system? Also, maybe the exchanges can refuse to admit such a fork since their value will also be destroyed with those shenanigans. I think exchanges will need to bear an important role in the future to counter balance the power of miners.

8. What happens if miners/signers sign multiple competing blocks simultaneously?
A punitive system which punishes miners who submit multiple competing signatures could be implemented (see the Slasher proposal for PoS), but then the punishment of those accounts would be embedded in some way in a future block, which the miner(s) being punished would not vote for, further antagonizing the mining/signing power.
I don't see the advantage of signing multiple blocks at once since the reward would be the same
Generally, signing multiple blocks wouldn't disadvantage a miner, so if a miner is offered a small extra payout, they might happily sign the new block too.
Every different block would need re-signing of enough participants to form a stronger majority. If 51% of the miners are willing to collude to promote a double spend we are doomed anyway, aren't we?

9. What encourages miners/signers to sign at all, rather than go offline and hope other miners/signers don't?
If a miner doesn't have to be online to get their deserved reward from each block, why would they bother validating blocks and signing? If they don't get their deserved reward from each block if they don't sign the block, then it encourages miners/signers to selectively not broadcast other miners' signatures (either so that they can get a higher reward, or to undermine other miners' profitability and get a leg up).

The miners would get the reward anyway. Signing is an almost zero cost operation. Being good citizens should be enough to motivate the miners to sign.
In light of the previous discussion about incentivized reorganizations, a miner electing to not participate might make the chance of such a fork (which they would benefit from) higher, without incurring any risk. In my opinion, this point/question is mostly relevant if those incentivized reorganizations are a legitimate concern.
I doubt we would see that kind of behavior. A possible solution would be that those not signing a block can't redeem their output until n-blocks have passed.

10. What would this change do to blockchains merge-mined with Bitcoin?
Since for the Tac period, they can't use regular PoW mining, would the miner responsible for creating a particular block be the one who gets to merge-mine other chains? In the event that there isn't one delegated miner of each block, miners would all propose blocks in which they receive the merge-mining rewards from merge-mined chains, and wouldn't vote on anyone else's.
I haven't considered merge mining at all, so I can't really say anything meaningful about this point.