Remove sequential increment requirements for Child Bounties

[itsbirdo]

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

When you create a child bounty it needs to have a unique ID, which has to be +1 from the last unique ID in the system.
This is fine if there is only one bounty active at a time, but there are many active bounties and we'll see more and more active bounties coming along. This leads to collisions in transactions, resulting in frustration, delays with sending funds to individuals and lost transaction fees.

Example: I create a child bounty, with the id 135, but it takes the signers on the multisig 24h to review and sign the tx.
If another bounty proposes a child bounty with the ID 135 and it gets signed before mine, my transaction will fail. Now imagine this multiplied by many bounties.

As an individual managing a bounty I have had this problem first hand. I know many other bounty managers also struggle with this design decision from how bounties operate.

Request

I would propose to change the way child bounties operate to not use an incrementing ID across all bounties.
Also ensure that child bounties don't need to be sequentially signed based on when they were raised.

Solution

I would propose to move to a user generated GUID, which would reduce collisions to almost zero, however any alternative approach could work.
Another option could be that child bounties need to start with the main bounty number,
e.g. Bounty 37, child bounty 1 (37-1) which is increased sequentially, this results in zero collisions, proving the bounty manager doesn't make a mistake.

Are you willing to help with this request?

Yes!

[ggwpez]

Sorry am not really familiar with the Bounty pallets. Can you post a link maybe to a failed Subscan extrinsic?
Is it the ChildBounties::add_child_bounty call that fails or a different one?

[ggwpez]

Probably its this https://polkadot.statescan.io/#/extrinsics/20813055-2:

They are trying to send two calls in a batch and just guessing the childBountyId. So sure it can be wrong if another addChildBounty call came first. Could be solved by attaching a curator proposal directly to the add_child_bounty call.

Another way would be to add a custom XCM instruction (probably controversial), since you basically want to get the "return value" of the first call as argument for the second one.

[itsbirdo]

It doesn't matter if you try to send two calls in one batch. Please review the use case, this will still happen if you are proposing just one transaction in a child bounty, batch or no batch.

Example: I create a child bounty, with the id 135, but it takes the signers on the multisig 24h to review and sign the tx.
If another bounty proposes a child bounty with the ID 135 and it gets signed before mine, my transaction will fail.

This is why the number needs to be a guid (or something else) and not a sequential increasing number