CHIP - Unconfirmed Transaction Chain Limit

CHIPs Standards Track
,
#41

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
#42

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.

#43

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
#44

So all you’re asking is a little good housekeeping, and all Tom’s asking is to be nice about it!

1 Like
#45

Thank you so much for toning it down and starting a private dialogue about your needs. I consider that a win!

3 Likes
#46

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
#47

There was a lot discussed, but that being said, I think there are only a few things I need to address.

  1. 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.

  2. 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 >= 1621080000 and 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.

  3. 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
#48

I think one can distill it down to the minimum:

The current policy limit of 50 on unconfirmed ancestors or descendants is to be removed entirely once MTP >= 1621080000 and this limit removal remains applicable during runtime even in the case of a subsequent re-org to below that MTP.

Something like that. @BigBlockIfTrue, do you think that’d be adequate in terms of content? Or should it be more explicit about mentioning that this applies to both mempool acceptance of such cases and the relay of involved transactions?

2 Likes
#49

That’s perfect from my perspective, FT. Others are welcome to comment here or on the PR:

2 Likes
#50

I’ve updated the technical specification to include activation time. Concurrently, I’m reaching out to Calin and Stone for additional content to flesh out any other remaining details that may be required.

2 Likes
#51

Apart from the unconfirmed chain limit on transaction count (50), there is also an unconfirmed chain limit on transaction size (101 kB). Please update the CHIP so that both limits are removed.

2 Likes
#52

I talked with the other node teams; it’s my understanding the tx chaining size removal is also not a problem, so John added it in the most recently available version (v1.2.1).

1 Like