Lets talk about block time

Consensus
#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?

#55

Name the wallet, so that they can improve.

4 Likes
#56

I can name three now, Unstoppable wallet, Cake Wallet and Trust wallet.

1 Like
#57

Looking a little, I found this issue on the ‘unstoppable wallet’; Received Instant DASH transactions should appear as confirmed right away · Issue #364 · horizontalsystems/bitcoin-kit-android · GitHub
they don’t even update the balance until confirmed!

Probably the other 2 wallets are similar.

Naturally, this is their choice. They explicitly state this is how they want to operate Unconfirmed Transactions: How They Should Affect Balance ¡ Issue #144 ¡ horizontalsystems/bitcoin-kit-android ¡ GitHub (still Unstoppable wallet)

But here is the good news. If you want instant transactions, you just have to switch to a wallet that understands the BitcoinCash chain better and actually supports that. I love the fact that there are a dozen wallets to choose from, and as most of those are actually open source you can find someone to fix those wallets to reflect reality better.

Hope that helps :slight_smile:

4 Likes
#58

I will leave my 5-cents here.

I dont think preconsensus has to make strong finality guarantees. It is ok to wait for a strong block to make strong finality guarantees. However, preconsensus should make some finality guarantee that is better than 0-conf. This is especially poignant as it will occur with predictable frequency that blocks will take hours.

While it is true that you will have a difficult time enforcing the preconsensus, I believe it is possible to strongly encourage following the preconsensus. For example, everyone agrees transactions should be censorship resistant and we dont want miners colluding with double spenders to mine hitherto unpublished transactions. Both cases are an instance where a miners behavior causes them to deviate from what everyone else would have assumed to happen in the next block.

There is a mechanism to penalize a miner, that is if the majority of the hashrate decides not to build on top of their block, i.e. orphan it. Maybe the strong encouragement to follow preconsensus could be found in game theory, miners who participate in preconsensus make incentivized commitments to preferentially build on preconsensus conformant blocks, thus giving good miners a competitive edge over bad ones (lower orphan rate). Just as a general idea.

It is also the case that preconsensus would offer further benefits over propagation, if a block can be marked with a preconsensus proof (the hash of the contents only that preconsensus postulates), then its contents are already known precisely to all preconsensus participants, and so the contents would not have to be republished to them. Only non preconsensus miners need to have the entire block delivered before they can build on it, and thus they are at a latency disadvantage against preconsensus miners.

#59

The answer is “Use a BCH first wallet.” Selene, Paytaca, Cashonize, Zapit, Electron Cash all operate on 0 conf.

If you insist on using a multicoin or non-BCH focussed wallet, then the poor integration of BCH related features (including 0 conf) is a choice rather than an inevitability.

2 Likes
#60

Did a little analysis of block times: https://twitter.com/bchautist/status/1775125674300198967

The period until the obvious anomaly at x=3371 is pre-fork and that is shared history with BTC. Notice how volatile it was at early days of Bitcoin?

  1. The anomalous area between x=3371 and x=3491 was the fork DAA era which was heavily gamed by miners to speed up the chain, and so BCH is now some blocks ahead of BTC, and it is the main reason why our halving is coming a little sooner

  2. Then, between x=3491 and x=4571, we had cw-144 DAA which was gameable but to a lesser degree, block times were more stable but there were cyclical oscillations: notice the median dipping with only the average being stable. I think at first it was fine, until pools figured out how to game it, which can be observed on the chart.

  3. Finally, we got the ASERT DAA which performs really well, and there’s even been some academic work analyzing it

Note: the plot is based on absolute difference between block times as read from block headers, which don’t always match the real clock.

image
image1216×578 53.1 KB

Zooming in on the last 3 years, we can see some day-to-day volatility but things look generally stable. Note that big price movements can temporarily speed up (while price is moving up) and slow down (while price is going down) the blocks!

Thing is, each day will have 1 or 2 blocks which take more than 1 hour, and people tend to notice those, because there’s always people making transactions, and so there will always be someone who happens to make a TX at that time and he’ll be annoyed by the wait. Sometimes that someone will be you. :slight_smile:

If more services adopted 0-conf, nobody would notice. It’s usually people waiting on payment processors or exchange deposits that get frustrated by the wait.
Payment processors could safely accept 0-conf if they wanted - usually the shipment of some good/service is not immediate and it can be reverted if someone tries to double spend. Also, we have double spend proofs which can serve as evidence and be used to punish the customer who tries to do the equivalent of shoplifting.
Exchanges could accept some risk, and have a 0-conf budget for their customers, allowing smaller deposits to be processed immediately.

With 2-minute block times, we’d still have extremes but they would then mean that every day there will be 5-10 blocks which take 14 minutes instead of 1-2 blocks which take 70 minutes. This could reduce frustrations with payment processors who usually require only 1-conf, but exchanges would likely adjust the required number of confirmations.
If starting a new chain, 2-minute block time would be a better choice than 10 minutes. However, changing an already existing chain’s block time would be a big cost on the whole ecosystem because things were built with assumption that it will never be changed, so I doubt it would be worth the trouble.

image
image1216×578 56.2 KB

PS

It’s always the block you’re waiting for which will be the outlier

– Murphy’s law of blockchains

1 Like