PeerAssets: Whitepaper

It has been confirmed that Chinese translation of the whitepaper will be released this weekend.

Is anybody working on a Japanese version, since they seem so interested in assets?

Is anybody working on a Japanese version, since they seem so interested in assets?[/quote]

Nobody has offered to translate to Japanese or any other language except Mandarin Chinese.

I have a new use case.

Lets say you have a website
and you want to create a separate area where only shareholders may enter.

enter https://github.com/bitid/bitid + PeerAssets
boom now only shareholders may proceed

:))

want to see ‘Deadpool’? Buy a ticket and it gets send to your phonewallet.
Scan a QR at the door and you are in ::slight_smile:

Wow that’s nice!
Thanks for sharing.

[quote=“thehuntergames, post:24, topic:3896”]I have a new use case.

Lets say you have a website
and you want to create a separate area where only shareholders may enter.

enter https://github.com/bitid/bitid + PeerAssets
boom now only shareholders may proceed

:))

want to see ‘Deadpool’? Buy a ticket and it gets send to your phonewallet.
Scan a QR at the door and you are in ::)[/quote]

Awesome.

I like the movie ticket example. So a ticket would be a token issued via PeerAssets?

Should we port bitid to Peercoin?

I think the bitid aware wallets are already extended for bitcoin

Whats needs work is the backend part, doing the P2TH querying and proof of timeline I guess

Question:
How does change addresses fit in this protocol?

It seems unpractical to send all your unspent coins to someone without change.

If there was a change address, how would you know which one is the actual token-recipient?

There is no need for a change address.
Change addresses exist in bitcoin (and peercoin) because the concept of an address is purely artificial through the P2PKH concept that allows transactions to be bound to addresses.
With PeerAssets there is no need to spend a full transaction, as balances are checked at address level and not at transaction level.

Does that makes sense? Or do you still believe change addresses are needed?

[quote=“thehuntergames, post:28, topic:3896”]Question:
How does change addresses fit in this protocol?

It seems unpractical to send all your unspent coins to someone without change.

If there was a change address, how would you know which one is the actual token-recipient?[/quote]

You don’t even need to transfer any PPC to a new PPC address to transfer PeerAssets.
My understanding is that you use the private key of the PPC address, to which PeerAsset tokens are associated, to issue a transfer of PeerAsset tokens to another PPC address.

this needs some explaining:

I have 0.30 ppc at the moment in one address.
To spawn I make according to the protocol the following outputs:

  1. 0 ppc to OP_RETURN
  2. 0.24 ppc to change address which i choose ti be the same as input
  3. 0.05 ppc to P2TH(myassets/lolcats)

Now I have 0.24 ppc which I use to issue coins with these outputs:

  1. xxx? ppc to Card receiver (new owner)
  2. 0.05 ppc to P2TH address derived from asset ID
  3. 0 ppc to OP_RETURN (metadata: 100)
    4) xxx?ppc no change address defined which means the Card receiver gets all remaining ppc coins?

Ok now I get what you mean. (I thought that you were referring to PeerAsset change)

It’s a good point that this is not explained in the paper.

In the feedback to [member=30983]peerchemist[/member] I stated that there should be agreement that the first transaction output should be to the card receiver.
So that any transaction output after the 3 obligatory ones can safely be ignored.
You are correct that there is still need for a PPC change output to make sure that your PPC are not lost.

Good remark!

I’ve envisioned to solve this by sending the change back to the sending address. As sending cards to self is equal to having cards in the first place this is effective and will be easy to parse from the blockchain by the client.
Ie, in PeerAssets Peercoin transaction there would be only one referenced address which is not 1) sender, 2) P2TH derived address.

But yes, this is not written in the paper. I have just forgotten about it while I was writing.

Do you think this is good enough solution? If you agree I will write up the text explaining this and place into appropriate places in the paper.

[member=30983]peerchemist[/member], thehuntergames is not referencing the change address for PeerAssets as that one is not needed.
He references the real P2PKH outputs of the peercoin transaction holding the OP_RETURN, …
The point is that you need to spend the entire output of a ppc transaction and that you need a ppc (not PeerAssets) change address to not spend the total amount of ppc from the originating ppc transaction.

[quote=“hrobeers, post:34, topic:3896”][member=30983]peerchemist[/member], thehuntergames is not referencing the change address for PeerAssets as that one is not needed.
He references the real P2PKH outputs of the peercoin transaction holding the OP_RETURN, …
The point is that you need to spend the entire output of a ppc transaction and that you need a ppc (not PeerAssets) change address to not spend the total amount of ppc from the originating ppc transaction.[/quote]

You’ve misunderstood my reply. I know there needs to be change address, but that change address should be sending address to keep things simple and easy to track on the blockchain.

To keep things simple I came up with the following:

  • When spawning the change address is always set itself.
  • When issuing cards the new owner is also always itself and get every available ppc. No change address needed here.
  • When transacting the first non self address is to be the new owner of the amount of cards being transferred, the rest of the outputs are non-applicable as the are probably a change address

[quote=“peerchemist, post:35, topic:3896”][quote=“hrobeers, post:34, topic:3896”][member=30983]peerchemist[/member], thehuntergames is not referencing the change address for PeerAssets as that one is not needed.
He references the real P2PKH outputs of the peercoin transaction holding the OP_RETURN, …
The point is that you need to spend the entire output of a ppc transaction and that you need a ppc (not PeerAssets) change address to not spend the total amount of ppc from the originating ppc transaction.[/quote]

You’ve misunderstood my reply. I know there needs to be change address, but that change address should be sending address to keep things simple and easy to track on the blockchain.[/quote]

:slight_smile: my apologies

Nope this is not the case in the current design. The issuing address cannot issue to itself, otherwise it burns the created cards at the same time that it spawns them.

A card issue txn is in form the same as a card transfer txn.

[quote=“thehuntergames, post:36, topic:3896”]To keep things simple I came up with the following:

  • When spawning the change address is always set itself.
  • When issuing cards the new owner is also always itself and get every available ppc. No change address needed here.
  • When transacting the first non self address is to be the new owner of the amount of cards being transferred, the rest of the outputs are non-applicable as the are probably a change address[/quote]

Why not simply every non self and non P2TH address in output is the receiver of the cards? If this rule is followed change is allowed to be sent back to self without disrupting the protocol.

Edit: Rephrased that.

ah now I understand what halving means. But yes that is actually way better approach