Yeah maybe, but you would essentially have to re-do their whole whitepaper and probably their synthetic tests/AI attack tests too in order to evaluate the possible dangerous scenarios again.
You essentially created a new version of TailStorm that is even more experimental than the old version. So, this increases the instability risk further because it’s completely novel.
Yup, it’s a big job, gotta get started somehow.
More like, trying to tune it to our needs, like how we did it with native tokens. I had a chat with Griffith on fees, in their variant they’re pooled together and redistributed equally in summary (each miner gets 1/K of total fees, no matter which TXs they contributed). We could do what I proposed above, so each miner gets their own fees from TXs they included, unless multiple miners had the same TX in which case they’d share.
Also, the WP penalizes all subblocks equally for non-chain formations, but I wonder whether incentives would still work if you didn’t punish the longest subchain at all, and if there are 2x K/2-long subchains then maybe yes, but if there’s (K/2)+1 and (K/2)-1 then (K/2)-1 would take a hit while (K/2)+1 wouldn’t.
EDIT: Would be interesting to explore the difference in punishment schemes, need to think more about potential complications arising, but not sure of any that haven’t already been discussed yet.
The structure on the right is not a valid Tailstorm chain. Tailstorm, as presented in the paper we are discussing in this thread, enforces a tree structure on the sub-blocks – the figure has DAGs that are not trees.
You might be interested in https://arxiv.org/pdf/2312.03111 . There I propose a scheme that only punishes the miners of parallel sub-blocks. Blocks without siblings get full rewards even if some parallel sub blocks have been mined in the same epoch. The scheme uses subblock DAGs not trees. This is what you see in the right part of the figure above.
Hey, thanks for joining the conversation here!
Yeah, it was a sketch I got from elsewhere and I missed that detail when copying it. Edited it in the opening post to remove extra connections, now it should match Tailstorm design.
Great! Yes we definitely want to look more into penalty schemes, and fee distribution schemes.
It looks like subblock DAGs further improve the mining game, but we have to carefully consider implementation costs & risks of retrofitting it on Bitcoin Cash. Nodes are already equipped to deal with block tree structures, as they already manage alternative chain tips. Tailstorm would just give them something more to do with them.
I have updated the above schematic of data structures. I think this would be the least intrusive way to retrofit Tailstorm on Bitcoin Cash.
Both subblock and block formats would be the same, and online nodes would announce them in the same way, but validate them slightly differently.
Nodes doing IBD could just ask for summary blocks like they do now, but they’d need to ask also for this extra data blob to fully validate.
If for whatever reason one day we’d want to remove Tailstorm, we could do so, and the only trace of Tailstorm would be the headers in coinbase opreturns and “unexplainable” changes in target difficulty around switching Tailstorm on/off.
The original paper is severely lacking an actual design description. It instead builds a virtual environment which simulates the real thing and then puts some parts of the design interspersed with a description of that virtual design. Which is quite useless as I DGAF about their simulation or their not-well-fitting-terminology. I just want the actual design so I can mentally put it on top of the actual real-world stuff.
Simulation should be separate and distinct. Like a unit test is in a done independent of the actual code.
It’s a fancy paper without much meat. Scientific papers nowadays are not meant to be used outside of science, so lets not digress too much. I’ll just highlight this low, as found on page 2 as something they purport to fix.
Consensus faults are inevitable when individual miners gain too much control [19].
The scared-talk continues for several paragraphs to make people think we really need to fix this, even though it has not failed in operation on quite some chains for quite some years by now. But, this is modern science. Who cares about real world results!
Here is where it really goes wrong (still page 2):
Ideally, rewards are distributed fairly, which means that a miner’s expected reward is proportional to its hash rate.
This ignores that miners are businesses and they may optimize cost and indeed rewards. They may create new incentive schemes like airplane operators did to improve life for the consumers and become cheaper for a great percentage of them. This is commerce, this is capitalism.
Just being rewarded based on how much you invested in hardware is… Not that.
Right now in my homecountry there is a nice farce that shows this distinction quite well. 3 years ago a new CEO took place in the biggest train-rail company with statements of equality, lower prices and other similar statements. Just last week the company announced they would fire a huge percentage of people and increase the prices of train-tickets substantially.
Lesson learned: the market doesn’t give a [censored] about fairness and equality and all that jazz.
Life is hard. Competition is good. We should embrace that and we should encourage that.
So I principally object to Tailstorm for largely 2 reasons:
miners should be in full control over the (full) blocks they produce. This is essential for creating a fee market, for creating business models on mining and essentially allowing capitalism to do its thing.
The same point I made here on the generic block-time thread. The adoption of Bitcoin Cash isn’t dependent on block-time. At the same time, large scale adoption of Bitcoin Cash will actually improve support for zero-conf and thus obsolete this idea probably even before it hits the chain.
I hope Alex and BCA can find some project to work on that helps us gain more users this year. Something that doesn’t require changing of the bch protocols is good. There are hundreds of such projects that require someone to jump on them.
You can find the actual design here. It was live on testnet. src/tailstorm · tailstorm · georgebissias / BCHUnlimited · GitLab
Beyond my 80-120hr per week main job, I spend a significant amount of my free time on promotion and funding. In the last two weeks I built a highly comprehensive tree of BTC and BCH, built and launched my website, have a beta BCH Minecraft server being tested, am 1/3 of the way there to be a high ranked wikipedia editor, have a full doc and team preparing phases of updating the BitcoinCash wikipedia page, reaching out to merchants daily to accept 0-conf/BitcoinCash in general, funding numerous projects/events privately (I’m no whale, but I have given away more than I have currently in all my wallets…)…to name a few things I am doing. So believe me, I am full and active.
If there is more I can do, lay it on me. Though, it will get added to my massive to do list. I am beyond swamped and don’t have the time/funding to do all I desire. Though, I feel this is a common problem.
Not gonna speak for BCA, but he’s probably more dedicated than I am to the network’s success.
EDIT: And from doing the above, and all I hear, having consistent block times is a highly recurring theme. The other benefits are very nice to haves as well.
EDIT2: Let’s stop that thread there, though, as this is largely irrelevant to the topic at hand.
apologies for my poor wording, what I meant was that the time freed up by not spending it on tailstorm (or blocktimes) can be used differently.
Seems you’re already a super human that doesn’t need more than half an hour of sleep a night, so keep rocking the bch stuff you’re already doing 
That’s OK though.
The description is clear enough so you can at least comprehend what are the basic principles and how it works.
It would be hard to implement it basing on that whitepaper alone, but not impossible.
Not the worst whitepaper of the ones I have read.
Right, but also, it has been implemented.
Then we can fill those gaps. The paper places us in the region of design space that holds promise, we can take it from there, and if we do the work then we may find the solution fit for us.
We’re working out the design right here, right now. We already found out that we can tailor it so it doesn’t break block format, we found that the paper socializes fees so we change that, we found that it penalizes all subblock equally, so we change that too and longest subchain can instead get full rewards. With all that, maybe we arrive to a design that could actually work for us?
The above proposed changes from the paper already deviate enough that we’d have to ask @pkel to run new simulations to get indication of whether it would still work to deliver the benefits without orphan rate drawbacks, and then see how to proceed from there.
Your rant about academia was uncalled for, this could be a good partnership here, and in fact the paper is the result of one such partnership: 3 contributors from 2 universities, and a Bitcon Unlimited developer.
In our modified scheme which doesn’t redistribute fee payouts - they’d have that for their subblocks. Mining a summary that references other miners subblocks is then no different than adding a N+1 block on top of block N.
I disagree with this one, but can we refrain from discussing it here, maybe better leave it for the other topic.
Not sure whether we have the same reward scheme in mind, but I’ve tried something like that before. If you’re comfortable reading OCaml, you can take a look at the source. I call it Punish there, opposed to the Discount scheme that made it to the paper. The longest branch gets full reward, the other branches none, just like in Bitcoin. Is this what you mean? We were not satisfied with the results. If I recall correctly the scheme does not help against selfish mining.
My simulations and RL-based attack search do not account for TX-fees. You’re largely on your own there.
The IMO most natural thing is to assign the fees to the miner of the subblock that records the TX first. Based on the total ordering of subblocks (and transactions) described Section 7.1 and discussed in the other thread (see citation below). That’s close to what happens in Bitcoin now, expect that compatible transactions on orphaned blocks are recorded earlier.
I had something like this in mind:
How do you establish first when you have sibling subblocks containing same TXs? We can split the fee then, while paying out full fee to unique TXs. The payout could still be multiplied by the penalty factor. So the fee could be split 1:0.75 for 2 subchains where 1 of them is longer.
That’s too bad. It would be nice to understand what happens to the mining game if / when fees would grow to be more significant than subsidy. Or even, impact of some outlier TX paying a big fee.
First we must ask ourself what problem we are trying to solve.
Brick-and-mortar have no issues using zero-conf.
DeFi will benefit some due to higher confidence in inclusion at a faster pace.
Exchanges and services like Travala will not see any benefit, since the main problem is low percentage of total hash on BCH.
As I see it, it’s better to lower block time to 1 minute and use Avalanche to checkpoint those blocks. XEC has already convinced exchanges to accept 1-conf transactions.
Nobody wants this. The orphan rates at 1 minute would be a huge setback to scalability & pool decentralization, and Avalanche breaks the PoW promise of Bitcoin:
What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.
I’m open to 2 minutes block time as well.
Talking about PoW promise of Bitcoin sounds counterproductive to me. We need to acknowledge the fact that we have minority hashrate, and that it probably will stay that way for a decent amount of time. Avalanche will also solve the problem of no block rewards in the future.
Edit: Avalanche can also be implemented in a way that enables it to be removed later if BCH suddenly have majority of hash. Though at that time I’m sure people will see the benefit and still keep it.
We are ordering the subblocks already. So first means the copy of the TX which is in the first subblock.
Recommended reads:
