Hi,
I want to propose an issue mode that assigns asset units automatically to addresses which paid coins to a specific address.
In other words: if an address paid one coin to address A, this address should receive one unit of asset X.
It’s a bit similar to this proposal: Smart Property Example?, and yes, it would need some code changes, particularly a new issue mode.
I have looked at the PeerAsset code (still superficially) and I have already an idea how this could be implemented.
The idea would work the following way:
The creator of the asset X issues a deck and specifies the address where payments must be sent to receive assets (in the variable deck.asset_specific_data).
If you made a payment to address A, you can create a CardIssue transaction of asset X, referencing the output O you spent to address A (txid + output number) in card.asset_specific_data. The amount of X created must be equal to the amount paid to A.
—> this would require a change in the CardTransfer class, because in this case, the deck issuer is not the coin issuer like it is required until now.
The parser (it could be a custom issue mode) checks two things for each of the CardIssue transactions of asset X:
– First, if the transaction to A with output O referenced really occurred on the blockchain and was confirmed (confirmation requirements can be determined),
– Second, only the first CardIssue transaction referencing a specific output O is valid (the rest are considered bogus).
From my Python knowledge and the code I looked at, I think this concept should be possible with PeerASsets, but I have a worry: that this parser could be very CPU/memory intensive, as the validity check for a CoinIssue transaction is much more extensive than a simple check “cards really were issued by deck issuer” like in “standard” PeerAssets, and it seems to require several for loops.
Wanted to ask if there were already ideas for such an issue mode in the PeerAssets developer community?
I think this kind of asset would be very useful for a kind of “trustless ICO contract”, where the assignation of the assets occurs automatically, and the participants do not have to trust the deck issuer to really transfer the coins.
There was a lot of discussion about this type of peerasset in the past, culminating in ideas such as semi-automated basket creation (aside from the more straightforward ICO concepts):
Essentially, a mode like this could be used to do fully decentralized peerasset exchange (at least between peerassets that equally have this mode)
It is hard to specific examples of use cases for this that can’t be done with a basic script. For example, if you don’t trust the issuer, why would you want to participate in their ICO? You can always prove the issuer didnt follow through using the txid.
It’s certainly worth thinking about the possibilities and consequences of a mode like this.
Thank you for your answer already!
One use case where a solution requiring trust would not work is an utility token where the distribution is carried out by proof-of-burn, i.e. the address where the payments should be sent is unspendable (like Counterparty did its XCP distribution). The reason for such a scheme is simply to provide scarcity of the token, not the profit of the deck issuer.
In this case, there is nobody “in charge” of the address, and for the mechanism to work long term, a trustless mode would be necessary.
But it would also useful for smaller entities wanting to distribute a token, which don’t have the infrastructure to run a client in a reliable way 24/7 and taking care of the script working 24/7 too. It has also, I assume, “marketing” value because you simply would always receive the token, even if the address owner disappears, which could be useful, again, for utility tokens necessary for a service.
I hadn’t decentralized exchanges in mind, but that would surely be another use case.
I have begun to code a very early and rough prototype of the parser for this kind of issue mode, but have to refine it and test it (most likely on a private testnet).
Okay, so I guess there was no technical discussion about a possible implementation, right?
I’ll continue then with my tests in the coming weeks, and if the concept looks feasible, I’ll look at the RFC process and write a proposal. The thing is that I’m not a professional developer, so I before it to become implemented I would need somebody having a look on the code. The required changes don’t seem overly complex, though (only, as I wrote, I’m worried about ressource usage).