New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Strawman] Refillable assets specification #1741

Open
TimDaub opened this Issue Sep 5, 2017 · 7 comments

Comments

Projects
None yet
5 participants
@TimDaub
Contributor

TimDaub commented Sep 5, 2017

Here is a solution for modeling refillable assets with our current transaction structure. I tried to keep it as simple and boring as possible. Feedback welcome.

TL;DR: Allow for refillable as value in transaction.outputs[x].amount. This basically transforms it into an arbitrarily double-spendable output.

Long version:

A valid refillable CREATE transaction is one that:

  • sets transaction.asset.refillable to true
  • includes a single, validly signed and formatted input
  • includes a single, validly formatted output, where output's amount
    must be set to the string value refillable (or e.g. infinite, infinity)
// Example of a valid refillable CREATE transaction
{
    "id": "abc",
    "inputs": ["<a single implicit input>"],
    "outputs": [
        {
            "amount": "refillable",
            "condition": {},
            "public_keys": []

        }
    ],
    "operation": "CREATE",
    "asset": {
        "refillable": true,
        "data": {
            "hello": "world"
        }
    }
}

A subsequent TRANSFER transaction spending a refillable output is one that:

  • sets its operation to TRANSFER
  • includes the CREATE transaction's id value as id in the transaction.asset object
  • includes a single, validly signed and formatted input that points to the refillable output to spend
  • includes a single, validly formatted output, where output's amount must be set to a value where: 1 < amount < 9000000000000000000.
// Example of a valid TRANSFER transaction spending a refillable output
{
    "id": "abcTRANSFER",
    "inputs": [
        {
            "fulfillment": "<valid signature>",
            "fulfills": {
                "transaction_id": "abc",
                "output_index": 0
            }
            "owners_before": []

        }
    ],
    "outputs": [
        {
            "amount": "1234",
            "condition": {},
            "public_keys": []

        }
    ],
    "operation": "TRANSFER",
    "asset": {
        "id": "abc"
    }
}

In cases where subsequent TRANSFER transactions have to spend > 9000000000000000000 of assets in one transaction, multiple inputs based on a single refillable output are permitted.

A refillable output is spendable an arbitrary number of times by the user controlling the refillable output's corresponding private key. Given the user controlling the asset's refillable output decides to assign control to another public key, a valid refillable TRANSFER transaction is one that:

  • sets its operation to TRANSFER
  • includes the CREATE transaction's id value as id in the transaction.asset object
  • includes a single, validly signed and formatted input that points to the refillable output to spend
  • includes a single, validly formatted output, where output's amount must be set to the string value refillable (or e.g. infinite, infinity)
// Example of a valid TRANSFER transaction assigning refill control to another
// public key
{
    "id": "abcTRANSFERrefill",
    "inputs": [
        {
            "fulfillment": "<valid signature>",
            "fulfills": {
                "transaction_id": "abc",
                "output_index": 0
            }
            "owners_before": []

        }
    ],
    "outputs": [
        {
            "amount": "refillable",
            "condition": {},
            "public_keys": []

        }
    ],
    "operation": "TRANSFER",
    "asset": {
        "id": "abc"
    }
}
@deweller

This comment has been minimized.

deweller commented Oct 7, 2017

If I am understanding this correctly, this allows an "issue more" operation on an asset in BigchainDB. Is that correct?

It also specifies a way to transfer issuing rights to another public key.

If so, I am in favor of the concept.

@TimDaub

This comment has been minimized.

Contributor

TimDaub commented Oct 7, 2017

@ttmc ttmc added the proposal label Mar 28, 2018

@ttmc

This comment has been minimized.

Member

ttmc commented Mar 28, 2018

Maybe this proposal could be turned into a BigchainDB Enhancement Proposal (BEP) and closed here.

@ttmc ttmc added make into a BEP and removed proposal labels Mar 31, 2018

@tozzi21

This comment has been minimized.

tozzi21 commented Apr 21, 2018

Valid proposal and necessary enhancement. In support of this proposal.

In practical terms, one approach be refillable does not propogate on TRANSFER, thereby allowing only the owner who CREATEd the asset to double-spend the asset.

Alternately, another approach be the owner of asset TRANSFERs to a 3rd party and specify himself in the output to retain ownership (for the ability to again later respend).

In latter case, how to make it possible to restrict recipients in the output of TRANSFER to not allow them to double-spend i.e. passing only the asset but not the right?

@AdrianPerez1994

This comment has been minimized.

AdrianPerez1994 commented Jun 12, 2018

I have tried this refillable assets token but I received bad respond like this.
{ message: 'HTTP Error: Requested page not reachable',
status: '400 BAD REQUEST',
requestURI: 'https://test.bigchaindb.com:443/api/v1/transactions?mode=commit' }

I have tried this according the rules above, but I can't find the reason why such error response returned.
This is my code and do you think is this code right?

const tx = BigchainDB.Transaction.makeCreateTransaction(
//Assets field
{
userIdentifier: 'names of user',
amountOfTokens: nTokens
},
// Metadata field
{
userIdentifier: 'name of user or sth else', // this part is used to search or get extra information of assets
time: new Date().toString()
},
// Output field
[BigchainDB.Transaction.makeOutput(BigchainDB.Transaction
.makeEd25519Condition(user.publicKey), 'refillable')],
user.publicKey
)

const txSigned = BigchainDB.Transaction
  .signTransaction(tx, user.privateKey)
let asset = txSigned.asset
let new_assets = {
    refillable: true,
    data:{}
}
new_assets.data = asset
txSigned.asset = new_assets
txSigned.inputs = ["<a single valid input>"]
console.log(txSigned)
// Send the transaction off to BigchainDB
conn.postTransactionCommit(txSigned)  

If you have a solution , please give a reply. Thank you

@ttmc

This comment has been minimized.

Member

ttmc commented Jun 12, 2018

@AdrianPerez1994 This issue is just an idea, a proposal. It hasn't been implemented and it might never be implemented.

@ttmc

This comment has been minimized.

Member

ttmc commented Sep 21, 2018

This is interesting... a new use case for refillable assets (or mint-on-demand tokens) that I hadn't heard of before:

Yesterday on Gitter, @8ana4nam1ni0n wrote:

is there a way that we can generate tokens "on demand" or thats not possible?

I replied:

Anyone can generate a new non-fungible asset, or a set of fungible assets, at any time, using a CREATE transaction.
but as mentioned earlier, there's a (high) limit on the number of fungible assets that can be created: 9 * 10 ** 18
If that's really not enough, then you can just create a second set, with the same number
ad infinitum

@8ana4nam1ni0n replied:

i would like to do it that way but my client requires that the token is created on demand.. what I dont know is that if each token will be compatible with each other since they are created in different transactions

I replied:

Your client could start by doing a single CREATE transaction that creates 9 * 10 ** 18 fungible tokens, where they own all of them, and then they could just transfer tokens to new recipients from their unspent outputs as-needed, on-demand.

@8ana4nam1ni0n replied:

thats what I told my client.. but he says that he added some sort of fixed value to the token and if he has all the tokens with that fixed value apparently some laws and tax stuff that I dont understand applies to it and harms his company.. since I lack of knowledge on that particular area I feel restricted on my answers and solution approaches.. so basically he wants that if a user needs to buy tokens from him he create the token on demand and give it to the user.. i dont know if that makes sense

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment