Lets talk about block time

Consensus
#19

If DAA target would change to 1/5 of the current (to 2 min) then block reward should also get changed to 1/5 the current at the moment of switching from 10 to 2, and halving heights after that would be accordingly recalculated as well. I guess we’d get to 0 a bit sooner due to additional integer division by 5, however if we’d have your increased precision CHIP then we could exactly match the original supply schedule. Anyway, even though nobody has worked out the details doesn’t mean it’s not a solvable technical problem.

The locktime opcodes would continue to work with “legacy” heights, like pretend you subdivide block 123 to 123.0, 123.2, 123.4, 123.6, 123.8. If the TX ends up in any of those, the locktime opcodes would evaluate as 123. To get more granularity would require a new set of locktime opcodes. Anyway, backwards-compatibility with regards to contracts is also a solvable problem.

I think the biggest ecosystem cost would be in having various blockchain analytics pages get messed up and display wrong info.

There’s also the increased headers size, and the question of orphan rates.

4 Likes
#20

Tom, @bitcoincashautist has explained it perfectly in this post

#21

It’s simple. Confirmation times is a wildly accepted term that is used everywhere in the crypto world, 0-conf isn’t there yet. So I argue that people running exchanges and payment processors are just counting confirmation times and not really doing the task of computing the work (chainwork). Some providers require just 1 confirmation. lowering block time to 2.5 minutes means 4 times faster transaction for people.

I think such upgrade should be accompanied with marketing/public relation campaign showing the changes BCH have went through to improve stability (yearly upgrade schedule - double spend statistic) to reduce the possibility of exchanges increasing confirmation requirements for BCH.

Did I say that this should replace 0 conf or that sellers will have to switch to block confirmation after such upgrade. It basically reduces the uncertainty/risk and increases trust in crypto payments for merchants and service providers.

Is it safe to accept $100 0-conf payment[s]?

One additional point is that I’ve seen it multiple times that people are suggesting accepting 0-conf for payments less than $100 which is probably good for many merchants but what about payment processors who have to process tens or hundreds of $100s in an hour? What about payments larger than $100 USD?

I quote part of @im_uname Telegram post:

note that 2.5m will shift current 2h complaints (which sometimes happen) to 30m complaints.

I think this is a big advantage to reduce wait time specially when 1h or 2h blocks happen.

#22

Why would the header size be increased? Or do you mean that the number of headers per time will increase?

1 Like
#23

Individual header size would be the same (80 bytes), but the total size of headers chain would be getting bigger faster.

3 Likes
#24

The point is that the premise you are working on is false. It is based on hopium, not on reality.

instant transactions are in actual fact widely used in a large number of places. Townsville is the best documented one.

The fact that it already works today, but isn’t even more widely used is much more logically attributable to things like fulcrum not supporting double-spend-proofs in a way that is usable for a merchant. Which leads to the majority of wallets and point-of-sale software that uses this backend still not using the dsproof, which is still in beta for exactly that reason, it’s waiting for a major roll-out, see roadmap.

The exchanges are not going to lower their confirmation count based on any technical changes in BitcoinCash. There is literally no evidence at all to suggest otherwise. Anyone suggesting so will have to provide some actual evidence to support their claims since otherwise it is and stays hopium.

But you do touch on a really good point:

We have never in our entire existance had anything like a marketing or public relations campaign. I bet that the vast majority of crypto people have no clue about BCH’s instant transaction security. They all still are living with the belief that it is exactly like BTC but with bigger blocks. While BTC is effectively removing all zero-conf features and SPV features with the effect that it stops being usable as cash. We in BitcoinCash have to live in that negative shadow. And I agree it would be wonderful to somehow fight back.

Changing the blocktime is not going to change the perception of risk. As a result it will have no effect on those companies making decisions based on that perception of reality.

The positive here is that companies that actually understand the reality (goCrypto is one, as a good example of a payment provider) they are able to provide zero-conf products and their customers actually can accept BitcoinCash as cash. Which makes them win and eventually the BitPay’s of this world will adjust or get replaced.

Trust the open market, it never fails.

2 Likes
#25

Imagine doing a PR campaign just for your users to find that they are waiting exceptional amount of time just because we inherited a number that some are not daring to change and because of being a minority chain. I’m not sure how much you use payment processors, transfer and deposit to exchanges but it really doesn’t feel right when you have to wait for one hour for just one confirmation. My own experience it’s about 50 percent of the time I had to wait for 30 minutes to 1 hours when dealing with services that requires confirmations just to get 1 confirmation.

When you mention Townsville do you really have data on the practice of the stores there? how many of them, how much volume they are processing. Do they accept 0-conf for transactions that are above $100, do they require ID? What exactly is their policy? Are they depending on payment processors or they are just using BCH directly.

Please don’t limit the discussion for store payments considering their share from usage of crypto currencies.

I’m not trying to undermine DSP or 0-conf but you can not undermine the importance of confirmations.

Tom, there are tons of cryptocurrencies around there, why would developers implement DSP just for us?

Using the same logic they are also not going to increase their confirmation requirements if we do lower block time.

#26

One argument from @BigBlockIfTrue first reply and @bitcoincashautist reminded me of really worth considering is when lowering block time we also lower the work required to produce a block and this may increase risk of forks of smaller pools produced blocks by larger pools. Hopefully someone can check if this is a serious issue or have it happened before at all on BCH or chains with lower block time?

Is this the situation we will be in if our hash rate drops to quarter of it’s current one?

#27

I am back from winter break now.

Do you guys need any help destroying above nonsense arguments? You seem to be handling it well, not sure if I should join in and ruin your fun.

@tom @bitcoincashautist @freetrader

2 Likes
#28

So, to make this very clear. The way that changes in BitcoinCash work is, in short.

No changes to the protocols or consensus rules are allowed. They are immutable. No developer, or miner or whomever is able to change them as the changed thing will simply not be BitcoinCash anymore. This is your baseline.

Good ideas can come up and the people that believe in them can attempt to convince everyone else to follow this good idea. When everyone in the community agrees this is a good idea, then it followes we all agree to change those consensus rules.

Now, if you state that “someone” needs to do work, and you’re not volunteering to do the work, that’s your choice and I don’t mind. I just want to establish expectations with the above. It’s not convincing me that this suggestion is a good one.

#29

Changes to the protocols or consensus rules are allowed - they are done via CHIPs.

When everyone in the community agrees this is a good idea, then it followes we all agree to change those consensus rules.

No, not everyone needs to agree. That was one of the last line of defense arguments from Core against raising the blocksize - that not everyone agreed. This kind of “extreme consensus” is not needed in the real world for changes to happen to the Bitcoin Cash protocol. Someone just needs to write a CHIP to motivate and specify the change well (looking at recent CashTokens and ABLA CHIPs as primary examples). Of course it needs to make a case for the change well enough that enough people want it so much that they’re willing to incur the costs of deploying and supporting it.

And even if everyone agrees that something is good in theory, it still needs someone to implement it.

So it does not follow that a change is deployed simply because some or all agree.

There is also no compulsion on others to implement anything. People implement things if they can and think they’re useful. If 90% agree something is useful, but 10% don’t, and the 90% implement it, and it becomes a success, those 10% are just going to find their products less in demand and maybe die out.

Just wanted to point it out to avoid confusion.

1 Like
#30

LOL, I guess the “in short” was too short for you? :rofl:

Excuse my bravity…

#31

Since people talked about exchanges, this older video is still valid and people should consider its implications.

1 Like
#32

Was Joshua able to convince Coinbase of accepting 0-conf transactions as he was/still an engineer there?

#33

Irrelevant, pretty much.

The ecosystem will automatically start accepting 0-conf transactions once Bitcoin Cash becomes the dominant way of making payments.

Despite nonsense claims from various parties, a successful attack against a 0-conf accepting merchant has never been done on neither BCH or pre-2016 BTC even. I still remember paying via 0-conf to coinbase and BitPay back then.

The unwillingness to accept 0-conf transactions is merely due to years of propaganda and (deliberate) malfunction [RBF, clogged blocks] on the Core side.

I can make an educated guess; based on solid, hard evidence; that 0-conf transactions for anything under $5000-$10000 in USD value are 99.99999% safe on BCH, because the attacks have been thoroughly discussed and the conclusion is that the attacks are too impractical and the risks are too high for a serious party(like a big miner) to even consider doing them.

Honestly you’re wasting time trying to convince the BCH community to decrease block time, while you actually should be trying to convince merchants to simply accept what works. You should rather, in fact, write to your favorite payment provider right now and politely inquire them about accepting 0-conf.

1 Like
#34

IDK if it’s a waste, I’d love it if our blocks were 2 minutes instead of 10, then those annoying outliers would be 24 minutes instead of 2 hours.

It’s always the block you’re waiting for which will be the slow outlier."
– Murphy’s law of blockchains

It’s just that the change would have a big cost to the ecosystem, and maybe we could just suck it up with 10 minute blocks until better solutions arise.

3 Likes
#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.