Yep-- I defined that as NextGen TailStorm above – to give it a somewhat shorter name haha
It is NOT as simple as decreasing block time. Decreasing block time increases orphan rates. If you read the TailStorm paper, and the many papers it references, this is abundantly clear. Amongst other issues. Doesn’t mean conf times can’t simply decrease somewhat with minimal issue, but at the same time, merchants/exchanges could require more confirmations. We don’t know.
It’s not “ALLLLLLL,” it is many that use services like BitPay and others. Granted, there are merchants using BitPay that also enable 0-conf, but it is not the default (iirc). This is on merchants to do, and on us to make them aware. Both sides can do better.
However, let’s stop it there because this thread is not meant to discuss general social practices as much as this proposal.
1 Like
P2P payments. Most online apps/services native to BCH. Merchants/otherwise are more hit or miss. You with ATMs – you should contact the company and ask why they don’t accept 0-conf. Possible they don’t know or didn’t consider or forgot. At some of the ATMs I’ve used, I’ve not had to wait at all. They used 0-conf.
1 Like
Can you guys stop discussing ATMs and merchants in a strictly technical topic?
You are completely derailing my research status updates.
There is no moderation on this service apparently and I am on the verge of dropping this thread and starting a new one.
The name of this service is “Bitcoin Cash Research”, which means we discuss research here, not politics and other problems, (unless a thread is specifically about researching politics, which it is not).
okay, fair enough 
my apologies 
1 Like
The topic about block times is here: Lets talk about block time - #67 by bitcoincashautist
let’s keep this one focused on TalStorm/WeakBlocks
2 Likes
Doesn’t this mean that sub-block confirmations are useless for finality purpose and having a sub-block confirmation is not any better than 0-conf?
- Transaction is broadcast
- Shortly after, a double-spending transaction is broadcast
- Most miners mine the 1st-seen one, but some miner adds the alternative one
- First sub-block is found, with the 1st-seen TX in it, yay?
- But then, another sub-block is found, with the double-spending TX in it.
- Then, another sub-block, which may or may not include the double-spending TX again.
- And so on until enough PoW for a summary
Miners mining the summary block would reference both the 1st-seen and double-spending sub-blocks, right? But which sub-block’s TX will affect the UTXO state, which one will win?
If I understand right - it depends only on the sub-block hash, whichever has more difficulty, right? But both have to have difficulty above target. Isn’t there 50:50 that the double-spending one wins here?
It costs nothing for miners to add the double-spending TX to their sub-block template, so some could still choose to provide fraud-as-a-service, as described here:
Good argument. It’s possible that finality of a TX is being undone here, by mining in parallel / not being certain which block makes it into summary.
But you should not be replying to me, I am not the author of the whitepaper.
I will give it some more thought.
1 Like
I do not know the details of 0-conf. What’s the exact security claim? After some superficial reading it seems miners watch for double spend attempts, don’t forward conflicting transactions, and instead broadcast a warning. If there is no warning about double spends after a couple of seconds (two worst case propagation delays) the merchant can be sure that all honest miners are working to include the payment transactions into the next block. (Orthogonal question: What about dishonest miners?)
Please correct me if I’m wrong, but 0-conf seems to be largely independent of the underlying consensus mechanism. With consensus I mean the mechanism that establishes a total ordering of messages/blocks/transactions. 0-conf seems to be based on the fact that payments do not require consensus. With payments, ignoring the conflicting transactions is enough; maybe you can even burn all involved funds. DeFi applications like AMM (the original topic of this thread) are different though, there you have to decide which transaction came first. A good reference about this topic is “The consensus number of a cryptocurrency” by Guerraoui et al. in 2021.
Parallel proof-of-work is about improving the consistency guarantees of the consensus mechanism: establishing a total ordering of the blocks which is less likely to change later, and doing this within shorter time. Instead of getting an acceptable failure probability of around 60 minutes as in Bitcoin, Parallel Proof-of-Work achieves this within 10 minutes. This guarantee translates to Tailstorm’s strong blocks / summaries: the ordering established in the last epoch does not change after the next epoch – with sufficiently high probability.
We designed the within-epoch TX conflict resolution to behave like a short-block-interval Bitcoin. Look at the sub block tree of a single epoch, preserve the order within any single branch, and priotize stuff on the longest branch over anything off the longest branch. BTC obviously just ignores the stuff off the longest branch, while Tailstorm merges the transactions that do not cause conflicts. The hash-based comparison only comes to play when the previous rules are ambiguous, that is, when two transactions are at the same depth of two different but equally long branches.
Still not sure whether I got the 0-conf thing right, but I seems to me it might benefit from Tailstorm: double spending proofs can be (and naturally are) persisted on chain earlier.
Wrong. Adding a conflicting TX requires branching the tree (= mining off the longest branch). This in turn implies lower mining rewards.
1 Like
It depends on most nodes respecting the “1st seen” convention and not emitting a conflicting TX but instead emitting double spend proofs (DSPs) if they see such a TX in public mempool. Instead of propagating a conflicting TX, they will produce a DSP to alert other nodes that the same key is trying to spend the 1st seen UTXO in another way. It’s a soft security claim, reliant on goodwill of nodes and pools, as opposed to being directly enforceable in any way. If some rogue pool would want to add a conflicting TX to its block template, there’d be no additional cost in doing so, and they would be able to circumvent the public mempool as often as their hashrate would let him.
I see, this is key here, it means sub-blocks would offer some hard security claims, so having 1 sub-block confirmation is objectively better than just having 0-conf on a linear blockchain, nice, and thanks for clarifying!
There’s a parallel discussion about just reducing BCH block times to something like 2 minutes. With that in mind, how would simple reduction of block times to 2 minutes compare to TailStorm with 2-minute sub-blocks and 10-minute summary blocks? Trying to undersrtand what would be the difference in security claim between some TX having 1x 2-min sub-block confirmation VS 1x regular 2-min block.
2 Likes
At least in TailStorm, there is a table (that I updated to correct numbers above) that shows orphan rates – TailStorm improves in all comparisons. That would likely hold true here, with very similar math. But would like to see the actual. (ref Spearheading the future implementation of Weak Blocks (Intermediate Blocks) for BCH proof of work - #40 by _minisatoshi)
(not to try and answer the question, but some context at least)
1 Like
Got some more info from Andrew Stone on Bitcoin Unlimited Telegram
TL;DR TailStorm gives the benefits of reducing blocktime and does that without negative impact on orphan rates! And it has other benefits, too: actually reduces orphan rates, and improves mining incentives.
Not only that, but sub-blocks work fine even with just 15s interval between them!
And it could be implemented without breaking block format from PoV of old software! Non-upgraded software would be seeing same old 10-minute PoW and regular coinbase TXs with correct emission schedule.
I guess reward redistribution could be implemented by forcing regular blocks coinbase TX to just merge coinbase payouts from sub-blocks and have sub-block hashes in the OP_RETURN.
I think this is definitely the most promising direction in order to improve UX, and makes reducing block time not necessary.
2 Likes
It’s really great that we agree on this.
Using additional emission of a specialized CashTokens, normal Satoshi’s PoW will work nicely too and the blocks will be small, so will propagate instantly comparing to normal-sized blocks.
So the difference will not be so significant.
I think according to Tailstorm whitepaper, the orphan rate improves by ~0.4% in the best scenario, but I need to re-check this number. But we do not know other serious problems with this scheme that will only come out once the system is tested LIVE.
1 Like
Why would there be a need for some specialized token, wouldn’t it only make it harder to reason about incentives? What if the token/BCH price ratio would suddenly change, what happens with our incentives?
Why would the blocks be small? With 1/40 subdivision we’d have 15s subs and their sub-blocksizelimit would start at 800kB. The sub-blocks are not just PoW without TXs - they will contain as many TXs as they can!
The same incentives for linear chain work here the same, and you subdivide everything as if changing the block time: you subdivide blocksize limit, block reward, difficulty by 1/40, each sub-block gets its own header, nonce, and merkle root, and miners mostly mine a linear chain:
(N) <-- N+S1 <-- N+S2 ... N+S39 <-- (N+1)
The legacy header & coinbase TX of (N+1) can still emit exactly 3.25 BCH in that TX, but the TX would be required to have outputs to all the miners who won the sub-blocks referenced by the summary block and they’d each get 1/40. If it so happens that 2 blocks referencing the same height are found, then it just changes the proportions somewhat - to give more to those on the longest subchain and a little less to those on the sides. Not sure if there’s some penalty for non-chain structures, in which case some BCH could be explicitly burned to an OP_RETURN in the coinbase TX and it will still all look normal from PoV of old block explorers etc.
Anyway, if you’re concerned about impact on emission, know that miners can already opt to get less than what emission allows, and they already lost some BTC/BCH to the void this way (Coins never even created! It’s different from creating and then burning), so our max. theoretical supply is already down to 20999821.02921183 BCH.
So in any case emission stays the same from consensus PoV, while incentives work for the benefit of all: both users and miners.
Yeah that’s the difference you can read from one table above, so not much difference when main blocks are 10 minutes apart. Chains with shorter block times would benefit relatively more - but they’d still have higher orphan rates than a chain with 10 minute main blocks.
What’s important here is that it’s not reduced, and we get 15s sub-confirmations!
Researchers had actually spun up a full blockchain network, a code fork of BCH:
I don’t know if the network is still active. Also, BU’s Nexa team plans to implement it, although they did not yet make any announcements about when.
1 Like
That’s the beauty of it: The incentives can only get better. There are absolutely no downsides, except for added complexity, only upsides.
- Miners get paid extra with additional fees for mining the super fast transactions
- Miners get paid extra with additional tokens mining the super fast transactions
The blocks would be small, because, by default, they would only contain the “extra paid” transactions.
They would not contain normal transactions, unless miner changes configuration file to contain normal transactions too. But he is incentivized against it.
The “superfast-tier” transactions would be paid either with normal satoshis or by the specialized cashtoken, at different rate. I am still considering the scheme.
This scheme is perfect because it does not mess with normal incentives and issuance of the system at all.
In fact, the superfast blocks can be completely disabled and mining will continue as usual. However, miners are incentivized to leave them enabled with default settings, because there is only potential extra profit in it.
Incentives everywhere. Make the system balanced so that miners WANT (are incentivized) to make the network faster. Miners also WANT for users to make more blazing-fast instant-confirmation transaction. And miners also DON’T LIKE (are incentivized against) allowing any kind of miner-assisted double-spend, otherwise they may have to orphan some extra blocks with extra fees and tokens.
This matches Satoshi’s original design and Satoshi’s original intention precisely.
100% agree. CashToken emission is pointless and will just overly complicate things that DO NOT need to be complicated. Keep it as simple as possible for the miners. Hard stop.
Huge.
I believe Shadow wants to see it long term on a real chain with economic incentive. Though I don’t agree fully that we don’t know how else it could be played.
I wouldn’t be surprised if by end of year we at least have the roadmap for full implementation.
1 Like
This is just overly complex and unnecessary. Miners mine or don’t. Simple.
What “extra paid”? Where is this described anywhere?
I don’t understand why there is any need to create a fast channel and a slow channel. TailStorm is an everything channel.
Shadow, I think you’re talking about a very different scheme from TailStorm. Maybe you prefer something like that (though I have no idea how it would even be possible, you’d need to write up a whole white paper about it and build out the testnet…), but TailStorm is something already built and working. It doesn’t break any incentive mechanisms that exist in Bitcoin. If anything it only improves upon them.
@bitcoincashautist if there indeed is a difference in thought, then perhaps it would make sense to have a separate thread for further discussion of TailStorm more specifically, to keep both Shadow’s concept and TailStorm discussions cleaner.
2 Likes
I know.
That is the point.
I am not really specifically needing TailStorm. I need a system that does 10-second confirmation without changing too many things, wrecking issuance, changing incentives for the worse or introducing massive complexity.
I will build it.
I think this discussion should be closed, I will make a new topic, this is all too confusing at this point.
just for reference:
what else have you built for the BCH ecosystem? i’m entirely unfamiliar with your “work” … perhaps others are too…