Well I think you are somewhat late to the discussion here.
We already have 2 solutions of which one is in the implementation stage and one in the design stage:
So I consider this matter as To Be Sorted Out Soon™.
PS.
Also, there is nothing to get consensus for, In My Opinion we have already achieved consensus, you just weren’t aware of it.
Have to agree with @ShadowOfHarbringer here, in that Double Spend Proofs should be used by services which fit your scenario (allowing withdrawal of 0-conf’ed deposits, and potentially large deposits at that).
So, if they notice proofs of double-spending repeatedly for deposits of some identifiable “client” (you need to be minimally identifiable in some way on such a service, in order to later withdraw any funds) then they can just throttle or freeze such a misbehaving account.
Double Spend Proofs are supported on various node clients, and I believe Fulcrum also has an API for them.
There is of course a difficulty that a user could register another account to continue their trials, after they’ve been blocked out by DSPs.
I think it’s more sensible for such a service to require more than zero confirmations for larger amounts, or even to downgrade a user’s limits if they detect DSPs on deposits.
How can double spend proofs stop this attack if the attacker never broadcasts the double spending transaction and only tries to secretly mine it themselves?
Here is a better description of the attack posted by @bitarchitect in Telegram.
(1) A miner sends e.g. 5000 BCH to an exchange (e.g. @markdavidlamb 's CoinFlex - he was outlining the risks of this particular scenario).
(2) With 0 conf in place and seemingly okay DS proofs (which only work if a 2nd DS transaction is relayed to nodes), the exchange could credit the big balance, never identifying any 2nd DS transaction at all.
(3) The miner keeps mining, is lucky to mine a block, but intentionally excludes the transaction (1) from the block, replacing it with another transaction to themselves that was never broadcasted to the network and thus bypassed the DS proofs.
(4) Hence, such a miner-initiated DS attack beats 0 conf and DS proofs as we know them now, and the miner walks away with a big balance on an exchange that was not confirmed in a BCH block.
So, DSP is somewhere between 0-conf and 1-conf:
DSP detracts the thief only from using the P2P network to broadcast his transaction to as many miners as possible, hoping that some of them don’t have double-spend prevention as a policy.
What you describe is that the thief can collude with miners and send them the TX covertly out of band, so it won’t be caught by the DSP alarm until it’s too late.
I think there’s no way to easily solve this without changing assumptions about mining:
What if we make DSP proof part of consensus so they would allow the double-spent output to be claimed as fee by other miners? A “magical” unlocking script OP_DSP which can unlock regardless of the locking script, as long as the provided DSP checks out. Suddenly, all other miners have incentive to:
This would bring 0-conf security to 1-conf level, because the thief would have to not only get the offending TX in, but then also spend it once more in order to secure it against being claimed by other miners.
DSP would be too big to fit inside unlocking bytecode, right? We’d have to somehow hack it to make it fit. There was already talk about increasing the size. Or, make it detached and put just the hash in the unlocking script, and find a place for the preimage somewhere inside the TX that’d claim the thief’s funds.
Ah yes, it’s the same idea but because it wants to avoid consensus changes it’s way more convoluted and requires action from the payer, who has to craft his TX in a specific way in order for it to be claimable by miners if he later changes his mind and decides to try to steal.
With the detached DSP, the payer (potential thief) has no say in the matter because the whole network consensus becomes that stealing will be punished, and proven attempts will instead find their way into miners pockets.
It would require consensus change, but ordinary P2PKH payments would be supported.
You could make this into a CHIP and name it “Double Spend Proofs 2.0” but I am not entirely sure yet this is safe and doesn’t have any Bitcoin-breaking rules.
Neither am I, that kind of thing would require careful study as with all consensus changes. It may be worth the trouble because it could forever make 0-conf almost as safe as 1-conf.
While the attack is doable and valid, it also is not very practical for most scenarios. It will basically
While better technologies to prevent the attack are in the works (ZECs), in the meantime exchanges can simply allow 0-conf for smaller amounts and require 1 confirmation for bigger amounts.
to expand on why this attack is not very practical here is a more complete list of possible mitigations (of which only the last one is not straightforward):
Collaterals only work if the recipient is the sole custodian of the collateral. ZCE nor miner forfeits dont work.
I haven’t really seen anyone citing a technical reason as to why a shorter blocktime (in the 1-2 minute range) is problematic. The only pushback I have seen is the implicit assumption that 1 minute block times don’t enable many more use cases than 10 minute block times… There is an implicit binary assumption that since block times can’t be 1 second, then it doesn’t really make much difference if they are 10 minutes vs 1 minute. Speaking from my own experience, I can say I have ruled out a long list of specific use cases because of 10 minute blocks (that would have worked just fine with 1 minute blocks). I understand these are all theoretical vaporware in my head, but I can’t help but think many other developers are having the same issue and simply choosing alternative ecosystems as the solution.
Now if the reason for staying with 10 minute blocks is because changing the block time would start another war – Then I 100% agree with not changing the block time – no problems there. But if the reason is because people think 1 minute block times don’t enable significant utility, then I think that position should be seriously reconsidered. I think it’s safe to make the assumption that latency in transactions is a serious consideration in choosing payment networks. Just because you can’t think of these use cases, doesn’t mean other people aren’t. I have thought of many, and I’m sure that doesn’t even account for 0.0001% of the potential use cases of 1 minute blocks. At the very minimum, I think people need to at least acknowledge a very very large tradeoff is being made here – Blocktime is not negligible design parameter.
As everyone knows, there are a hundred different ways to mitigate the 0-conf challenge, but none of them rival the simplicity and elegance of a 1 minute block time. It’s super simple with little technical downside.
I don’t have a formed opinion on what the block frequency should be.
But I can confirm that there is currently a lack of a decision-making mechanism capable of making a decision as important as this, without breaking us.
Without a decentralized voting mechanism it is not possible to make any minimally disruptive decision.
I will make a formal proposal in the coming weeks.
correction - in this specific case a zce type collateral might actually be helpful
The zce’s aren’t realistic for multiple reasons. They “technically” work, but there are too many real-world implementation challenges.
Hello,
Discussion of this topic comes up again and again on Telegram in circles, so I thought I’d just copy and paste some in my opinion, conclusive thoughts about the whole idea:
Joey NFT Master Pig | Enter The Sphere, [22/6/22 00:52]
i’m just reading the reddit thread and its all over the place and why CHIP is important
Joey NFT Master Pig | Enter The Sphere, [22/6/22 00:53]
[ Photo ]
this actually kinda outdated…ltc is being choosen over bch
Joey NFT Master Pig | Enter The Sphere, [22/6/22 00:55]
i see you lay a decent discussion about block time, but it was a full year ago
Joey NFT Master Pig | Enter The Sphere, [22/6/22 00:55]
it doesn’t seem to have gained much discussion on bitcoin cash research actually
bitcoincashautist, [22/6/22 01:01]
[In reply to Ghost]
The claim “if you have 10% hashpower then you have a 20% probability of reversing a block” is indeed true… but it ignores one thing: the cost you pay in absolute terms: 20% for 1minute costs 10x less in power bill than 20% for 10minutes
bitcoincashautist, [22/6/22 01:01]
and exchangs are not ignorant of this fact… so you change your block time to 1min, you can be sure they’ll adjust their no. confs accordingly
cheaplightning #125:ghost: 
, [22/6/22 01:02]
6 confs becomes 60
Ghost, [22/6/22 01:03]
I see your point, but I think that’s just speculating on what exchanges will do, zcash doge ltc all have 1-2 minute blocks and none of them require 100+ confirmations on exchanges
Joey NFT Master Pig | Enter The Sphere, [22/6/22 01:03]
[In reply to Ghost]
but doing all the work to reduce block times, is also speculating what exchanges will do
cheaplightning #125:ghost: , [22/6/22 01:03]
at the end of the day exchanges can choose whatever number they want and are not bound by any rules.
sploit#100 
, [22/6/22 01:04]
[In reply to Ghost]
We’re at 0.5% of sha256 hashrate, any exchange which doesn’t up confs gets robbed
bitcoincashautist, [22/6/22 01:04]
[In reply to Joey NFT Master Pig | Enter The Sphere]
yup… any benefits are speculative while the costs of having everyone update is certain and hyuge
Ghost, [22/6/22 01:04]
Of course I would want to see exchanges adopt instant 0conf deposits, but I think any large bussiness (not only exchanges) will want at least 1 conf even if its just to be sure
cheaplightning #125:ghost: , [22/6/22 01:04]
Yes but DSPs dont require massive changes to the entire network and the emission schedule, breaking the fundamental economics of BCH
Ghost, [22/6/22 01:05]
[In reply to sploit#100 ]
But isn’t there a 10 block replay protection?
im_uname#100🍋, [22/6/22 01:06]
[In reply to Ghost]
that 10 block is crudely adjusted against expected orphan rate / fracture risk, if you lower blocktime to 1 minute it’ll become 100 blocks.
bitcoincashautist, [22/6/22 01:06]
yeah but that’d also have to be adjusted to 100 blockc… because if would be too easy to reorg the 10, then you risk a fork which would require manual intervention to get on the correct chain
Joey NFT Master Pig | Enter The Sphere, [22/6/22 01:07]
i think exchanges are also likely getting alot of FUD about BCH, so introducing a blocktime change isn’t going to change their minds
Ghost, [22/6/22 01:07]
Allright I see, that is something that i was not aware of
Max, [22/6/22 01:07]
[In reply to Ghost]
My opinion is there is no point to lower block time until nearly all major exchanges accept 1 block confirmations for BCH.
Max, [22/6/22 01:08]
so if you want a lower block time first get all major exchanges to accept 1 block confirmations, then we can talk more.
Max, [22/6/22 01:08]
Also exchanges won’t be able to accept 0-confirmation transactions. I lay out the issue here. Why some services can not adopt 0-confirmation transactions
im_uname#100🍋, [22/6/22 01:09]
straightforward “reorg protection” is not free, reorgs exist to align everyone on the network - the more “protected” you are the more risk you have that the network breaks apart in two and fall into consensus failure. there’s a reason the reorg protection is 10 blocks instead of just 1 block YOLO
Just want to revive this topic – there’s been good discussion in the CHIP ZCE topic about whether or not BCH zero-conf is already “good enough” for all users:
This comment summarizes my goal in working on ZCEs:
It’s relatively inexpensive to spin up a fraud-as-a-service mining operation, and because the next generation of mobile wallets will support user-imported plugins, these operations could be able to grow a widespread, on-the-ground user base.
Such an operation doesn’t need to be either very large or very profitable to have a freezing effect on BCH zero-conf – if a risk exists, some percentage of merchants will choose to require 1 conf or (worse) personally identifiable information (KYC) about each customer for risk purposes.
By developing ahead of this systemic risk, we significantly reduce the likelihood that it will ever happen. With ZCEs available, we prevent the further propagation of point-of-sale KYC and ensure a trusted technical solution exists for any burned merchants rather than just disabling zero-conf acceptance (what they’ve done in the past).
The problem here is that practically all the attacks against 0-conf require creating a large evil-miner infrastructure, and the attacks will only succeed in fraction of purchases.
In theory, such an “evil mining” scheme could work, in practice it would be a lot of work for little profit. Perhaps there would be more profit (or certainly: less risk and a lot of less hassle) in honest mining?
Another problem is that, to generate any significant profit (the maximum profit is a small percent from purchases since there is small percent of success probability), basically you would have to convince some large players (like popular payment operators or popular wallet creators) to use such a system where transaction is also sent to an evil miner every time purchase is made.
Perhaps this is why nobody ever did it, even in 2014-2016 era when multiple services were accepting 0-conf (I know, I used them).
The problem with 0-conf attacks is not actually technical. It is logistical and social.
There are 2 general ways to scam in 0-conf purchases:
Scenario A: Make few very large ($>10000 otherwise it does not make enough profit) transactions yourself multiple times. Will not succeed, because for larger sums of money everybody will expect at least 1 confirmation
Scenario B: Make thousands of small transactions. To do this without triggering Per-IP-Range-Limit defence mechanisms [that will be built], you would have essentially either have to 1) create large fake-IP infrastructure yourself, 2) use a botnet or 3) convince a lot of people to do it via using an “evil wallet”
Each of these options: A, B1, B2, B3 either will be quickly and easily stopped or requires significant infrastructure and work and perhaps the small profits and huge risk simply do not justify such huge amount of initial work and maintenance.