The only reason I can offer is what I’ve given above - but I’m developing a full node myself so my views are from a more generalized perspective. It’s also just an opinion, and not a conviction or faith, so if everyone lands on the same page and says “lets’ remove the limit entirely”, then I 'd be happy about that outcome as well.
I think its’ not good enough. If I fail to send given the UTXO’s I’ve selected, and I have other UTXOs I can use, then I shouldn’t be expected to wait. The problem is I can’t go around and try to brute-force the UTXO selection by broadcasting over and over.
Particulary so since this isn’t concensus, and one node might accept while another rejects.
I would like to be able to know the policy of the node I’m broadcasting too as part of any errors (too-long-mempool, utxo [outpoint] has X ancestors while we only allow Y), and better access to understanding my own UTXOs (how many ancestors does this UTXO have).
@freetrader @BigBlockIfTrue have you been able to conclude whether BCHN can remove the limit without adverse effect, or am I misunderstanding your take?
I don’t know if @BigBlockIfTrue has concluded something, but work on CPFP removal is still in progress. There are some open questions related to the keeping of counts (which we wanted to retain if possible even if we remove the CPFP feature), and the status is that we don’t know feasible the retention of that counting is. If we can’t count accurately, how can we maintain a limit? - this is one open question. The other is the performance under CPFP fully removed - we have yet to assess whether it would allow us to remove the limit entirely or how much we could raise.
Figures mentioned in this thread are obviously higher than the x10 increase for which we were conservatively aiming so far.
Even if we get positive results for the path of complete CPFP removal, I’d prefer is we also assess how much performance we can get out of it while keeping CPFP.
If push comes to shove, we could probably remove CPFP in BCHN first, and re-introduce it if there is an actual need for it, but it’s not my preferred route.
Was asked to add my comments here after making them on Telegram. I think they echo some already made but here goes:
Cache management is one of the hardest things to get right in “computer science” - and that’s ultimately what the Mempool is for our decentralized ledger. Right now we’re depending on undefined behavior (as in its not part of the “official” specification) where nodes have created an arbitrary limit as to how deep it can go. Worse yet, different nodes can have different limits. This gives us an excuse to ignore the actual realities of physical resource limits of whatever hardware the node happens to run on and likely results in an underutilization of its potential in most cases. Best to recognize that there are physical limits that will be hit and enact official behavioral guidance policies that will inform transaction submitters on what conditions might make their txs more likely to get prioritized. But absolutely make clear that a pure “fire & forget” wallet model in a decentralized trustless system is utterly irresponsible.
So I think we need to remove this limit but that’s only the first step in a much more complex and longer effort to make clear what is defined and undefined behavior for the network side of the protocol. The goal should be to clearly define the boundaries of what can be counted on and good heuristics to help devs understand the conditions that might make their transactions get kicked out and have to be submitted again. I admit our own initial BCH development assumed a fire and forget model as there wasn’t any documentation that implied otherwise. Perhaps a good specification of what a well behaved wallet model should be would be in order? Anyway - I’m glad to see the efforts BCHN are making to get this first step done and wish them luck.
2 Likes
I think we can say now with high confidence that we will be able to remove the unconfirmed tx chain limit from BCHN completely in May.
The time before May seems too short for us to fully explore keeping CPFP around in the way that BU did in their client. So BCHN client will most likely NOT support CPFP after May, at least for a while. If there is some real demand for CPFP that would merit additional complexity, we would consider re-instating it at some later time.
8 Likes
I’ve updated the post to match the proposed CHIP format/structure and updated this CHIP’s version to 1.1. These changes are reviewable at bitcoin-cash-chips/unconfirmed-transaction-chain-limit.md at master · SoftwareVerde/bitcoin-cash-chips · GitHub .
3 Likes
Without intending to be rude, I want to draw attention to the fact that the Technical Description section of this CHIP is essentially garbage at this time (unused template stuff and a link to another document without any context). I really want to urge the CHIP authors to improve this, quickly. At the very minimum, this section should specify the exact activation time and mechanism of the change.
2 Likes
Dude! This is just not helpful.
A CHIP is not meant as a technical document, its main (probably only) purpose is to convince the community to do something. And, indeed, the CHIP having technical details is immensely helpful to fulfull that goal.
But, really, when all clients already implemented the change what point is there to alter the CHIP? Its served its purpose. There is really nobody left to convince and hence the CHIP has fulfulled its purpose. People support it in its currenf form.
So, on top of you being rude you misunderstood the goal and you put on someone work that you have no right expecting them to do.
Edit:
As you seem interested in some soft of technical document for some reason, I invite you to write it. You want it, you get it written. Decentralized, no need to wait for anyone.
1 Like
If you want the community to do something technical, it is very helpful to include an actual technical description of what that something is, exactly.
Which clients have already implemented the change? How did they implement it? What activation logic do they use?
I am a BCHN maintainer and I am pretty sure that at least BCHN did not implement the change yet. We are working hard on getting it implemented, though. I am requesting technical details to be included in the CHIP so that we can be sure different implementations are in fact compatible.
Support in current form is meaningless if the current form does not include an actual technical description of what we are going to do.
I indeed have no right to expect this CHIP to be written properly. You also have no right to expect BCHN to implement this CHIP.
We’re trying to solve a collective problem here. I propose all parties do their part. For BCHN, that means getting the implementation finished. For the CHIP authors, that means getting the CHIP finished.
@joshmg is listed as the CHIP owner. I am noting a significant deficiency in his CHIP, so it’s primarily his responsibility to address the problem. I believe he is very capable to write this technical description himself, but if he would like assistance from BCHN devs, that is possible. (I similarly assisted with improving the multiple OP_RETURNs CHIP already.) Either way, a technical description belongs in the CHIP - as evidenced by the CHIP template chosen for writing this very CHIP.
4 Likes
Yeah, keep pushing. Realy nice.
I really don’t think its fair or even useful to bully others into doing work you want done. Really quite sad to see you act like this.
1 Like
Remove the chain limit at the previously defined timepoint of May 15th.
Can you say what more details you want?
For these reasons, it is requested that this change be implemented in a coordinated manner on May 15th.
This is too imprecise, and the problem is that the technical description section, which is supposed to provide the precision, points to a study report by BU instead of a technical specification part.
Yes, it is the onus of the CHIP writer to provide such a technical description, to the best of their abilities, or seek to involve others to assist them.
I’m thankful to @BigBlockIfTrue for stepping in and doing this for the OP_RETURN proposal already, it should be dead simple for this CHIP as you point out, it is only removing the limit at an exactly specified time.
FWIW, there was discussion in BCHN about exactly how to do this - MTP, wallclock time or block height, and we settled on using the MTP activation which everyone is well accustomed to.
This means we (BCHN) activate this delimiting when
the BIP113 median time is greater than or equal to 1621080000 (2021-05-15T12:00:00Z)
I hope this provides more detail to this discussion.
1 Like
Is it? Seems you are following rules and regulations about how CHIPs should be written and certain stuff is required, again, according to you.
There was no confusion about the activatoin time and your repo shows the timestamp already correct about a week ago. So the drama of pushing someone to come up with it and put it in his chip is just that, drama. Was that really useful? Is that really the way you want to cooperate and work on BCH together?
I keep writing that this is about PEOPLE working together, not to follow rules blindly because that gives the professional politicians an wide opening to hijack our movement.
What this means in practice is that it would really help a lot if you and bigblockiftrue would start showing up on the dev-meetups and show you are more than just messages here on this forum. Help understand where you are coming from and in turn let us show you that we are human too. Humans that don’t deserve you making demands like was done this weekend.
So, please show that this isn’t some power play and be human about it.
The bottom line is that a CHIP is a way to help people understand a proposal. There was no misunderstanding, there has been wide appreciation of this proposal and teams provided support.
And if you asked nicely, I’m 100% sure that Josh would work with you on an edit, if you find this so important. But honestly, adding that one line to an already accepted proposal, which isn’t even consensus critical, really isn’t worth the drama.
At the risk of belaboring this point, which I think is important.
CHIPs do not have to be technically specific at first, but the closer they get to consensus, the more specific & precise they should be.
Consider the larger context: People who come to BCH without the context of preceding, distributed social media discussion or social familiarity.
A CHIP should - eventually - provide all they need to understand and implement, correctly , the proposal.
There was no confusion about the activatoin time
There was sufficient lack of clarity that I requested, internally in BCHN, to create a top-level document for the upgrade and for that document to provide the exact time for activation of both CHIPs, since I was unsure at the time whether this CHIP would receive further specification.
I have spoken privately to @joshmg today and learnt that work on refining the Technical Description had already been tasked and is underway.
and your repo shows the timestamp already correct about a week ago
Again, we strive for an outcome where CHIPs carry this information so that implementors do not have to guess it.
Without it, the term “correct” is simply inapplicable - “undefined” would be a better term.
Note that it is conceivable that CHIPs may be formulated to activate under slightly different circumstances, and would usually consider what schedule is reasonable given their complexity and the specific technical issues they’re addressing.
Which is why it makes sense to include the exact proposed activation in a CHIP (best time to include is once this has been roughly agreed upon after consultation with others, but a CHIP author is of course free to just propose what they want without such initial consultation).
3 Likes
So all you’re asking is a little good housekeeping, and all Tom’s asking is to be nice about it!
1 Like
Thank you so much for toning it down and starting a private dialogue about your needs. I consider that a win!
3 Likes
I am glad we are coming closer to an agreement.
We actually have a common goal here, so it’s important to try to understand other viewpoints even if they differ a lot.
1 Like
There was a lot discussed, but that being said, I think there are only a few things I need to address.
-
I think requesting that a section be improved is a legitimate action. I also understand the initial reaction from Tom–while I don’t think @BigBlockIfTrue meant to be negative in his phrasing, I also must admit it could have been worded better. However, language and cultural barriers are real, especially when collaborating with people across the world on a project as large as this. I think it’s important to try to assume no ill-will from anyone working on BCH, especially those that have been around for a while.
-
John (Jamiel) had been tasked with asking BCHN for some help regarding the technical section of this CHIP more than a week ago, but unfortunately time has gotten the better of us with other priorities. Additionally, John doesn’t have the facilities to make a recommendation, and furthermore, I cannot personally recommend a technical specification on this change due to its specifics being heavily dependent on each the node implementations’ existing architecture. For instance, Bitcoin Verde doesn’t even have an unconfirmed txn chaining limit currently, so writing a specification from Verde’s perspective does not make any sense. Another example is that BU has made its own changes to CPFP and, to my knowledge, automatically re-relays txns past the current limit, which means their technical specification could also vary wildly. It is also not my intent (or even right) to suggest/demand that BCHN removes a feature (i.e. CPFP) in order to make this change, and I would feel uncomfortable making a technical specification/recommendation alluding to that.
Ultimately, I think the important thing we need to focus on in order to do our due diligence to 0-conf security during the upgrade is that we all agree on an activation time and a policy for reorgs. This suggestion comes from the BCHN slack, and I am grateful for the time and energy they’ve put in to collaboration.
I will be making a PR to Bitcoin Verde’s copy of this CHIP and then copy those changes here. This PR will make an attempt to document the activation BCHN has proposed, as well as their reorg/activation policy: essentially
MTP >= 1621080000and once activated, it does not de-activate in the case of a reorg. Anything more sophisticated than that does not seem to outweigh the implementation complexity.Once the activation logic is document, it might be prudent to gather feedback from @AndrewStone and others to ensure they don’t have any problems or limitations with the proposed activation.
-
Regarding BCH Dev hangouts–while totally not on-topic for this thread, I do want to address the purpose of the BCH Dev hangout group in close proximity to the problem it’s trying to solve: the mildly unfriendly conversation that happened above I think could have been avoided in a couple of different ways, but in the end I think would have been diffused more immediately by developers interacting with one another in a medium that personifies one another. …kind of like disarming road rage. The more we interact in a way that is friendly and amicable, the less inclined we’ll be to jump to the assumption that something written mildly out of flavor was an intentional slight. Furthermore, these BCH Dev Hangouts are supposed to be fun and whimsical, and definitely not meant to shame those for not attending. I think there are plenty of logistical and personal reasons to not come, and I think we should respect that choice, and I definitely don’t want participation to be used as a wedge or weapon.
Anyway, I want to say thank you all for your time, energy, and passion put into making this change a reality. In the end, these CHIPs are just tools used to document our logic and decision making process for future generations, as well as a tool/framework to better communicate with one another. I think we’re learning lessons along the way, and I hope we can all continue to collaborate efficiently and amicably, regardless of the process/framework we’re operating under.
2 Likes