Lets talk about block time

Consensus
#35

But what would stop exchanges and merchants from requiring 4x - 5x as much confirmations to get the same “protection” ? Nothing.

And 2 minutes is nice, but still too long when you are waiting in a line at local supermarket. Anything longer than 10 seconds is too long.

So yeah, seems like a total waste of time.

I also understand that 0-conf cannot work for DEXes for some reason that is unknown to me? Is this really the case? Is this like an absolutely necessary thing, or can there be workaround done using DSPs or maybe Zero Confirmation Escrows?

1 Like
#36

0-conf with DSPs is already proven safe, so instead of trying to achieve something that may not really improve our situation [and comes with huuuuuge risks and inconveniences], we can instead try to convince large players that what works just works.

#37

Huh? It works amazingly well for DEXes, it’s instant and you can extend the 0-conf chain with another DEX TX and so on.

3 Likes
#38

Sorry, I thought I saw someone above claim that DEXes require a confirmation or something?

I was not sure, so I phrased it as a question.

#39

Oh yeah, this guy did:

#40

Ah this:

It wasn’t clear to me either what’s being said here.

We can do 0-conf DEX chains, although miners will have opportunity to roll it back by kicking out the ancestor and then entire chain of built up TXs would be reverted.

For cross-chain swaps you do need confirmations, but how would 10-min blocks be advantageous over 2-min blocks? With 2-min you get more granularity for specifying timelocks.

#41

How about intermediate weak blocks every 1-2 minutes instead?

I saw a proposition of such a system somewhere.

2 Likes
#42

Glasgow from Ergo shared this link about Sub blocks (weak blocks) in the UTXO alliance group:

https://docs.ergoplatform.com/uses/sidechains/subblocks/

Proposal:

Source:

Even though they have 2 minutes blocks they are working on this proposal.

3 Likes
#43

I don’t know much about DEXes but for Cauldron it kind of is a problem at scale where every trade (potentially) opens up an arbitrage opportunity. Since everyone could create an arb transaction for free we might see many conflicting transactions broadcasted at the same time thus fracturing the mempools. Not to mention that miners could use the arb for MEV…

The mitigation as I understand it is for each swap to contain as many pools as economically possible where the slippage gets reduced more than the mining fee is increased to avoid creating an arb opportunity, but this relies on people being good citizens since it only mitigates it for the next trader. It’s a trade-off where you on one side include many pools and increase the risk of one of them being rolled-back and on the other side pay more slippage.

1 Like
#44

while average block delay in Ergo is 2 minutes, variance is high, and often a user may wait 10 minutes for first confirmation.

With BCH current low SHA256 hashrate, I imagine we might end up in similar situation if going to 2 minute blocks.

It just goes to show that the “reduce the blocktime approach” is a slope.

It’s also interesting that there may be complex ramifications of lowering the block time - which include lowering the difficulty per block - on other applications like DEXes. It’s not at all clear cut that it would lead to improvements for what might be some important use cases in future, compared to the centralized services of today.

3 Likes
#45

It would seem that weak/intermediate blocks could be the “Eat Cake and Have Cake” solution in this case.

Assuming anybody can/has time to code it, of course.

#46

The no-change solution (keep 10 minute blocks) may position BCH DEXes at an extreme advantage over centralized exchanges to capture the majority of real trading volume.

If a user can do a swap or exchange in a decentralized manner quickly and reliably in seconds, then why would anyone want to wait for 6 confirmations? (Although some CEXs credit deposits sooner but don’t allow withdraw until settlement.)

Even if it were possible to expedite the time it took for BCH deposits to be “trusted” by exchanges, it’s building a better off ramp out of our ecosystem.

To repeat myself a third time, there is a massive market and business opportunity if a party is able to offer a DEX that is both fairer and easier than current CEXs. Particularity, a scheme with parallel batch order submissions with timelocks to avoid front-running and latency arbitrage.

Batching orders with timelocks ensuring multiple confirmations as demonstrated by jedex seems like a valuable way to ensure a fair market and genuine price discovery. It could solve our issues with centralized exchanges by moving their role on-chain.

In sumary, a slow dex with timelocks, and confirmations even, would be more interesting to me than changing chain parameters to have a faster off ramp to a set of exchanges where the prices can always be dictated by single well positioned market marker operating across all of them.

3 Likes
#47

You’re missing one huge elephant there.

DEXes cannot do fiat.

Thus, unless some seemingly impossible breakthrough happens, DEXes will always be 2 steps behind CEXes (so they cannot ever take over from CEXes completely and become a dominant type of exchange).

1 Like
#48

Some historical context guys.

The idea of weak blocks dates back to 2013 [BitcoinTalk].

While digging I also found a very interesting article describing the concept further:

https://alexeizamyatin.medium.com/a-quick-glance-at-weak-blocks-and-subchains-64ca705bd382

This idea is older than I thought it is.

1 Like
#49

The variance can be modeled and will show a shorter block time will still have variance but will have less. The number of seconds required to produce i blocks falling below the target pow is distributed as Gamma(i, b) where b is the expected number of blocks per second.

Using a two chain example that only differ in target block time; 1 block every 600s is modeled with Gamma(1, 1/600) while 10 blocks every 600 seconds is Gamma (10, 1/60). Now take random variables X1 ~ Gamma(1, 1/600) and X10 ~ Gamma(10, 1/60). Since the mean and the variance of a random variable with distribution Gamma(i,b) are i/b and i/b**2, we know that expected X1 / expected X10 = 1. however variance X1 / variance X10 = 100.
The variance of process X1 is 100 times greater than of X10 when they are both calibrated to run for 10 minutes.

To summarise in English… given two identical chains except for block time with identical network hash rates, both chains will meet some expected PoW target of security at the same time on average. However, the chain with a shorter target block time will have fewer exceptional cases where the pow target is met late. So while harbinger is right, there is nothing to prevent exchanges from 4x or 5x the number of confirmations required because the pow target is now 1/4 or 1/5 what it once was, the time to meet the pow target will be more consistent than it was before with the longer block times.

TLDR; More blocks in the same amount of time (shorter target block time) leads to a tighter distribution of block times.

Also keep in mind that as the block time gets shorter, orphan rate will go up. not providing any math on that right now but i believe we all generally know this to be true.

All that being said, it is probably not worth the cost to hardfork only to reduce the target time of full blocks. Better to fork to add in some other inter-full-block scheme such as weakblocks/bobtail/tailstorm. or both. but not only the full block target time reduction.

3 Likes
#50

OK, I don’t disagree. So variance should not be a problem.

What about another critical thing - orphan rate?

AFAIK orphan rate should theoretically rise with shorter block times, thus lowering average income of a SHA256 miner. It would thus theoretically show BCH in a bad light as a mining target and further lower the total hashrate.

EDIT:

Sorry, I am a moron because I did not read your post to the end.

You did mention orphan rate as well.

#51

@tech was chatting with folks in UTXO alliance and some interesting stuff surfaced:

My reading is that 10 minute target time seems to be “just right”:

The blue graph depicts a numerically-computed maximum value of ρ for which α(1 − (2∆ + 2)α) > β, i.e. parameters under which our theorem 4.3 shows consistency of the Nakamoto protocol. The red plot shows when our best attack succeeds in violating consistency. When c = 60, the hardness roughly corresponds to an expected 10-minute blocktime, and our theorem shows that Nakamoto tolerates a ρ < 49.57% attack, and our best attack succeeds when ρ > 49.79%.

image
image708×360 18.5 KB

It’s an old paper, though, and I don’t know if things have changed since that would change the paper’s assumptions on which the calculation was based.

I’d just like to highlight this. One 10-min block has the same PoW as 5x 2-min blocks (with 1/5 difficulty). However, a single 10-min block would have greater variance than 5x 2-min blocks.
Individual blocks should have the same variance. But, if you need to wait for some fixed amount of chainwork then more granular blocks will better smooth out the individual blocks’s variance and the aggregate of those blocks will have less variance.

4 Likes
#52

You ever read about the STORM proposal? (I think the latest from BU has it called TailStorm (merging ideas of bobtail and storm))

Was a very interesting concept as an alternative to Avalanche using weak blocks to secure 0-conf transactions. Granted this might be slightly off topic for this, but when you mentioned “weak blocks” this immediately came to mind.

1 Like
#53

Storm / weak-blocks are interesting ideas.
I think it is nice to be able to broadcast an “hey, this is the transactions i’m mining” ahead of them being mined, with some weak proof-of-work to avoid spam. The advantage is that other miners mempools can make sure they have that transaction in there to avoid slower propagation.
Naturally, that isn’t actually solving any problem that anyone is really having in the real world…

The linked paper mostly talks about it being good for instant transactions, which is a dubious claim as there are no guarentees that a weak block will represent a final block. Any such guarentees can’t be made as that will fundamentally change the longest-chain consensus mechanism (proof of work) and that isn’t on the table for BCH. This was also the reason why Avalanche was rejected. It either has no benefit over status-quo, or it changes the consensus concept to unrecognizable state.

Baby/bathwater.

2 Likes
#54

Just want to say that anything less than a real “strong” confirmation would not make much difference as the confirmation concept is deeply rooted in the space. I wouldn’t imagine wallets/exchanges/payment processors to adapt our teach unless a huge movement of all 10-min chains align together and adapt a common solution which I wouldn’t expect to happen.

I had to use a wallet the other day and it wouldn’t even allow me to spend BCH unless I had one confirmation. What is the opposition answer, be patient again?