PeerAssets whitepaper is now translated to mandarin Chinese.
Link: https://www.dropbox.com/s/qreborkvrgpf5jr/PeerAssets-CN.pdf?dl=0
Link to post: http://diandianbi.org/thread-806-1-1.html
Thanks to @caribou for translating this!
I have created a peer4commit page for PeerAssets project.
https://peer4commit.com/projects/178
I will post the projected roadmap and timeline of development in couple of hours. I will start working on this in the following 5 days.
So you’re going to code it yourself?
Neat! This is really taking shape ;D
Yes I am going to code the proof-of-concept myself. I guess the other projects like PeerKeeper will implement it with another set of tools. It is important to code the proof-of-concept to set the standard and strictly define the protocol.
I guess the first project to use it will be Peerbox, so users of Peerbox will be able to issue an asset from their Peerboxes.
[ul][list][list]Proposed project roadmap:
please note that this is relative and will greatly depend on my available spare time.
[listl]
[list][li]Implement tools for the job.[/li][/list]
Implement simple python library for interaction with Peercoin blockchain. This will serve as a backend for the application. This code will be left to be used by all the future projects that utilize Peercoin blockchain and need custom transactions or OP_RETURN read/write.
This will be most labor intensive piece of the puzzle.
Estimated time to complete: up to 5 weeks.
[list][li]Implement command line utility to issue and transact with assets.[/li][/list]
This will serve as a platform for first tests and will allow final definition of the standard through testing. It will be deployed on Peerbox as part of peerbox command. Such utility will also be first public release but will be contained to Peercoin testnet for start.
Estimated time to complete: 2 weeks
[list][li]Expand functionality of backend to support multisig assets.[/li][/list]
Estimated time to complete: 2 weeks
[list][li]Coordinate integration into PeerKeeper by hrobeers.[/li][/list]
With protocol strictly defined and tested so far it is time to release it to wider public, and is there better platform than nice and elegant web based wallet? At this point I guess that PeerKeeper will continue with separate but compatible implementation.
Estimated time to complete: 2 weeks
[list][li]Expand functionality to enable dividend payout and shareholder voting.[/li][/list]
Estimated time to complete: 3-4 weeks
[list][li]Final polishing and launch on Peercoin mainnet.[/li][/list]
Estimated time to complete: 2-3 weeks
[list][li]Issue “ħopium” (ħ) currency as a PeerAssets based secondary currency running on Peercoin chain.[/li][/list]
This will be satirical move in essence, commenting on the state of community and Peercoin in general. Also, it will allow community to see what PeerAssets can do beside assets. I imagine this currency to be used as tipping currency on forum, reddit and twitter. I will need help with forum, reddit and twitter tip bots at this point.
Estimated time to complete: up to 4 weeks
[/list]
Future:
-
Port to Bitcoin blockchain, implement tools to move the asset deck from chain to chain.
This might cover some other chains like Litecoin, depending on the interest. -
Figure out how-to and implement blockchain identity based on this technology.
This means that it should be possible to send Peercoins to me by writing @Peerchemist into address bar in PeerKeeper. - Experiment with technology to deliver DNS solution to Peercoin chain (copy what Namecoin does).
*Something even cooler than all the above but I will keep it secret for now.[/list][/ul]
Code will be published and updated each time I pass those milestones. This will consume a lot my time and as this is open-source project and can not be monetized I ask the community to fund my work. You can do that via Peer4commit: https://peer4commit.com/projects/178
The same fund will also be used to fund some external work if required.
“cooler then” -> “cooler than” ?
can’t wait to know what is the secret.
[quote=“caribou, post:59, topic:3896”]“cooler then” -> “cooler than” ?
can’t wait to know what is the secret.[/quote]
Thx for the typo fix. I guess you will wait and see 
I like! 
How come the PPC price is not pumping yet? ;D
Awesome concept & whitepaper. I like the concept for its simplicity. I’ve also read a little bit about OpenAssets and CoinSpark, but they seem way more complicated.
A question: Will it be possible to trade PeerAssets to Peercoins in a trustless manner (without trusting the other party or having to use an escrow)? I may have missed it, but I think I didn’t find that topic in the whitepaper.
No, the paper does not deal with those problems. This paper is just an intro I would guess, I hope it will get some people to think and expand it.
I do have some ideas on trust-less and decentralized trading via data-carrying sidechains, but that will have to wait for now.
Thank you for the clarification, Peerchemist! Nevertheless, a very interesting whitepaper. I’ll try to understand the technology a bit more in detail.
I had just a little idea how a direct trustless PPC-to-PeerAsset-trading mechanism could be implemented without sidechains or another additional mechanism. I don’t know if there is a limitation I didn’t consider, 'cause I’m not really familiar with the Bitcoin/Peercoin transaction mechanism.
All we would need is a slightly modified Card Transfer transaction. I would call it “Conditional Card Transfer transaction”.
The only difference to a regular Card Transfer would be that a Conditional Card Transfer transaction would be only considered valid if there is also a Peercoin transaction with a specific amount in the blockchain. This amount is specified by the issuer of the Card Transfer transaction.
It would work very similar to a regular Card Transfer transaction. In a regular Card Transfer transaction the “PeerAssets reasoning mechanism” does consider “bogus” transactions if the transmitter has not received a similar or higher number of assets before. In a Conditional Card Transfer transaction, additionally, the receiver of the Card Transfer transaction has to prove that he has sent a specified amount of Peercoins to the transmitter.
If two parties have agreed a price for the asset, the sequence would be that way:
- The asset owner issues a Conditional Card Transfer transaction, specifying the amount of assets and the amount of Peercoins the receiver must send for the transaction to be valid.
- Once the asset “receiver” sees this transaction to be confirmed, he/she issues the required Peercoin transaction.
- If the receiver does not send the required Peercoins, the transaction is considered invalid. But he can transform it into a valid transaction sending the Peercoins.
I can think of a number of limitations of this approach. So, the receiver could, in theory, wait for a lower Peercoin price and buy the assets much later, and it would be considered valid again. For this reason I can think of some “additions” to this mechanism like a specified timeframe or the possibility to “undo” a Conditional Card Transfer transaction. That would obviously make things more complicated
But I think for many use cases the described simple mechanism should be enough and it would fit into the KISS approach of PeerAssets. It’s something like a simple ask order.
You can send PPC and do a card transfer transaction using one single peercoin transaction (multiple outputs).
Ah, do you mean a trade could then carried out by a simple multisig/multi-output transaction signed by both parties? That would be even better!
In this case, the trustless-trading problem would be already have been solved. Even direct asset-to-asset trading would be possible then, I guess (that’s not even possible with NXT). Then I see a bright future for PeerAssets 
Afaik this would require an additional transaction type (exchange transaction)
In this case, all involved parties provide their input to the transaction.
The exchange get’s encoded in one of the outputs.
When the transaction is created, all parties sign their inputs and the transaction is broadcast.
[member=30983]peerchemist[/member] Does this corresponds to your ideas?
The thing with Peercoin is that it does not support any special transaction types and stuff like you propose is quite difficult to implement. If someone thinks of a way to expand the concept by implementing something new into Peercoin (a new tx type) I am sure that Sunny will accept it. Maybe something can be done with all those new OP codes Bitcoin has implemented in last year?
I did not mean a new Peercoin txn type.
I meant a new PeerAssets txn type.
In this case, all involved parties provide their input to the transaction. [b](standard ppc txn)[/b] The exchange get's encoded in one of the outputs. [b](e.g. OP_RETURN)[/b] When the transaction is created, all parties sign their inputs and the transaction is broadcast. [b](standard input signing)[/b]
[quote=“hrobeers, post:70, topic:3896”]I did not mean a new Peercoin txn type.
I meant a new PeerAssets txn type.
In this case, all involved parties provide their input to the transaction. [b](standard ppc txn)[/b] The exchange get's encoded in one of the outputs. [b](e.g. OP_RETURN)[/b] When the transaction is created, all parties sign their inputs and the transaction is broadcast. [b](standard input signing)[/b][/quote]
That is interesting idea. Simple and effective. Good, I like it.
This should be integrated into client though, to ease the interaction for the user. Any idea on how to transmit the raw tx data between parties?
For the user is would work as follows.
One party sets up the exchange by filling in the amounts to be exchanged from which addresses.
He signs it.
The other party/parties receive request to sign.
He/they sign it too.
The transaction is broadcast automatically once the last input is signed.