[Deprecated] Peercoin simple assets (evolved into PeerAssets)

[peerchemist]

Hello,

I am presenting a draft for quite simple protocol which will enable issuing and transacting with assets on top of Peercoin blockchain, however this is not the only possible feature of this protocol as I have explained in the paper.
I am looking forward to hear feedback from community so we can discuss and plan on what comes next.

http://peerbox.me/psa/PSA.pdf
You can download the document via IPFS here: https://ipfs.io/ipfs/QmdVJUeNQWjyHStSTnFWqmRw2ikUXQvpYnHqxEDbTjoKaj
or here: https://mega.nz/#!GIdGwSjC!k9aLkRbXdx8Si0F3skdHy16D2T_GDaO8Evnedo5cYUA

[size=8pt]edit: small updates to document[/size]
[size=8pt]added mega.nz link as some members have experienced troubles getting to that ipfs gateway.[/size]
[size=8pt]turns out IPFS is not so great after all
few more tiny changes to documument[/size]

[thehuntergames]

This is a nice use of peercoins blockchain without any need for soft forks.
The way it stores meta data does remind me of counterparty to color coins on top of the blockchain.

I think many future companies? will prefer this over peershares for the simplicity alone. Not to mention the security over a private blockchain.

I do think that and correct me if am wrong, the size of tx's might exceed 1kb as metadata is sent over the network having a larger fee is needed to move those assets around?

[Sentinelrv]

I won't be able to read this until later (currently at work) but is this like a more in depth and expanded version of Peerassets, which Mably previously introduced?

[Gin]

I think many future companies? will prefer this over peershares for the simplicity alone. Not to mention the security over a private blockchain.

Yay! simplicity is the key. And collaboration as well, instead of further blockchain fragmentation.

[peerchemist]

This is a nice use of peercoins blockchain without any need for soft forks.
The way it stores meta data does remind me of counterparty to color coins on top of the blockchain.

I think many future companies? will prefer this over peershares for the simplicity alone. Not to mention the security over a private blockchain.

I do think that and correct me if am wrong, the size of tx's might exceed 1kb as metadata is sent over the network having a larger fee is needed to move those assets around?

Yes, metadata might exceed 1Kb and then the fee would be larger.

[hrobeers]

Hi Peerchemist,

I read the entire paper now, so here is the remainder of my review:

1. Page 5: "There is no way to stop the deck issuer from just “printing” more money"
   It is theoretically possible to require a multisig sender where 51% of the current asset holders needs to sign the creation of new money. However, it would not be weighted by the holded amount. Alternatively, you might require 5 of the top 10 asset holders. Anyway, this is just food for thought.

2. Page 5: "Deck can be destroyed (burned) by simply assigning all cards in deck to an unusable address."
   Consider reformulating to "provably unspendable address", as there are unusable addresses that can't be proven to be unspendable so there is no way to detect.

3. Page 5: Multisig decks
   See point 1. It is possible to make the card issuing dependent on the top asset holders. Imagine someone leaving the company still holding some private keys.

4. Page 7: Voting
   Consider integrating the voting mechanism into card issuing (see point 1 and 3).

5. Page 8: "spawn another deck with same name “Peerchemist” to try to fool other clients"
   You could require the name registration "Peerchemist" to be a transaction from a private key being a hash for "Peerchemist" as this would make it easier to query for duplicates.
   Or a multisig using that private key and a secure one, so that the name can be re-registered to a different address using the same multisig as the first txn (but you lose the queriability here).
   Again, just food for thought.

Thanks for sharing. I'm very happy that I found this community. Although there is not very much activity on the forum, the signal to noise ratio is very high. I'm learning a lot here.

[peerchemist]

Hi Peerchemist,

I read the entire paper now, so here is the remainder of my review:

1. Page 5: "There is no way to stop the deck issuer from just “printing” more money"
It is theoretically possible to require a multisig sender where 51% of the current asset holders needs to sign the creation of new money. However, it would not be weighted by the holded amount. Alternatively, you might require 5 of the top 10 asset holders. Anyway, this is just food for thought.

3. Page 5: Multisig decks
See point 1. It is possible to make the card issuing dependent on the top asset holders. Imagine someone leaving the company still holding some private keys.

Thanks for sharing. I'm very happy that I found this community. Although there is not very much activity on the forum, the signal to noise ratio is very high. I'm learning a lot here.

I get the other points, but this sound the most interesting to me. Let me focus on this first.

1) I do not see how is that possible. Ok, requiring 51% of shareholders to print more is possible, but if number of shareholders is small and it fits in some multisig combination which is possible to implement. AFAIK, maximum for Bitcoin multisig is 8 of 15.
Due to simplicity of protocol, each deck is permanently tied to originating transaction and it is not possible to modify privkeys involved in original multisig as this is already written on the chain.

3) If someone leaves the company with still holding keys, then the company is left crippled. They can no longer issue new assets nor send from the original stack of cards.
This is why there should always be some room to breathe, ie. using 2/4 multisig or 5/8 or 7/13.

[hrobeers]

I get the other points, but this sound the most interesting to me. Let me focus on this first.

1) I do not see how is that possible. Ok, requiring 51% of shareholders to print more is possible, but if number of shareholders is small and it fits in some multisig combination which is possible to implement. AFAIK, maximum for Bitcoin multisig is 8 of 15.
Due to simplicity of protocol, each deck is permanently tied to originating transaction and it is not possible to modify privkeys involved in original multisig as this is already written on the chain.

3) If someone leaves the company with still holding keys, then the company is left crippled. They can no longer issue new assets nor send from the original stack of cards.
This is why there should always be some room to breathe, ie. using 2/4 multisig or 5/8 or 7/13.

Indeed that's correct, it's not possible on the peercoin/bitcoin chain. That's why I suggested something like the top 10 shareholders. Or let's say 8 of top 15 shareholders.
So if it's possible that the company becomes crippled, people won't trust it as much isn't it?
Or image the company getting sold, where all the assets/shares are transferred to an other party. In this case, the original share holders will still be able to issue more shares.

[peerchemist]

Or let's say 8 of top 15 shareholders.

The list of top shareholders can change several times per day. There is no elegant solution to this.

So if it's possible that the company becomes crippled, people won't trust it as much isn't it?

True, people will steer from such company.
Such complex issues are beyond the scope of this paper and idea behind it, if you check out older solutions that offer issuing a assets you will find out they suffer from this same fundamental problems even that their chains and protocol are modified to support all kind of bells and whistles. Nobody has solved those issues, not even Ethereum.
When someone gets that right, that will be first true DAO/DAC. For now, we will have to live like this.

Or image the company getting sold, where all the assets/shares are transferred to an other party. In this case, the original share holders will still be able to issue more shares.

That is correct. However in this case I would advise that new holders found a new deck which they control and deal with value transfer mechanisms manually (proof of burn for the old assets and sending new ones to registered addresses).

[hrobeers]

Ok, sounds good.
You might include some of these questions in your FAQ, especially the "getting sold" case.

Any thought's on point 5?

[peerchemist]

@hrobeers

At point 5), do you want to say vanity addresses should be used? https://en.bitcoin.it/wiki/Vanitygen

[hrobeers]

Nope, a vanity address could need too much computing power for long names.

A private key is usually a 256-bit number (https://en.bitcoin.it/wiki/Private_key), so you could use the sha256 hash of for example "Peerchemist" which will give you a valid private key that you can generate an (insecure) address on.

This way, you can easily search for all txn on that address to find the first one.

So you could define the protocol that the first transaction (of the specific form) from that address should be sent to the owning (secure) address of that name. So you can easily lookup the real owner (secure address) of for example "Peerchemist", so that address owns the name and can change it's metadata later or send it to a new owner.

The same kind of system could be used to register an asset deck under a specific name. The generated (insecure) address provides a fast way to lookup it's first transaction to see who registered it first.

It's still work in progress in my head, but hopefully you see where I'm going

[hrobeers]

Salting could reduce the chance of addresses being watched by others to steal their funds. But since there is only the txn fee to be stolen and since it's spent immediately for the txn to the secure address, salting with a known salt should be good enough.

If this sounds good to you, but want a more detailed explanation, I can create some kind of sequence diagram.

[peerchemist]

Yes, that sounds interesting. I would like to see something more detail and maybe in some form of document.
However, I guess we first need to implement PSA to utilize that idea?
Maybe aliases with your scheme could become first use for PSA.

[saeveritt]

I'm excited to see PSA being discussed, Peerchemist. Great work! I've been thinking. How should the PSA protocol permantely ignore transactions from individuals sending more asset quantity than they currently have? If I understand correctly the initial spawning of the deck with the earliest date will be considered the genesis dataset for that particular asset and the Quantity as seen by PSA aware nodes and clients will only increase if the same Deck Spawner generates more under the same name. I see that comparing against the cumulative sum of the particular asset provides the first validity check. I'm considering the scenario where let's say Person A has 100 quantity of Bluebunny and attempts to send 120 quantity to Person B. How should PSA protocol reject this quantity transfer from being considered and mark it to ensure that all subsequent nodes and clients do the same in the future when coming across this transaction? Assuming that the metadata passes the initial formatting filter and follows protocol where
meta = { marker:PSA
name:bluebunny
quantity: 120
prev_owner: Person A
new_owner: Person B}.

Could there potentially be an asset that the PSA protocol uses to propagate announcements on the public bulletin board to all listening nodes/clients where a record of marked transactions for the previous block are posted?I understand that this would take 0.01 PPC/kb and perhaps the benefits may not outweigh the cost in the future.
Example:
meta = { marker:PSA
name: Excludes
quantity: 1
id_list: List of excluded transaction id's

Would this reduce the computational requirements for clients and nodes if they can quickly invalidate known transactions posted on PSA Excludes?
Of course this is just a thought. I'm looking forward to continually discussing PSA; thank you for your hard work Peerchemist!

[peerchemist]

How should the PSA protocol permantely ignore transactions from individuals sending more asset quantity than they currently have?

It is not possible to permanently ignore bogus transactions without the help of PSA aware full nodes, and that would require a quite complex patch and it is not really needed for start. This issue is solved by each individual client, on his own and for his own benefit.

I'm considering the scenario where let's say Person A has 100 quantity of Bluebunny and attempts to send 120 quantity to Person B. How should PSA protocol reject this quantity transfer from being considered and mark it to ensure that all subsequent nodes and clients do the same in the future when coming across this transaction? Assuming that the metadata passes the initial formatting filter and follows protocol where
meta = { marker:PSA
name:bluebunny
quantity: 120
prev_owner: Person A
new_owner: Person B}.

So in this scenario Person A has been give 100 "blue bunny" assets by the asset issuer or some other party which was previous owner.
Now, nothing is stopping Person A to send millions (!) of he's blue bunny assets to any Peercoin address listed on the blockexporer for example.
This protocol does not define "sending" asset in any literal way, but sending a message to the blockchain stating that previous holder is giving up control of some quantity and transfers it to next owner, it is up to each individual client to trace back chain of messages to the spawning transaction and decide if it is valid.
In this case where Person A is sending more assets than he owns, PSA aware client of Person B will recognize this a false message and will simply not show it to the user.
There is no mechanism to permanently mark this transaction as bogus, every client will have to deduct this for itself.
However, this kind of transaction can be pruned of the chain later when PSA evolves to have aware full nodes.

[hrobeers]

Ok, I reorganised my idea and it's now greatly simplified and generalized.

It should allow the PSA client to quickly find the asset transactions that are related to a specific deck instead of parsing the entire blockchain to search for these.

I'll write it down in a document and post it later. I'll also search the internet for similar concepts.

[kschneezy]

Always exciting to see work done to make Peercoin a "back-bone currency"

The FAQ section was the most informative portion for me. It helped put PSA in a more macro level context in comparison with the other options out there for issuing shares. A more comprehensive FAQ section will be helpful in the future. Also, the card deck analogy was great for a laymen to follow a more complex topic.

Issuing the asset on the Peercoin blockchain over a private blockchain is great for security purposes and public exposure. If the necessary client add-on can be implemented into Peerbox or Peerunity this becomes a viable option for issuing shares.

Excited to see what comes of this project!

[caribou]

I feel that PSA is similar to ETF (Exchange-Traded Fund). PSA is a blockchain-based ETF. Am I right?

[peerchemist]

I feel that PSA is similar to ETF (Exchange-Traded Fund). PSA is a blockchain-based ETF. Am I right?

PSA is a protocol. It can be used to issue any type of asset, including ETF.