Improving ChildBounty ID Allocation: An 8-Digit Solution Proposal

1

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.

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.

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

Do you think this approach could be an effective solution to our current challenge? I welcome any thoughts or suggestions you might have.

Thanks!

2

Is there a technical reason we can’t auto-increment and assign on creation?

3

This is doable and I can’t think many downsides other than we have to figure out if we need some compatibility considerations with existing bounties.

1 Like
4

They are already. The core issue is about name spacing.

5

Maybe we have different definitions of auto-increment and auto-assign. To me, that means, we don’t need to enter an ID when creating a child bounty, that the field would auto populate with the next free available child bounty id. Currently you have to manually define the id and can use the ids arbitrarily – it doesn’t seem very “auto-increment auto-assign”.

6

That’s not the case. You don’t specify child bounty id when create one and it got an assigned id that’s child bounty count.

2 Likes
7

What would be the best way forward with this? Opening a Github issue?

8

Hey guys,

I can appreciate your perspective on this as I’ve also shared similar thoughts with my first interactions with childbounties many moons ago. The introduction of separate index allocation reduces (but does not eliminate) the likelihood of collisions.

I think the best approach would be to auto-increment but I’m wondering if if each transaction within the same call would increment the childbounty count counter or would it be constant for all transactions within the batch. If this is the challenge then we can enumerate each child bounty call 1, 2, 3, 4… such that the index would be const childBounty.count +1, childBounty.count +2 etc.

May I ask if you’re doing these things manually? I’ve found that scripted approaches with atomic calls lend for smooth operations. There’s so few active bounties that collisions should be minimal and should they occur the likelihood of a collision with the next block should tend to 0.

9

Hello,

Thank you for your insights and suggestions, they are certainly valid in a number of scenarios. However, I believe there might be a slight misunderstanding of the issue at hand. The problem we’re encountering primarily relates to multisig transactions that, due to various reasons, may take several days to reach their approval threshold. During this waiting period, other bounties might come into play and claim the same ChildBounty ID, thus creating a conflict where the first confirmed childbunty will execute and others with same ID will fail.

Furthermore, in scenarios where a single bounty has issued almost 400 child bounties, the ChildBounty ID landscape becomes rather crowded. This presents a unique challenge and underlines why a unique ID allocation system that separates ChildBounty IDs for each bounty is a way to solve the problem. By having a unique ID, each ChildBounty can be processed individually, unaffected by the operations of others
meaning each Bounty can run independently of each other.

In the current system the process of submitting a ChildBounty on the Kusama/Polkadot network involves several steps using the ChildBounty palette. Introdicing a unique childbounty ID will remove the urge on the multisig participants to sign the call asap.

Screenshot 2023-07-30 at 18.59.15
Screenshot 2023-07-30 at 18.59.152962×2186 472 KB

10

Hey Coin,

I totally understand the problem and I agree that we can craft a better solution. The curators I interact with normally react fast enough to have averted this issue. If we are caught we don’t have to manually setup the extrinsic all over again, we just run a script and the id’s are updated within a new call-data hash. All descriptions, fees, recipients are held in separate storage items.

If I had to ponder a solution I would suggest something like the below. Please try to grasp the concept and appreciate that I am not a frame developer. I could probably hack away to get it functional but this is just a forum discussion.

		
		//Type to define bounty line items
		pub type bounty_line_item{
			child_curator:AccountID, //Child curator address
			fee: BalanceOf<T>, //Curator fee
			value: BalanceOf<T>, //Value to disburse
			description: Vec<u8>, //Description for child bounty
			beneficiary: Option<AccountIdLookupOf<T>> //Account receiving funds
		}
		
		
		//Decorator to ensure that all entries are executed in an atomic manner
		
		/*
		  Single extrinsic to award a child bounty and propose a child curator.
		  If the submitter is the child curator then accept the child curator position
		  and attempt to award to the beneficiary
		*/
		pub fn disburse_bounty(
			origin:OriginFor<T>,//curator
			parent_bounty_id: BountyIndex,
			bounty_entries: Vec<bounty_item> //An array of items conforming to the type above
		) -> DispatchResult{
			
			/*
			   Do verification stuff here like ensure the bounty exists,
			   that it has funds and that the origin is the curator of this bounty
			   etc.
			*/
									
			for bounty_item in bounty_entries.iter() {
				add_child_bounty(...);
				//get child bounty index and use in the following
				propose_curator(...);
				

				if(bounty_item.child_curator == Origin){ 
					accept_curator(...);
					award_child_bounty(...);
				}
			}
					
		}
11

Thank you for the provided feedback and for your thoughtful insights on this matter.

I want to remind that in our current situation here, we have a workaround. When curators notice their ChildBounty IDs have been taken, they simply cancel the previous multisigs and issue new ones. This does the trick for now, but it is clear that this solution is not ideal in the long run despite how the new extrinsics are generated.

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.

I view multisig as a form of ‘lazy consensus’ mechanism - a process that can span over weeks, allowing stakeholders time to reach an agreement. However, our current ChildBounty ID restrictions pose a challenge to this laid-back approach, demanding a quick response.

I will keep this topic open for a few more days to see if we can come up with alternative solutions that might be easier to implement compared to the proposed 8-digit system. If there are no further objections or suggestions after this period, I’ll proceed to open a GitHub issue. I am hoping that the Parity developers will then take over and propose and develop an effective solution to the mentioned problem.

12

I will suggest open a github issue now. You already have an issue and a potential solution. Have a GH issue will help get attentions from Parity devs and they may be able to provide more suggestions.

1 Like
13

Thank you for the feedback. I will take your advice and proceed to open the GitHub issue on the matter.

14

Github issue opened https://github.com/paritytech/substrate/issues/14686