You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the ordering rules we have in place if two operations are present on different chains, they are compared by their timestamp. This has a number of issues:
blocks do not always increment timestamps with their height; specifically this can be seen in Liquid and Bitcoin testnets, when the block time is short and frequently blocks at larger height have smaller timestamp than their predecessors (see WitnessPos ordering fails on regtest rgb-core#273)
miners on blockchains with less security than bitcoin mainnet may manipulate consensus ordering by deliberately putting lower timestamps to their blocks, being ordered before mainnet events
Proposal
introduce blockchain information directly into consensus ordering data
for the same chain order basing on the height and not timestamp information
ordering items from different blockchain check their timestamp:
if the absolute timestamp difference is less than 10 mins (typical bitcoin block time), ignore timestamp and height, and instead apply chain ordering rule (see below)
otherwise, order using timestamp information
chain ordering is the following (from higher to lower priority): bitcoin, liquid, other future chains
Rationale
Selection of 10 minutes as a timestamp window: since we are using absolute difference, this means that for all blocks mined (or reported by miners) from 10 mins before to 10 mins after a current bitcoin block, the bitcoin block will take a priority. Given that liquid block time of 1 minute, this provides security 20x threshold, which would be hard to the liquid miners to manipulate. Making a larger time window would mean reduced incentives for the users to use non-bitcoin blockchains; making smaller window - simplify miner manipulations. Thus, while ±10 min is still arbitrary value, where only order of it is important (so it can be easily ±9 or ±11, but certainly not ±1 or ±20), selection of 10 mins equal to the block time makes just most obvious choice of this arbitrary value.
Background
#10
Motivation
With the ordering rules we have in place if two operations are present on different chains, they are compared by their timestamp. This has a number of issues:
Proposal
Rationale
Selection of 10 minutes as a timestamp window: since we are using absolute difference, this means that for all blocks mined (or reported by miners) from 10 mins before to 10 mins after a current bitcoin block, the bitcoin block will take a priority. Given that liquid block time of 1 minute, this provides security 20x threshold, which would be hard to the liquid miners to manipulate. Making a larger time window would mean reduced incentives for the users to use non-bitcoin blockchains; making smaller window - simplify miner manipulations. Thus, while ±10 min is still arbitrary value, where only order of it is important (so it can be easily ±9 or ±11, but certainly not ±1 or ±20), selection of 10 mins equal to the block time makes just most obvious choice of this arbitrary value.
Implementation
RGB-WG/rgb-core#275
The text was updated successfully, but these errors were encountered: