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
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.
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.
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.
Ah, right, you could use the same conflict resolution mechanism as with double-spending TXs and just reject the duplicate(s). That would mean the selfish mining incentives in absence of block reward would remain the same.
If we’d equally redistribute fees to only the subblocks that included the TX (but penalizing width similar to how subsidy is penalized), what’s your intuition on impact on incentives? Imagine a 10 BCH TX is mined and not much left in mempool to fund the next block. Wouldn’t it incentivize a competing miner to fork so he could at least get a portion of that?
If we’d just pool together all fees and redistributed 1/K to each subblock, no matter the position in the tree/DAG, then wouldn’t this create freeloaders / tragedy of commons: rather than trying to get TXs in their block template just mine empty blocks and get paid because others would collect some TXs.
This is incorrect. You are missing the next step. The point isn’t getting these services to accept the subblock confirmations (though they could choose to, but 0-conf still better), it is that there will be far more consistent block times. Hash issue or not, this will make block times far more consistent, which is a win for anything requiring a confirmation or more.
This would be the only ±fair way to do it. If a miner has parameters set to not accept a tx, then they shouldn’t participate in the fee.
Don’t the same anti-fork mechanisms still exist? If this is a credible threat, then the general idea of crypto is flawed. Why would they want to fork if they risk not getting the next block and not being the majority chain? Good way to lose out on monies. Maybe I’m missing the point you’re making, though.
Main block will still be aiming for 10 minutes. Exchanges does not care about number of confirmations. They want finality guaranties. That’s why they wanted the 10-blocks deep rolling checkpoint. If we can improve this with 2 minutes block times and Avalanche, we should. I think Tailstorm is interesting, but I don’t see why we need to rush this. We should focus on better and faster finality guaranties instead.
Not at any cost, what are “we” willing to sacrifice to get those faster finality guarantees? Anyway, please move general talk about block time / finality here: Lets talk about block time
The topic here is Tailstorm, and whether we could make it (or something similar) work. Evaluation vs alternatives would come after we’d have some design we think could work.
When I say fork, I mean fork the subchain in order to get a cut of the fees from TXs already included in another’s subblock, bad choice of word, let’s use “branch” further on. Imagine a steady inflow of 0.1 fee TXs coming in at a steady rate of 2 TXs / block interval, and then one of those TXs has 1.0 fee instead of 0.1.
Where do we go from here? Extend the best tip with next 2 TXs, or branch to copy the 2 already mined ones + the 2 new ones? If everyone is just extending the longest chain then it wold look like this:
But, if one miner got the 1.0 fee TX, then another miner can make a branch in order to get a share of the big bounty:
The above is considering the idea of splitting the fee among duplicates, and still applying the branching penalty to lesser subchains.
It’s still better than the case where winner takes all the fees, which is essentially the same as what orphans do now, however the losing subblock would still contribute PoW:
Network gets the PoW security contribution, miner who contributed it gets nothing.
Currently, neither the losing miner nor the network get anything from it because the block would be reorged.
Yup, and looks like it could improve selfish mining, as well.
SubBlocks and SummaryBlocks. (both SB, joke here about hardest thing is naming). I’ll call it “FullBlock” instead of SummaryBlock here for that reason…
There are some higher level issues with the idea that I’m not sure people put on the table yet.
subblocks (SBs) are not required to inherit from each other. Technically every single miner can mine their own SB and only when the full block (FB) comes in are they combined.
This means that it is extremely likely to include conflicting transactions in different branches. Your node or indexer can’t reject one of two subblocks that may have been made at the same time with conflicting transactions. They both got mined. (At this point it makes sense to point out that miners CAN (and do) lie about their blocktimes)
And that means that the entire concept of “the blocks are faster, therefore stuff confirms faster” is out the window. Only when the FB comes in do you know which of the sides of a double spend is finalized, and if the subblock containing the tx that pays you is actually used at all. So you wait until the final block, just like today.
FullBlock POW or no POW?
There is also a choice to require mining a full block or simply make it implied.
If it is implied (zero pow) that means that a conflicting transaction is actually not settled until a full block later. We don’t know which section of subblocks miners are mining on top of.
If there are two subblocks that are in conflict (contain a double spending tx), both have no children blocks, then it’s 50% which one is valid. The FB may simply reject a SB.
So simple logic dictates that you need PoW to finalize the FB. As that is the basic requirement of the Byzantine Generals solution that Satoshi invented.
But if it has PoW, that opens a can of worms:
miners now have to choose which type of block to mine. A SB or a FB. If they choose wrong, they will get their block orphaned.
A FB can not be created until all SBs are validated and a new block template is created. Unlike today where the miner mines an empty block for the couple of seconds that this takes, this would not be legal (they can’t just mine an empty full-block).
As such this breaks header-first mining.
These two means that without infinite bandwidth and zero validation time, we’ll see orphans being created at massively higher numbers than today.
Notice that the numbers today are super low BECAUSE miners use things like header-first mining. So “massively higher” isn’t a high bar at all. Like growth from zero to 1 is a huge number of percent.
But I can guarantee you that miners will not be happy with it.
ps. it is useful to NOT assume there will be an exact correct number of SBs as needed for a FB. Apart from accidents, going for a fraction of full PoW cost, it is likely going to become worth it to have miner assisted double spends.
Not required, but they can and this is favored - because there’s benefit in choosing to extend the longest subchain rather than referencing the previous FB.
The penalty system incentivizes mining on top of best known subtip in order to avoid the penalty. It also incentivizes against subblock witholding because then nobody will see your blocks and they’ll extend the other branch while you mine in secret, and if the public branch wins - you get hit by the penalty if your branch will be shorter.
Why, if the mempool policy stays the same, how would you even obtain a conflicting TX? If anything, it’s likely that subs will include duplicates, like the scenario im_uname laid out:
a quick top-of-my-head example:
block A1-A2 is the longest subchain.
block B1 competes with A1 and has a transaction T1 that doesn’t conflict with A1, yet doesn’t exist in A1-A2 either. it’s a branch, uncle, whatever.
I now want to mine A3. Can I mine T2 that spends from outputs of T1, if block B1 “contributes” transactions? I assume I’ll need to include T1 first so my block is internally consistent. If I include T1, did block B1 actually “contribute” anything?
To which I answered:
I see, good Q, yeah you’d have to include T1, or you’d have to extend the subchain that already has it
Yup. Not rejecting is the secret sauce of Tailstorm, it integrates blocks that would otherwise be orphaned: takes in their PoW contribution + any non-conflicting TXs, and there’s PoW-based dispute resolution for conflicts.
Re. time, they can lie, sure, but it has no effect here. Accumulated PoW settles the dispute just like now, not the reported time. In case of equal PoW (same competing subchain length) it’s a coin toss based on subhashA < subhashB.
No, because if you observe your TX is included in a fast-advancing subchain, you can have some confidence that it won’t be replaced by another subchain - just like now you can have confidence that a 2conf won’t be reorged by another tip.
Miners are incentivized to announce their subblocks ASAP, so let’s say K=60, and there are subtips:
30 blocks
15 blocks
14 blocks
the network needs just 1 more SB in order to announce a FB, and then everyone’s expected to start mining on top of it, else they risk their extra SB getting reorged.
If you have a TX in 1., then you can be pretty sure it will win over whichever tip produces the last SB.
If you have a TX in 2. or 3., there’s uncertainty, if 3. mines the last SB and it has a conflict then it’s a coin-toss. If 2. mines the last SB then it wins over any TX in 3. but NOT against 1.
If 2 SBs arrive simultaneously, the FB picks one of them, and shortly after some SBs in the next epoch start appearing so the network can have confidence which FB won.
You can’t mine a FB unless there’s a pick of SBs available that would accumulate (1-K) PoW.
At that moment, mining a SB would imply overproducing PoW and you risk the SB getting reorged by some other miner mining a FB and not picking your SB. There’s incentive to go for a FB as soon as enough SBs have been announced.
You could still go for an empty SB or FB, why not? Not sure it breaks header-first, I’m not ready to claim either yes/no at this moment.
You’d see higher number of branching / 10min, but not orphans / 10min. That’s the secret sauce. The would-be-orphans get merged, their miners get paid (and only get hit by 1/K penalty), so latency has less impact on their profit, so big pools get less of an advantage over small pools.
If small pools are trying to stay on main branch in order to avoid penalty, sometimes they’d manage, sometimes they wouldn’t, and then you’d have something like this:
-- F -- o -- o -- o --o -- o -- o -- o -- o -- o -- o -- o -- F -- o -- o --
\ o \ o \ o \ x
When they’re not late - they just extend the best tip. When they’re late, they branch off the best tip, but their subs later get picked up by the FB. Only if they’re late to the last sub would their sub get orphaned.
Their loss here would be (3 * 1/K) + 1/K = K.
Compare that to just reducing block time, you’d have this:
-- o -- o -- o -- o --o -- o -- o -- o -- o -- o -- o -- o -- o -- o -- o --
\ x \ x \ x \ x
