Closed meowsbits closed 2 years ago
BelfordZ
commented
2 years ago nice one!
Might be nice to make it a blockHash | transactionHash, allowing similar thing but for creating transaction ordering dependencies.
If enough transactions set this field, any chain mined without the required ancestorblock would have a very low cumulative difficulty unless they produced a much larger number of blocks than the cannonical chain. I'd imagine you would see overall far fewer less reorgs.
gitr0n1n
commented
2 years ago @meowsbits , if you can resolve @BelfordZ 's comments (if anything needs resolving), I'll allocate the time for a review within the week.
meowsbits
commented
2 years ago @BelfordZ
Might be nice to make it a blockHash | transactionHash, allowing similar thing but for creating transaction ordering dependencies.
Yea, transaction-ordering seems like a logical next step (or adjacent abstraction), but...
a.) With only block hash dependencies we get a kind of superset of transaction-ordering dependency, since a block's hash will change if its transactions are reordered (or otherwise edited)... the block becomes a new block. So a transaction's citation of a block already cites the existence and ordering of its transactions.
b.) Transaction dependencies (vs. block dependencies) are generally less "strict." This feature is proposed in the context of 1108, which is interested in differentiating public vs. private chains, generally to mitigate the risk of large reorgs by increasing the cost of making them in independent isolation. An attacker in these circumstances can include any necessary transactions in their private chain more easily than blocks, which are impossible to reproduce.
If enough transactions set this field, any chain mined without the required ancestorblock would have a very low cumulative difficulty unless they produced a much larger number of blocks than the cannonical chain. I'd imagine you would see overall far fewer less reorgs.
As for the reorgs, I'm not 100% sure I follow here (at least in the context of this ECIP). But in the context of 1108, indeed, the more transactions that use relevant (~contemporary) block dependencies, the fewer transactions will be applicable to private chains, and the more balance/capital the attacker (building a private chain) will need to provide themselves to stay competitive with the public aggregate transaction-sender balance score (TABS).
Will there be fewer (small) reorgs? Probably, but as I had understood it, that'll be because the TABS score (the 2nd-dimension consensus score value) for two competitive blocks (same parent), one of which is destined to become an ommer, the TABS score could be decisive around 50% of the time, breaking the consensus tie that otherwise difficulty alone would yield to a coin toss.
gitr0n1n
commented
2 years ago @BelfordZ
Might be nice to make it a blockHash | transactionHash, allowing similar thing but for creating transaction ordering dependencies.
Yea, transaction-ordering seems like a logical next step (or adjacent abstraction), but...
a.) With only block hash dependencies we get a kind of superset of transaction-ordering dependency, since a block's hash will change if its transactions are reordered (or otherwise edited)... the block becomes a new block. So a transaction's citation of a block already cites the existence and ordering of its transactions.
b.) Transaction dependencies (vs. block dependencies) are generally less "strict." This feature is proposed in the context of 1108, which is interested in differentiating public vs. private chains, generally to mitigate the risk of large reorgs by increasing the cost of making them in independent isolation. An attacker in these circumstances can include any necessary transactions in their private chain more easily than blocks, which are impossible to reproduce.
If enough transactions set this field, any chain mined without the required ancestorblock would have a very low cumulative difficulty unless they produced a much larger number of blocks than the cannonical chain. I'd imagine you would see overall far fewer less reorgs.
As for the reorgs, I'm not 100% sure I follow here (at least in the context of this ECIP). But in the context of 1108, indeed, the more transactions that use relevant (~contemporary) block dependencies, the fewer transactions will be applicable to private chains, and the more balance/capital the attacker (building a private chain) will need to provide themselves to stay competitive with the public aggregate transaction-sender balance score (TABS).
Will there be fewer (small) reorgs? Probably, but as I had understood it, that'll be because the TABS score (the 2nd-dimension consensus score value) for two competitive blocks (same parent), one of which is destined to become an ommer, the TABS score could be decisive around 50% of the time, breaking the consensus tie that otherwise difficulty alone would yield to a coin toss.
Great, I'm going to process the ECIP editor review. It appears copy for the ECIp is being edited here and perhaps the discussion @BelfordZ and @meowsbits are having can continue in the Discussions-To thread, as I think its great thoughtful technical conversation that would be great to have a clear paper trail for future readers. :+1: https://github.com/ethereumclassic/ECIPs/issues/422
This strips off all proposed context types and their generic structure to instead propose only adding a field 'ancestorHash' which defines a dependency on some foregoing canonical block for a transaction.