PeerTicker (A Hypothetical PeerAssets Project)

Projects
1

PeerTicker

Summary

A peercoin price tracking operation designed to replicate the open market value of peercoin on the blockchain itself.

A peerassets project

PeerTicker will function as a peerasset, granting shareholder authority to those that donate peercoin to the effort. In this way, it will pseudo-anonymously accept and track donors such that it can fund its operation. As a peerasset, PeerTicker will require a central governing body made up of one or several asset issuers. These issuers will also be known to be responsible for the core function of the PeerTicker project, that of writing the price on the blockchain.

Cost and Operation

As a function of time, the PeerTicker governing body will print the price of peercoin with respect to some well recognized standard directly on the blockchain using OP_RETURN codes. Using the assumption that the minimum fee per block for a transaction is 0.01 PPC, and that the price tracking can occur within the allotted space corresponding to that fee (1 KB), we can now calculate the total fee required per year to write the price into every block (assuming a 10 minute block spacing):

365 days * 24 hours * (60 minutes / 10 minutes per block) * 0.01 PPC per block = 525.6 PPC/year

Donated funds would be sent to the address that is used to publish the price and would be compensated with 1 PeerTicker Asset for each PPC donated, while the address would consume 525.6 PPC/year in normal operation. Funds donated in excess of some threshold may be used to fund peercoin development as designated by the asset holders.

Governing Body

The simplest form of the governing body is the dictator. A single private key controls the organization and the assets, and if compromised, compromises the entire operation. This body would be responsible for publishing the price regularly, overseeing asset creation and distribution, and proposing votes. The only reward would be the power that such responsibilities inherently grant, as well as the continued operation of a PPC consuming organization. The governing body is assumed to hold a stake in peercoin’s success.

The governing body may be generalized to multiple signatures. The delicacies are mostly surrounding the technicalities of price publishing, though the organization would in general be greatly strengthened by such governance.

Asset Holder Voting

Asset-holders may perform a vote using standard peerassets protocol. A vote can only be held at the discretion of the governing body, as they control all keys and therefore must be complicit in the action for asset-holder opinion to hold sway. Calling a vote should not be taken lightly, as voting requires not only direct participation, but also the burning of asset-holder funds to signify compliance directly on the blockchain. Votes will be considered successful using a basic supermajority of 60% of all distributed PeerTicker Assets. Votes will generally have indefinite endings (at the discretion of the governing body) and can be withdrawn.

Price Trackers and Technical Operation

Each member of the governing body (most likely 1-3 entities) will have a mutually agreed upon price tracking software. Each block, one entity will generate a script with the price encoded into an OP_RETURN and sign it, passing it to the next entity. Each entity in turn will check the price and the transaction and sign the script before the final entity publishes. A minimum time frame for this will be chosen such that if multiple peercoin blocks are found in a very short period of time only one will contain the price tracking transaction. A basic PeerTicker transaction will contain one input, one change output, and one null_data output.

Peercoin Development Funding

If the governing body deems a particular peercoin development project worth funding, they will put a vote before the asset-holders. Upon passage, the governing body will add additional inputs and outputs to the next convenient price tracking transaction that sends funds from the donation pool to the appropriate developer addresses. No development project will be funded if doing so would take the funds in the donation pool below what is required for 1 year of price tracking (525.6 PPC). It is worth noting that PeerTicker can easily contract and fund developers in arbitrary units of currency simply by taking into account the very price that is tracked in that transaction. For example, if a development contract is made in USD and lasts 3 months, PeerTicker need just record the PPC/USD price and pay at time of development completion by taking the requested USD, accounting for the recorded PPC/USD price, then sending that number of PPC to the developer.

An Open IPO

The public offering of PeerTicker Assets is always open to new PPC donors. The reward rate for donated PPC will always be the same and no assets will ever be destroyed. While this implies an eternally inflating asset, the worth of PeerTicker is that of its history of price tracking which will only grow with time.

Migration to Another Governing Body or Another Chain

It must be understood that the governing body must consent for any migration to occur. Assuming governing consent, the asset-holders may vote to move PeerTicker to another governance or another chain. Such a move would simply require a 1:1 distribution of assets on the new chain and/or the movement of the donation pool to a new governing address.

Potential Asset-Holder Votes

[ol][li]Reference Asset (default: USD)[/li]
[li]Peercoin Development Projects[/li]
[li]Minimum Publishing Frequency (default: 5 minutes)[/li]
[li]Governance or Chain Migration[/li]
[li]Price Tracking Algorithm (including new exchanges, and many more options)[/li]
[li]Minimum Donation Pool (default: 525.6 PPC)[/li]
[li]This list is not exhaustive[/li][/ol]

2

Very nice writeup. You might be missing some sections:

IMMEDIATE BENEFITS OF THIS TICKER

LONG TERM BENEFITS OF THIS TICKER

WHY WE NEED THIS NOW, AND NOT LATER

HOW WE’RE MANAGING WITHOUT IT NOW. WHY THIS WON’T LAST

HOW THIS SHOULD INCREASE INTEREST IN PPC AND PPC VALUE

Provide some case scenarios why we need this in layman terms. Some times only serious traders would instantly recognize the benefits, but to the layman peercoin holder, it has to be spelled out.

You did a great job on the proposal so far… a part 2 could help for the business use / case scenarios.

My guess, is because you believe centralized exchanges will eventually fold, or get over regulated, and a price ticker will stablize Peercoin’s price, or ?

3

So there are 2 parts to this, and I will most likely write something up responding to all your points later, but I’d like to do a little meta first. The first and foremost thing I want to do here is talk about what a peerassets project would actually really look like. Much of what I’ve talked about here can be applied to almost any project that writes periodically on the blockchain. One thing I wanted to point out is the way that such a project can become a donation pool that can support and direct future peercoin development.

The second part is the actual application, writing the price on the blockchain. The concept here is that of having an agreed upon price of peercoin that is published reliably on a periodic basis. This project is not intended to have a direct impact on the peercoin price other than to grow peercoin use cases. Rather, this is a reflection of market sentiment that is being recorded through time. This allows for a series of other applications, such as USD denominated contracts, that can refer to a central authority for the peercoin price. This project can be used as an official declaration of the price such that when one makes a deal or a contract in the peercoin ecosystem they need not declare a peercoin price at handshake, but can rather deal with more natural units like US dollars.

There is actually a third purpose here. An organizaton that can merely exist and consume a sustained amount of peercoin writing something verifyable on the blockchain on a regular basis donates trust to the asset and the governing body. In this way, PeerTicker, if it is the only continually functioning organization in the network, could act as a surrogate for interested parties. I.e. it could become an oracle or some other abstract voting body other than the original intended purpose. The ticker would then simply be a trst developing operation chosen for its low operational cost.

For example, imagine if PeerTicker only posted once a day. Then the operating cost would only be equal to about a cup of coffee a year. Still, it would be an organization with governance and trust and some aspects of transparency. It could become a crypto authority for the total cost of less than a cent a day.

4

Immediate Benefit
Donation pool able to contract developers in stable currencies.

Long Term Benefit
Any other contract in the peercoin ecosystem can make those contracts in stable currencies.
Proven group of voters with specific interest in peercoin’s future, as well as a governing body that is proven as a consistent leader.

Why now not later
As a cheap and simplistic system, it will be an easily managable and low weight organization in a veritable wild west. By avoiding any vast or overreaching goals, it is very good for these early stages of the peerasset project.

How we manage now
People send ppc to vanity addresses or peer4commit. The participation of such donations is very low as there is no immediate reward for such actions. In addition, community leaders need to essentially pan handle for anything to get done. This would allow formal contractualizaton and the ability to promise pay at a future date in a virtual denomination other than peercoin.

Increasing interest in PPC
First, it provides a use case and a burn mechanism for PPC. It also provides a method by which the layman can avoid getting their hands dirty with exchanges. A business or company that wants to make a ppc contract with an independent party need not come to an agreement on price, they can simply both trust PeerTicker to pick the price at a date specified.

5

Ok I like the idea.
As this will have the price history encoded in our chain forever, I’d also vote for including the history from before this ticker starts (as a first large OP_RETURN).

I believe your governing body should be way larger, let’s say a 3 out of 15 multisig.
This would make sure continued operation when several are down.
Oracles can be used as mutlisig keyholders, non-key holding processes can let the oracles sign the ticker txns and publish them on the chain. The standard double spending protection will avoid double publishes.

So I’d advice on the following steps to set this up:

[ol][li]Develop oracle software[/li]
[li]Develop txn builder software[/li]
[li]Distribute oracle software to 15 governing bodies[/li]
[li]Create a multisig address using the 15 governing bodies’ public keys[/li]
[li]The 15 bodies publicly serve their oracles[/li]
[li]Distribute the txn builder software publicly, for anyone to run it (even non governing bodies)[/li]
[li]The txn builders will now build ticker txns concurrently and let the oracles sign them if correct. Since every tick spends the UTXO of the previous tick, only one txn per tick will end up on the chain.[/li][/ol]

The oracles can ensure the UTXO never runs out of funds by not signing a transaction with an output lower than a threshold (e.g. 0.05 PPC)

6

I’m thinking about 2 things at this point: Separating oracles from signers and the way the donation mechanism will work explicitly with UTXOs and stuff. Donation stuff first:

In each block there may be one or more donation transaction. Such a donation can be limited to a minimum amount (say 1 PPC) such that it can easily pay for its own cost to distribute additional TickerTokens. Then, in the next convenient block the appropriate OP_RETURN gets added. It would be more elegant to make a PeerTicker client with the governing address hardcoded, but that makes for a hard fork of the PeerTicker client to migrate governments.

So if we separate signers, builders, and oracles, we end up with a rather complex explanation. However, as all three can be the same group of people, it can degenerate to a simple thing at first. Oracles run home brew software to determine the price. Signers agree on a function of oracles using asset-holder consensus if possible. So, like median of Oracle A, B and C or something clever. Then, builders make a txn including all peerasset functions required, any prescribed dev funding, and the previous UTXO (as well as any additonal outputs required to pay for the required outputs) and signers sign. Oracles should be pseudo-anonymous, signers should be community leaders, builders should be anonymous.

7

You can’t split signers and oracles.
Oracles are signers by definition as they validate the price info. The only way the can approve is by signing.

I guess what you call oracles are just external data providers.
But oracles are not data providers, oracles are trusted entities that approve transactions by signing them.

I’ll make a drawing of how I think the txn chain can work when I find some time, you’ll see that it’s quite simple.

Good thinking already!
Keep up the good work, the more projects, the better :slight_smile:

8

Yes, so you have the people that collect and interpret data feed info from external sources, such as exchange API. Those people then broadcast a particular price tick. Say there are 15 such price feed providers. The builders would then look at those 15 providers, exclude any with nonsense responses (down servers) and select the median price to place into a txn. Signers approve the choice by looking at the same group of 15 providers and signing the txn. This way, the providers can be essentially independent not only from the signers but also from each other to achieve a more robust price feed.

9

Here’s a basic volume-averaging using all last_price’s. There are a lot more complicated algorithms that can be chosen. I would say this is very nearly the most simplistic.

This python program is a first iteration. It will go onto each of 4 websites (btc-e, btc38, jubi, and poloniex) for peercoin prices and other locations (bitfinex and yahoo mostly) for BTC and CNY prices.

10

The builders have to put 3 things in the txn:

  1. The price average since the last tick (ticks are to be ~10 min averages. Should this be exactly 10 min? Should the tick contain a timestamp just in case it takes half an hour or something to find the next block?)
  2. Any asset creation txns in response to a donation txn. Builder can just scan the chain since the last tick, maybe the last 5 or 10 ticks just for some redundancy.
  3. Any officially passed donations.

The real trick here is that the signers have to choose between valid ticker txns and invalid ones. I can keep crafting the PeerTicker builder software to fulfill 1 and 2, and the signers can probably use the same software. Point 3 is difficult to automate, it may require manual intervention from both the builders and the signers. Maybe we could make some neat UI where you just drop the donation address and amount into an input area somewhere and it gets added to the next ticker txn.

I can’t do a whole lot of progress on 2 until I know more about peerassets. I have to read up some.

11

Point 3 is easy to automate, if you use the same multisig address for donations as is used by the oracles for signing.
This way, every tick, all the unspent outputs on the multisig address are grouped into a new output + OP_RETURN.

Inputs (all current UTXOs on multisig):

[ul][li]previous tick output (multisig UTXO)[/li]
[li]Donation 1 (multisig UTXO)[/li]
[li]Donation 2 (multisig UTXO)[/li]
[li]…[/li][/ul]

Outputs:

[ul][li]tick output, value=sumOfInputs-fee (multisig UTXO)[/li]
[li]OP_RETURN containing price info[/li][/ul]

The oracles can sign all inputs as they are locked by the same multisig address as the previous tick output.

So builders create the transaction mentioned above, Oracles check and sign. If 3 out of 15 oracles signed, it can be pushed to the chain. It can’t be pushed twice as that would result in a double spend of the inputs.

Importand to note is that once the donations run out, the system stops automatically. And will resume automatically once new donations are made.

This will already work without PeerAssets.

BTW you can add an extra fee output that goes to a development fund. so your output can look as follows:
Outputs:

[ul][li]tick output, value=sumOfInputs-txnfee-devfee (multisig UTXO)[/li]
[li]dev fee output (some address you own)[/li]
[li]OP_RETURN containing price info[/li][/ul]

12

Ok, if we drop peerassets then I need a way to keep a list of donors for voting purposes. I agree this can be done without the addition of a token, but the token allows for transfer of ownership over a spot on that donor list. How do the builders know what donations are valid and what aren’t without blockchain voting?

13

I’d advice on implementing all that donor stuff later.
People donating at first, are just donating to keep it running.
This way you can show early that your project works, so you might attract more dev donations and you’ll have the first app on top of the peercoin chain.

Later, you can add all token stuff and people will be incentivized to donate more.

The voting and all is cool, but I’d advice on building an MVP first https://en.wikipedia.org/wiki/Minimum_viable_product

14

Nevermind, I see what you’re saying. So the donation pool pays the multisig to keep crunching out the ticker prices. Donators get nothing but the satisfaction of the ticker wheel turning. I can probably make that.

15

Correct.

I hope you understand that I don’t want to push you in any direction. I just want to help you get something working quickly.
It’s only the first iteration, please keep thinking and discussing the features you want to see implemented later.

But it would be unfortunate that you’d get frustrated by the complexity and don’t finish the project.
I learned that putting you work out there sooner always pays of in the end.

16

UPDATE:

It looks like Peerticker is indeed the canonical implementation I thought it would be. It is growing quickly (despite my having done zero actual coding toward that effect) and I feel I need to document some of it here.

Price Feed
[member=30983]peerchemist[/member] has put together a wonderful library for exchange APIs:


I intend on using this repo to query the price. It currently only runs for btc-e and poloniex, but there is no real reason it can’t be grown to implement more diverse markets. For now, let’s assume we’re just going to use btc-e PPC/USD spot price and tackle the price feed problem a little later.

Ticker Chain and P2TH
It came to my attention (mostly via [member=32827]hrobeers[/member]) that P2TH in one form or another is well suited to tag the tick output so we can chain it back in as an input to the next tick. This would make a single unique “most recent tick” which is easily looked up and verified via the tag. In fact, one need never actually trace all the ticks back to the initial submission to be sure that the tick is valid. All you need is 2 or 3 tagged ticks back because the multisig will not fork for more than 1 tick. Anyway, the resulting inputs and outputs of a tick look like this:

Inputs

  1. Previous tick, tagged by P2TH
  2. Additional input, if necessary, from donation

Outputs

  1. P2TH tag (size: 0.005 PPC)
  2. Tick output (size: <1 year’s worth of PPC) [Contains null_data of price feed]
  3. Extra output (splits up outputs that are >1 year’s worth of PPC)
  4. Burned: 0.01 PPC fee

First of all, it’s arguable whether we need a P2TH tag on each tick or just the first one, and I’m still thinking about and discussing this. Second, I’d like to specify why there is a maximum amount on the tick output. It’s there so that if the multisig wants to use funds that exceed 1 year’s worth of PeerTicker operation, that money will be automatically split off into another output. This is to avoid the multisig ever spending the tagged output. This is vital, if the multisig accidentally spends the tagged output in a non-tick txn then the ticker chain will be broken.

My current concept is that of a tick every 5 minutes with clients taking the “most recent tick” as the current price. This means most blocks will have more than 1 tick txn and some may contain none (if two blocks are found in under 5 minutes). Still, using the P2TH system, looking up the “most recent tick” should be computationally inexpensive.

peercoin-OP_RETURN
The software distributed to builders will need to forge the above inputs and outputs into a txn. It will then be passed around by signers to sign and broadcast. There is a large question of verifying the txn, namely that the signers will need to verify each output and the price feed. As the price feed can vary by small amounts, there must be a tolerance (say 0.5% price deviation to remain valid) and the txn hash cannot be used to validate. This also brings up the question of what happens in the case of signers not being able to come to consensus on a tick. In such a case, the most obvious answer i can find is that they try again 5 minutes later and everyone just continues to use the “most recent tick” and the ticker just skips one 5 minute interval.

Currently, I am hoping to use this software for the builders:
https://github.com/PeerAssets/peercoin-OP_RETURN
However, there are other potential libraries for bitcoin txns that I could use. The advantage to this one is that it is being currently worked on by [member=30983]peerchemist[/member] and [member=31975]saeveritt[/member].

PeerAssets
A lot of discussion is going into additional and non-standard asset distribution modes. Ideally, an asset distribution done based on PPC deposited to the multisig will allow for a straightforward, continuous and fair IPO that does not require any additional complication to the ticker chain.

So that’s where PeerTicker is. I am very open to suggestions or comments, and happy to answer questions.