Red blocks are “the orphans of DAG”, they are blocks that arrived too late and therefore their POW is not counted as contributing to the weight of their respective branches. This is formally defined by the PHANTOM/GHOSTDAG procedure. I propose to include their txns in the UTXO set as well.
The motivation is that it allows for very fast 1 confirmation: In many use cases there is no real threat of a double spend, and the user only wants to know that her txn entered the ledger and is accepted for sure (assuming no double spend). This gives protection, e.g., against temporary 51% attacks, where an attacker gets hold of a majority of the hashrate for some limited time, and is able to gain full control over the set of blue blocks and to reject all txns included by the honest miners and users, which are now inside red blocks. (A counterargument is that valid txns that were rejected by this temp attack will be reintroduced to the mempool and mined again, post the attack. I still argue that this proposal greatly simplifies the UX for users/integration points, and that counting on the mempool process adds risks and uncertainty - mempool may bloat due to the attack, fees can temporarily skyrocket, etc.)
This can be achieved by simply iterating over txns in the set of blocks B.past \setminus B.selectedParent.past according to some deterministic topological ordering, and for each txn adding it to the UTXO set if it is consistent with the current UTXO.
From a DAST point of view, there is no need to keep in memory the information on red blocks, it can be simply part of the UTXO handling around the accepting (blue) block.
Note that txn fees should not be paid to the miner of red blocks. Note further that even red blocks must respect the mass and gas caps, and can’t introduce more txns than allowed.
I really like the idea of including red blocks, but it seems that we’ll have some difficulties with mixing it with the idea of not validating double spends of red blocks. If we don’t keep the past UTXO of red blocks it means it won’t be trivial to count the number of sigops in a transaction, so it means we won’t know if a red block has more mass than allowed (and by proxy also the blue block that points it).
Sorry for resurrecting this thread. I have a few questions along these lines and didn’t want to create a new thread when there was already one with minimal discussion.
I just want to say first that argument about having protection against temporary 51% attacks is a compelling one for including txns within red blocks. It’s not mentioned above, but to include txns within red blocks necessarily means including red blocks in a block’s mergeset (mentioning it here in case it’s unclear to anyone reading).
I’m wondering about a few things:
Are red blocks ordered the same way as blue blocks would be (except they go after all the blue blocks in the same mergeset)? My intuition tells me it must be since they’d still have blue work info even if they’re red so they can be ordered that way. And since ordering is consensus sensitive then so ordering them must also be done in a consistent, stable manner.
How deep of a red block (and txs within) are we allowing for inclusion here? I’m thinking about a few boundaries like the DAA window, the merge depth bound under which we (maybe?) no longer accept red blocks.
IIRC red blocks receive no special treatment within the merge set–the rules of inclusion and the ordering do not explicitly take into account the colour of a block (re inclusion, it so happens that merge_depth violating blocks will be red, since merge_depth>>k). From the “local” merge-set pov, the only different treatment they receive is that their rewards are sent to the merging block, in order to impose a clear cost on double-spending attempts (similarly to Bitcoin orphans not receiving rewards; also related: the uncle mining attack on Ethereum 1.0).
The real impact of blue-red discrimination is the contribution to a block’s score (aka blue score), which impacts the chain selection rule, and in turn the entire ordering. Since only blue blocks contribute to a block’s ability to compete for chain membership, red blocks do not contribute to the security of the DAG’s ordering.
BTW, I’ll try to explain in a later comment the answer to another question (which i believe you once raised): if red blocks do not contribute to security, why are they still counted in the DAA window