In this thread, I would like to discuss modifying the issuance code to allow asset owners to make certain changes simultaneously that they currently perform separately.
For those that don’t know, the issuance message in Counterparty is multipurpose, with it you can…
- Create a new asset with N tokens.
- Update an asset, so more tokens are circulating.
- Update an asset, so it is locked (no new tokens).
- Update an asset, in order to edit its description.
- Update an asset, to transfer address ownership.
Some of these actions you can do simultaneously, but most you cannot…
- You cannot transfer an asset AND increase its issuance.
- You cannot create a new asset AND transfer it.
- You cannot create a new asset AND lock its issuance.
- You cannot create a new asset AND transfer it AND lock its issuance.
So, at present, counterparty-lib requires most actions to be handled separately, but it appears to be more a matter of preference than a matter of technical limitations. If I’m reading the code correctly, you can transfer assets AND lock them.
If we work on allowing simultaneous changes, asset owners will incur fewer Bitcoin transaction fees. I also think such an improvement would aid interesting subasset use-cases.
Some of the code that would need to be changed…
Prevents transferring AND issuing…
IMO - This code seems to enforce a preference for major actions such as “transfer” to be separate, but perhaps that’s not something we really need to enforce.
218 if destination and quantity:
219 problems.append(‘cannot issue and transfer simultaneously’)
I think this could be removed, I believe the code after this check would work as expected.
Prevents creating AND locking assets…
These two pieces of code are related. The first lines (147-148) prevent users from locking an asset at its initial creation, a second tx is required to lock the asset after its creation. The second line (392) handles re-using the last description, in the case of performing a “lock” action.
147 if description.lower() == ‘lock’:
148 problems.append(‘cannot lock a non‐existent asset’)
392 description = issuances[-1][‘description’] # Use last description. (Assume previous issuance exists because tx is valid.)
Basically, to lock an asset, you set the description to “lock”. That’s taken as a command by counterparty-lib, but is not stored as the literal description, the last issuance’s description is used.
I think we should just get rid of 147-148. That should allow you to create a locked asset.
To handle the asset’s description when locking, we have some options…
- We can add logic to use either the last issuance’s description OR blank if it’s a new issuance.
- We could do something like
lock("My description here")rather than simply
So, I would be interested to know if this is a feature that people would like or use. I think the major use case is for subassets, like I could issue and transfer a subasset in one bitcoin tx, but it’s useful generally as a way to minimize bitcoin txs required to perform routine actions.