Improving ChildBounty ID Allocation: An 8-Digit Solution Proposal

[CoinStudioDOT]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Motivation

Hi,

The Polkadot/Kusama Bounty payment system is currently set up in a way where each payment is assigned to a specific ChildBounty ID. However, this setup leads to a common situation where the duration it takes for a multisig to be signed and reach its threshold often leads to these pending ChildBounty IDs becoming obsolete. This happens because other ChildBounties, which have been approved while these are pending, take over their IDs.

To illustrate this, let’s imagine that Bounty 10 initiates a multisig transaction and picks up the first available ChildBounty ID, let’s say ID 133. This ID 133 is not marked as “taken” or “reserved” anywhere in the system. So, when another bounty, say Bounty 20, comes along and wants to issue its own multisig transaction, the system will show ID 133 as being available, as it doesn’t recognize it as being tied up in the pending transaction for Bounty 10. As a result, Bounty 20 also picks up ID 133 for its multisig transaction, leading to a conflict where only the first signed tx will be executed.

This current setup can lead to inefficiencies and confusion, as multiple bounties are essentially competing for the same pool of IDs, making it difficult to track the status of specific bounties.

Request

As an alternative solution, it might be beneficial to assign each bounty its own unique set of IDs, separate from other bounties. This way, there would be no overlap or takeovers. Every bounty would have its unique identification, unaffected by the progress of other bounties. This could significantly improve the tracking and management of individual bounties, improving efficiency and reducing potential confusion in the bounty payment system.

Solution

A simple solution would be to use an 8-digit ID system, combining Bounty and ChildBounty IDs. The first four digits could be the Bounty ID, and the last four, the ChildBounty ID. This would provide each ChildBounty with a unique ID, removing overlaps and making tracking easier.

For the Bounty 20 and Childbounty 133 scenarios described above, a new ID is going to be 00200133.

Taken from https://forum.polkadot.network/t/improving-childbounty-id-allocation-an-8-digit-solution-proposal/3566

Are you willing to help with this request?

Maybe (please elaborate above)

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/improving-childbounty-id-allocation-an-8-digit-solution-proposal/3566/14

[paradox-tt]

Hi Coin,

Thanks for carrying over the discussion to a forum for developer discussion.

I would like to take a stab at rephrasing "the problem".

It is common for child bounties to be awarded in one batch that incorporates four extrinsics or multiples thereof:

1. addChildBounty(ParentBountyID, Value, Description)
2. proposeCurator(ParentBountyID, ChildBountyID, Curator, Fee)
3. acceptCurator(ParentBountyID, ChildBountyID)
4. awardChildBounty(ParentBountyID, ChildBountyID, Beneficiary)

While most input parameters are known at the time of execution, the child bounty ID is taken predictively. Most bounties are curated by multi-sig accounts and delays with approvals permit other curators to execute similar transactions which invalidate the predicted child bounty IDs.

This is more a matter of convenience more that it is a system issue. One could...

1. Issue a batch of addChildBounty(...)
2. When it is executed collect the certain child bounty IDs
3. Execute proposeCurator, acceptCurator and awardChildBounty using the established IDs.

This would take require two requests for approvals but it would lend to expected execution.

With no offense intended, I do not like your proposed solution for the following reasons:

• Keeping track of the counts for each child bounty using int representation would be cumbersome. A proper implementation would best utilize a map with a counter for each bounty.
• Taken per example, it imposes a limit on the number of child bounties of 9999
• We can debate padding scenarios but this is NOT ideal and can lead to allocative inefficiencies i.e. batches of numbers with no use.

With that said, I disagree that the issue of convenience surrounds the common child bounty index but rather the lack of an atomic extrinsic to achieve steps 1-4.

My humble suggestion, create a single extrinsic that executes steps 1-2 without the need for entering a child bounty ID such that the child bounty id generated by 1 lends into 2. Allow further execution of 3 and 4 if the child bounty curator is the signer.

I hope this brings clarity to the matter but I would love to hear the take of the core-devs for my own development.

Regards,
Will | Paradox

[CoinStudioDOT]

Dear Will | Paradox,

Firstly, I want to express my sincere appreciation for the time and effort in rewriting the post and providing your perspective on this issue.

However, this seems to be same misunderstanding of the problem as previously explained in the forum post.

The challenge here relates to multisig transactions that remain pending over several days, NOT the process of child bounty ID allocation itself. In a perfect scenario multisig acting as a 'lazy consensus' mechanism, should be able to take as long as needed to reach consensus, free of time restrictions. However, our current ChildBounty ID restrictions pose a challenge to this laid-back approach, demanding a quick multisig executions.

This would take require two requests for approvals but it would lend to expected execution.

Your approach is thoughtful but it appears to add an extra layer of complexity to the problem without addressing the problem core. The problem lies in the ID interference caused by delayed multisig approvals. Splitting the batchcall extrinsic into a few steps is not solving the multisig time issue. The proposition we are discussing here aims to evolve this process. Instead of relying on these ‘quick fixes’, we want to create a system where each bounty operates independently of others, eliminating the risk of ChildBounty ID overlap.

What we're trying to achieve is an environment where each bounty operates independently, without dependency on the progression or status of others. The proposed 8-digit solution was suggested with this goal in mind - to eliminate dependencies and ensure that the child bounty ID allocation process is uniquely tied to each individual bounty. I am interested to hear in any variations of this solution. 8-digit ID solution is a proposed option that we can start from.

Your concerns regarding the limitation on the number of child bounties and potential inefficiencies are duly noted and appreciated. However, this has a very low impact as it is not likely that a single Bounty will issue more than 9999 child bounties. Even if this become the case, a proposer can open a new Bounty and start issuing child bounties from 1 (relative to the new ID xxxx0001).

Just to clarify, the proposal on the table is NOT suggesting using the current child bounty ID system, but rather to introduce a new unique identifier. This unique ID would be a combination of the parent bounty ID and the child bounty ID (proposed solution), allowing each bounty to function independently and eliminating the current dependencies.

Once again, I'd like to express my gratitude for your valuable contributions to this discussion. I would really love to hear from the core devs to hear their take on possible implementations.

On a side note, a similar issue was opened by @annaelleparity paritytech/polkadot-sdk#591 that I didn't pick in the first place.

[paradox-tt]

What more can I say...

The solution I'm proposing is a single extrinsic that would generate the child bounty ID upon execution (after all multi-sig approvals are obtained). It would then feed the child bounty index into the other functions that are commonly batched with the call. It is independent of approval time.

[CoinStudioDOT]

I see several advantages to the approach of assigning separate, unique IDs to each bounty, as Annaele suggested.

-Having a separate system for Childbounties IDs tied to their parent bounty ID would help curators and the community gain a better overview of childbounties-related data (i.e how many, for which bounty, how often, recurrent implementers profiles/recurring beneficiaries, etc.)

We are all here with a common goal - to make our processes as efficient and user-friendly as possible. As such, suggestions for simplicity are always welcomed as the assembly of multiple child bounties and related extrinsic can at times be quite cumbersome. Having said that, I believe that auto-generation of childbounty IDs could help curators eliminating the need of searching for the first available child IDs.

[anaelleparity]

Thank you for bringing this issue up, @CoinStudioDOT.

From my perspective, it is pretty clear that the current indexing system for childbounties is rather inefficient and cumbersome for those involved in bounty curation, as well as obscure and arbitrary for those who aren't.

When designing systems that are meant to be used by decentralised communities, it is important to reduce unnecessary complexity as much as possible and support transparent operations.

Updating the current Childbountied ID system would only be the first step in the process of making bounty curation more manageable for curators and more approachable for the general community; but it is a critical one.

Thank you to @paradox-tt for being so reactive and committed to proposing alternative arrangements. I am hoping that more propositions will follow up in time, so that we can address this issue in practice sooner rather than later.

Thank you! 🙏

[paradox-tt]

Hi @anaelleparity and @CoinStudioDOT

I respect that your perspective is non-technical; I'm also trying my best to appreciate why you're adamant towards this 8 Digit solution when I've proposed a more efficient solution which:

1. Introduces no new storage variables to the runtime
2. Doesn't require a user to understand a proposed convention of child bounty IDs
3. Brings about the desired outcome even when approval is delayed (Multi-sig approval scenario)

What I've suggested means that you don't need to interact with child bounty IDs at all.. may I ask why do you think you NEED to interact with it? Maybe if I understand your pain points, I can have a better appreciation of your point of view.

[anaelleparity]

Hi @paradox-tt,

I think you might have taken my statement re: "updating the current Childbounties ID system" a bit too literally, meanwhile I am discussing the big picture at play here.

I am interested in any proposal that solves the issues I have described here, including making it easier for non-tech folks to navigate bounties and childbounties and pull out meaningful data. From what I know, this touches upon many different areas of dapp development such as UX and UI, not just programming.

I am certainly not in a position to decide unilaterally what works for everybody and push for its immediate implementation. And this is why I wrote that I was hoping we would get more input from the community at large and devise more engaging alternatives together.

Thanks for your time.

[CoinStudioDOT]

Hey @paradox-tt

I appreciate your active participation and the perspective you bring to this discussion.

I have opened an issue to address the particular problem of delayed multi-signature transactions and to introduce a more sustainable system for tracking bounties and child bounties as mentioned in the posts above.

The proposed new 8-digit ID is an illustrative example of a solution for the core developers to assess the situation and see the best possible implementation of such. The goal of this topic is to open dialogue and find the most effective and efficient solution to the problem at hand. In that spirit, all suggestions are warmly welcomed and carefully considered including yours. The final decision and choice of how the problem will be solved should lie with the parity cor dev who will work on the issue.

I want to ask you to keep the conversation open and respectful rather than calling other solutions a non-technical perspective and approaching the conversation by saying my solution is more efficient. In stating this, I intend no offense, merely a reminder of our shared objective. We're all here with a common purpose: to collaboratively solve problems and advance our project. Let's continue to work together in a spirit of mutual respect and open-mindedness, valuing each contribution. Thank you for your engagement in this process.

[paradox-tt]

@CoinStudioDOT I'm sorry that you're offended by the use of non-technical, no offense was intended. An end-user's perspective is also very valuable. I was hoping for a more analytical discussion but it seems we are not coming to a meeting of the minds. I'll hold on responses until said is provided.

[CoinStudioDOT]

I appreciate your understanding, @paradox-tt , and rest assured that no offense has been taken. The aim here is indeed an analytical and constructive discussion. Various perspectives often offer invaluable insights in problem-solving. Let's continue the dialogue with this spirit of collaboration and inclusivity. I'm looking forward to further discussions and contributions on this topic.

As previously mentioned, I strongly agree that there's significant room to improve and simplify the current process of required bounty batched calls. Your proposed solution, while not entirely addressing the specific issue we're discussing here, could contribute to simplifying the process of batching calls through the auto-assignment of child IDs. This is something that could be valuable in its own right and should be further explored.

[xlc]

Let's focus on the problems that we want to address first before diving too deep into the details.

To clarify, the root problems are

• Generation of a child bounty is non-deterministic (in the way that you can guess what it could be but cannot guarantee the value before it is created).
• A common workflow is to perform the creation of child bounty and additional operations (propose curator) in a single batch call from a mutlisig account. Due to the previous point, which process is error-prune.

@CoinStudioDOT 's suggestion is essentially to make the child bounty ID generation is fully deterministic. The exact way can still be discussed as for example 1000 child bounty limit per bounty may or may not be enough. We also need new storage to keep track of the total child bounty count for every bounty.

What @paradox-tt 's suggestion is to solve the second point by merging the batch calls into a single extrinsic that doesn't need the child bounty id. Something like addChildBountyAndPropsoeCurator(ParentBountyID, Value, Description, Curator, Fee). The benefits of this approach is that no storage modification is required.

@CoinStudioDOT could you describe bit more about the current workflow including details like how many calls to execute, the content of each batch call, etc. I am sure your proposal will solve your problem but wanting to check if the other solution is feasible as well. In the end, we want to explore all the possible solutions first before arriving in a decision.

[CoinStudioDOT]

Hi @xlc,

Thank you for your input. Your points are correct:

To clarify, the root problems are

• Generation of a child bounty is non-deterministic (in the way that you can guess what it could be but cannot guarantee the value before it is created).

• A common workflow is to perform the creation of child bounty and additional operations (propose curator) in a single batch call from a mutlisig account. Due to the previous point, which process is error-prune.

I believe this recent example can better demonstrate the content of the batched calls.

The current workflow is to assign/adjust structured batch calls like in the example above and issue to multisig. After the extrinsic submission, it is a typical case to wait an extended time for multisig to reach the minimum consensus and execute the call.

Due to some complexity on how to effectively track each Bounty payment (childbounty) and have it clear and transparent for a wider community, I believe a ChildBounty IDs is useful in this sense. If there is an effective way to solve this, I am in favor of any solution.

One other thing that came to my mind is the option that during Bounty creation bounties.approveBounty, an option for Bounty to predetermine and reserve a childbounty ID range for future use. This may solve this problem but introduce some other id tracking issues.

Thank you for your time looking at it and looking forward to get the problem solved.