Hop Whitepaper Altcoin Solution for Trustless Decentralized BTC USD Exchange

[cunicula]

Hey I made a white paper. I think it is super super exciting stuff.  It is an extremely rough draft in terms of writing, but specific with respect to technical details.

Please ask simple questions so I can make everything more understandable.

And please ask challenging questions too.

Hop aims to allow users to send USD and bitcoin to one another within an altcoin. It is a solution to the trustless decentralized exchange problem, a replacement for paypal,  a solution to the price volatility problem, and well potentially a replacement for bitcoin too, but at this point it remains unproven of course. I would like to see the experiment happen.

The big distinction between hops and bitshares/mastercoin/ripple/etc. is that there is no use of trust relationships in any part of the system.
As with bitcoin, users are asked to trust in a system of economic incentives established by the protocol itself.

Does anyone want to develop this or fund raise to develop this?

https://anonfiles.com/file/14d9ed0ebc60f2fc30bc596c49e7b61f

[1714676128]

1714676128

[1714676128]

1714676128

[1714676128]

1714676128

[greBit]

Just a quick piece of feedback - the pdf is fairly poorly formatted which makes it extremely hard to read. You might want to at least make the page margins smaller.

A brief look through and I see use of a fixed parameter - '7 months' - how did you arrive at this value?

The big distinction between hops and bitshares/mastercoin/ripple/etc. is that there is no use of trust relationships in any part of the system.
As with bitcoin, users are asked to trust in a system of economic incentives established by the protocol itself.

I might have missed something but where is the use of trust relationships in Bitshares?

[cunicula]

Bitshares relies on users to designate mutually agreeable arbitrators (or escrow agents can't remember the name used), who can decide whether to reverse fraudulent transactions.

Mutually agreeing on an oracle = user-designated trust.

Ultimately these arbitrators link bitshares to the real world. Without the arbitrators, bitshares is completely virtual and there is no reason to expect it to have any relationship with real world behavior.

 

Just a quick piece of feedback - the pdf is fairly poorly formatted which makes it extremely hard to read. You might want to at least make the page margins smaller.

A brief look through and I see use of a fixed parameter - '7 months' - how did you arrive at this value?

The big distinction between hops and bitshares/mastercoin/ripple/etc. is that there is no use of trust relationships in any part of the system.
As with bitcoin, users are asked to trust in a system of economic incentives established by the protocol itself.

I might have missed something but where is the use of trust relationships in Bitshares?

Thanks. I am horrible/lazy at formatting. Will retype it in word when I get the chance. Thank you for your patience.

Yes, 7 months is a magic number. There are several magic numbers in the paper. In many cases, the justification is simply that it is easier to impose a number than design a voting or market-based selection mechanism. I opted for simplicity unless I saw something as mission critical. Here is the story behind 7 months (other magic numbers may have similar backstories):

It takes time for the hops backing hopdollars to respond to price changes, so in the short-run the current level of backing provides information about future levels of backing.

To avoid gaming, you need to use a time point far enough in the future that, given future prices, the current level of backing has no additional information about the future backing level.

I simulated adjustments to maintain parity with bitcoin using historical bitcoin price data.

See the graph here:
http://imgur.com/dJ2ekUu

I arbitrarily imposed a starting disparity between the current backing level and the backing necessary to maintain parity with 1 USD. I then let the system run, assuming that users vote so as to target parity in a 30 day time frame (sooner if they are within 20% of parity). Using this algorithm, I find that a 3 month interval is sufficient to decouple the current backing level from the future backing level (i.e. starting state no longer matters for the ending state; only future price movements matter).  This works even for an extremely large mismatch (say a factor of 10^9). I then added 4 extra months as a safety margin just in case real world behavior fails to outperform my algorithm.
 
I omitted this type of discussion from the paper to prevent it from becoming too long to read.

[greBit]

Bitshares relies on users to designate mutually agreeable arbitrators (or escrow agents can't remember the name used), who can decide whether to reverse fraudulent transactions.

I thought the use of escrow was just a 'feature' to facilitate the exchange of Bitshares/BitWhatever with traditional assets such as dollar bills.

[cunicula]

Bitshares relies on users to designate mutually agreeable arbitrators (or escrow agents can't remember the name used), who can decide whether to reverse fraudulent transactions.

I thought the use of escrow was just a 'feature' to facilitate the exchange of Bitshares/BitWhatever with traditional assets such as dollar bills.

Any system like this needs an 'oracle.' End of Story. My 'oracle' is the aggregate voting behavior of PoS miners. The only plausible oracles in bitShares are escrow agents.

If the escrow agents impose a rule that 1 bitUSD must be exchanged for ~1 USD (or a txn is fraudulent), then this links the system to real world prices.
If they do not impose any such rules, then there is no mechanism whatsoever coupling the price of a bitUSD to the price of a real USD.
It is either a trust dependent system where escrow agents regulate exchange, or it is bitUSD in name only and could just as accurately be called bitSEASHELLS.

If you want me to tear apart bitshares (or mastercoin for that matter) using economic theory, please post a request for that in the bitshares thread. I will happily oblige.
  

[markm]

Sounds reasonable. Should hopefully take less than the $300,000+ of venture capital some other propoals raked in to try it out, too.

How many hops are to be pre-mined? Or does that depend on venture capital, like X amount per bitcoin of capital ventured?

-MarkM-

[cunicula]

Sounds reasonable. Should hopefully take less than the $300,000+ of venture capital some other propoals raked in to try it out, too.

How many hops are to be pre-mined? Or does that depend on venture capital, like X amount per bitcoin of capital ventured?

-MarkM-

Thanks.
The number of pre-mined hops is just a scaling factor. Maybe a million. The hops inflates at 5% a year in any case. (i.e. it is just 21 million bitcoins vs. 21 billion milibits)
Pre-mining is just to facilitate funding, by offering some virtual assets the project can sell.

What I would like to see is some kind of open source kickstarter-like project. Some pre-mined hops could be given to developers and others could be sold to people who advance BTC to feed the developers.

I could contribute up to 50 BTC to feed developers, but it isn't enough in and of itself. Moreover, since I am not a developer myself (or even in the tech industry), I feel that I would need someone else to lead or co-lead the project. Realistically, that would have to be based primarily on enthusiasm rather than upfront monetary incentives.

If it turns out that there is no broader interest in this. I will just leave it out there and hope it influences future innovators at some point (I'm certain it will, question is how long I have to wait).

 

[jedunnigan]

If you want me to tear apart bitshares (or mastercoin for that matter) using economic theory, please post a request for that in the bitshares thread. I will happily oblige.

Please do, I'd very much like to read this. Curious how they would respond.

edit:bitshares, not mastercoin.

[charleshoskinson]

Everybody's a critic  . Goodluck and I hope some good ideas come from this proposal.

[qwk]

 

[Luckybit]

Sounds reasonable. Should hopefully take less than the $300,000+ of venture capital some other propoals raked in to try it out, too.

How many hops are to be pre-mined? Or does that depend on venture capital, like X amount per bitcoin of capital ventured?

-MarkM-

Thanks.
The number of pre-mined hops is just a scaling factor. Maybe a million. The hops inflates at 5% a year in any case. (i.e. it is just 21 million bitcoins vs. 21 billion milibits)
Pre-mining is just to facilitate funding, by offering some virtual assets the project can sell.

What I would like to see is some kind of open source kickstarter-like project. Some pre-mined hops could be given to developers and others could be sold to people who advance BTC to feed the developers.

I could contribute up to 50 BTC to feed developers, but it isn't enough in and of itself. Moreover, since I am not a developer myself (or even in the tech industry), I feel that I would need someone else to lead or co-lead the project. Realistically, that would have to be based primarily on enthusiasm rather than upfront monetary incentives.

If it turns out that there is no broader interest in this. I will just leave it out there and hope it influences future innovators at some point (I'm certain it will, question is how long I have to wait).

 

Why don't you crowdfund it?

Have an IPO on BTC.CO or Litecoinglobal? Offer up some sort of value to investors who get in early? If you provide the right incentives they will come.

[cunicula]

Sounds reasonable. Should hopefully take less than the $300,000+ of venture capital some other propoals raked in to try it out, too.

How many hops are to be pre-mined? Or does that depend on venture capital, like X amount per bitcoin of capital ventured?

-MarkM-

Thanks.
The number of pre-mined hops is just a scaling factor. Maybe a million. The hops inflates at 5% a year in any case. (i.e. it is just 21 million bitcoins vs. 21 billion milibits
Pre-mining is just to facilitate funding, by offering some virtual assets the project can sell.

What I would like to see is some kind of open source kickstarter-like project. Some pre-mined hops could be given to developers and others could be sold to people who advance BTC to feed the developers.

I could contribute up to 50 BTC to feed developers, but it isn't enough in and of itself. Moreover, since I am not a developer myself (or even in the tech industry), I feel that I would need someone else to lead or co-lead the project. Realistically, that would have to be based primarily on enthusiasm rather than upfront monetary incentives.

If it turns out that there is no broader interest in this. I will just leave it out there and hope it influences future innovators at some point (I'm certain it will, question is how long I have to wait).

 

Why don't you crowdfund it?

Have an IPO on BTC.CO or Litecoinglobal? Offer up some sort of value to investors who get in early? If you provide the right incentives they will come.

I also don't think funding will help until I have identified developer(s) that would be excited to undertake the project, but need money to do so.

[greBit]

Any chance you could rustle up a quick-and-dirty slideshow presentation that could clearly explain how it works?

I found the paper pretty hard to follow but then my economics is pretty weak

[BombaUcigasa]

I simulated adjustments to maintain parity with bitcoin using historical bitcoin price data.

See the graph here:
http://imgur.com/dJ2ekUu

I arbitrarily imposed a starting disparity between the current backing level and the backing necessary to maintain parity with 1 USD. I then let the system run, assuming that users vote so as to target parity in a 30 day time frame (sooner if they are within 20% of parity). Using this algorithm, I find that a 3 month interval is sufficient to decouple the current backing level from the future backing level (i.e. starting state no longer matters for the ending state; only future price movements matter).  This works even for an extremely large mismatch (say a factor of 10^9). I then added 4 extra months as a safety margin just in case real world behavior fails to outperform my algorithm.
 
I omitted this type of discussion from the paper to prevent it from becoming too long to read.

The simulation looks interesting. Two questions:
- do you have another example for say a one week interval time frame calculation, or maybe a curve showing the relation between the interval and price stability?
- how will the peers decide on the market price of your hopdollars (when some of them are rogue or prefer say 2 USD/hopdollar)?
- where are they taking the hopbits? http://www.youtube.com/watch?v=z9Uz1icjwrM

[dacoinminster]

MasterCoin here.

Disagree that MasterCoin protocol (or bitshares, for that matter) requires any trust relationships.

You seem to be aiming for a similar set of features as bitshares. It would be interesting to see a features matrix (feel free to bias toward your own project) with the features of your coin vs bitshares, ripple, and mastercoin.

Best of luck to you. Stabilized currencies is where it's at!

[Luckybit]

Sounds reasonable. Should hopefully take less than the $300,000+ of venture capital some other propoals raked in to try it out, too.

How many hops are to be pre-mined? Or does that depend on venture capital, like X amount per bitcoin of capital ventured?

-MarkM-

Thanks.
The number of pre-mined hops is just a scaling factor. Maybe a million. The hops inflates at 5% a year in any case. (i.e. it is just 21 million bitcoins vs. 21 billion milibits
Pre-mining is just to facilitate funding, by offering some virtual assets the project can sell.

What I would like to see is some kind of open source kickstarter-like project. Some pre-mined hops could be given to developers and others could be sold to people who advance BTC to feed the developers.

I could contribute up to 50 BTC to feed developers, but it isn't enough in and of itself. Moreover, since I am not a developer myself (or even in the tech industry), I feel that I would need someone else to lead or co-lead the project. Realistically, that would have to be based primarily on enthusiasm rather than upfront monetary incentives.

If it turns out that there is no broader interest in this. I will just leave it out there and hope it influences future innovators at some point (I'm certain it will, question is how long I have to wait).

 

Why don't you crowdfund it?

Have an IPO on BTC.CO or Litecoinglobal? Offer up some sort of value to investors who get in early? If you provide the right incentives they will come.

I also don't think funding will help until I have identified developer(s) that would be excited to undertake the project, but need money to do so.

Set up a system where developers can name their price for services and also design the incentives so people who fund it can make a profit from doing so.

First question, how much would it take in BTC to get someone to code this? Anyone want to name their price?

[charleshoskinson]

It's ok, he's got a lot of pretty math to make everything better . BitShares and Mastercoin do not require trust relationships, but I suppose people can write whatever they like in their whitepapers.

[cunicula]

It's ok, he's got a lot of pretty math to make everything better . BitShares and Mastercoin do not require trust relationships, but I suppose people can write whatever they like in their whitepapers.

Okay, your have made your disagreement known. As I said previously, I will only discuss this issue futher in threads devoted to bitshares and/or mastercoin. If you want to debate this, post in an existing thread or create a new one.  And yes, I will rely on mathematical arguments to do so. If you don't like that, we don't have to go there. Up to you.

[cunicula]

The simulation looks interesting. Two questions:
- do you have another example for say a one week interval time frame calculation, or maybe a curve showing the relation between the interval and price stability?
- how will the peers decide on the market price of your hopdollars (when some of them are rogue or prefer say 2 USD/hopdollar)?
- where are they taking the hopbits? http://www.youtube.com/watch?v=z9Uz1icjwrM

1) The interval is not so important. You could push it out to 5 years and the math behind the system would still hold. I have chosen an interval that allows for fantastically large price changes. This is extremely conservative. I don't see a major user benefit from reducing the interval. Accordingly, I chose to play it extremely safe so I have one less thing to worry about.

Technical discussion:
It is really allowance for black swan outlier events that matters. This is the size of the state space. I cover a set of future backing realizations using a binomial tree issue. Moving from time t to time t+h there are 2^h possible voting patterns, each of which maps to an (approximately) unique change in backing ratio. That is a lot sure, however they have to span the entire state space of future backing realizations. It could be that 99% of the time, the t+h backing ratio is within 10% of the starting backing level at time t. Gamblers only need to worry about outcomes in that narrow interval of the state space. I also allow for exceptionally large outliers, covering changes of +-10^9%. This means that only a tiny fraction of the state space will lie in the interval of probable outcomes.
I guess the relevant question is what is the largest conceivable % change in price over h blocks. If you reduce this % then you can get faster convergence. Another alternative is giving miners more than 2 voting options. I feel that yes or no is the most idiot proof solution.

2) if more than 50% of PoS miners are honest than there is some interval h which is large enough to prevent gaming by the minority.
If you have say 66% honest miners and 33% who always lie, the interval is approx 3 times as large as if you have 100% honesty. Essentially you use up one honest vote to cancel out the dishonest vote. This leaves you with 1 influential honest vote for every 3 votes cast. So it takes 3 times as many voting periods to get things done. (Actually more because you need to cover a larger state space as you move forward in time, but I got that covered by being safe in (1)).

[charleshoskinson]

Okay, your have made your disagreement known. As I said previously, I will only discuss this issue futher in threads devoted to bitshares and/or mastercoin.

This isn't a disagreement it is a factually incorrect statement that you are broadcasting in your whitepaper right in the abstract:

....Unlike other proposed systems for issuance of USD-denominated cryptoassets (e.g. Ripple, Mastercoin, Bitshares, etc.), hop does not rely on trust relationships.

Either you have bastardized the word trust to mean something beyond common notion or you have no understanding how Mastercoin and BitShares work. In any event, you are misrepresenting our brands and I have every right to post a disclaimer in your thread stating such. BitShares does not rely upon trust relationships.

And yes, I will rely on mathematical arguments to do so. If you don't like that, we don't have to go there. Up to you.

When mathematics are used to justify arbitrary design decisions or override the will of the market, then I tend to discount the system. You can use any level of abstraction you desire with any level of complex relationships, but unless the system is actually tested with real users and predictive models are verified, the math is worth less than the ink on the paper. Ask David Li about this Cunicula.

Just as you discounted us for our lack of economists (and we do actually have one), I'll discount you for your lack of developers. They are the lifeblood of these ideas and the drivers of their implementation. I'll leave your thread now.