Topic: Hop Whitepaper Altcoin Solution for Trustless Decentralized BTC USD Exchange (Read 6127 times)

If he PMs you remind him his obligation for the NXT whitepaper - he took 250K NXT for this from me, Pouncer & CfB...

Guarenteed of Gold isn't true

Have to admit that I skipped through the script doc realatively quickly. I could not find the part that desribed how hobUSD are pegged to USD? What is the mechanism?

I am a bit late to discover this, hopefully cunicula is still monitoring it.
Anyway I am a C programmer and I would love to implement this, my total cash requirements for this project would be 0.00000000 BTC

Plz PM me

James

Futures contracts exist under the same structure and can be purchased years out. Imagine buying oil futures for 2017.

When someone makes a "commitment" to convert 6 months into the future, is that an "option" to convert (that can be canceled), or strong commitment? If they can't be canceled, 6 months seems like a very long time to have your money tied up in a cryptocurrency system. Though, I guess that could be somewhat alleviated by trading the "commitment?"

http://www.scribd.com/doc/186071279/Hop-System-for-Store-of-USD-Value

These are slides offering more of a big picture explanation. Comments please.

Yes, you understand my claims correctly.

Yes, I'm still advocating this.

Yes, many of the parameters are arbitrary. Some of these parameters serve a regulatory function and are intended to enhance financial stability. Other parameters are chosen to prevent gaming of the system. Arbitrary parameters != broken system

Other aspects of the system are absolutely necessary (e.g flexible interest rates for each asset, the ability to immediately arbitrage away interest rate fluctuations following price changes.)

I'm working on a higher level explanation which is more focused on the questions of why and how, rather than a providing a blueprint. When discussing why and how it is not necessary to get specific on parameters, but is essential to outline the necessary features. In a blueprint, parameters are a must.

If I understand it correctly this is what he's claiming:
The value of Hopbits and Hopdollars should theoretically be very close to the value of Bitcoins and USD. Hopbits and Hopdollars actual values would be determined by external exchanges. The system attempts to alter the value of Hopbits and Hopdollars by increasing or decreasing the amount of "Hops" backing Hopbits and Hopdollars. These increases and decreases in backing are driven by PoS miners who vote up/down depending on the market price of Hopdollars and Hopbits on external exchanges. I.e. PoS miners would scrape exchange sites or use exchange APIs to determine their votes, and it's in the best interest of PoS miners to vote in a way that would make the prices on the exchanges to tend toward the value of Bitcoins and USD.

Is the author still advocating this idea? There's not much rationale for the design decision presented in the document. Without rationale and analysis, the equations defining the dynamics of the system look arbitrary to me.

I find this whitepaper to be far too abstract. Can you describe some real-world examples (or even imaginary-world examples) of how this would work?


This only links "hop" to real-world data. Fine, prices on "hop" are reflective of real-world prices. But...


Hopdollars and Hopbits sound more like units which have the price of USD and price of bitcoin written on them. Having the price written on it is not what gives it value. What will give them value is the ability to exchange these units for "real" USD, or actual BTC. How will someone exchange hopbits for bitcoins and hopdollars for dollars? Otherwise you would just have a decentralized ledger where people are trading hopbits for hopdollars (but never actual BTC or redeemable USD).

You cannot add this directly into bitcoin. You might be able to do it as an overlay protocol like mastercoin.
That would require a redsign of the voting scheme.

The development and technical discussion forum is not friendly to innovation unless it can happen within the (restrictive) confines of the bitcoin protocol.

Why an altcoin and not a pitch to add a layer onto bitcoin itself? Seems like someone like Gavin would find something like this important enough to implement into bitcoin... but of course I don't speak for him. Have you approached anyone or made a thread in the Development/technical discussion forum?

Why is a decentralized exchange better seperated from the protocol?

Well, obviously we plan to include this in MC2. I'm still looking for an exchange to do the funding for development.

Now the actual idiot comes in to defend the scammers who are masquerading as idiots.

It is sad, really.

Listen. Let's just listen to your employee sell the system in the press:
You are offering supposedly extremely low risk returns in BTC and USD to naive investors.

You are using a magical system which you cannot possibly believe will work.
(i.e. I used to think you were just an idiot. But looking at how this is marketed in the press, it seems highly improbable.)

You are not going to be protected from the SEC just because of a cloak and dagger white paper.

Telling naive investors you can hold btc with us and earn risk free interest and sell them for 1 BTC later is fraud.

If you go forward with this project, expect to do hard time.

Yes, just offering interest (or dividends) does not make a Ponzi scheme. For instance, if Ponzi really was investing 100% of the money he collected in arbitraging postage stamps, it wouldn't have been a Ponzi scheme, and we would be calling his scheme something else today. Calling bitshares a Ponzi scheme doesn't do much for your credibility.

A sum zero system with no premine and fully collateralized positions to serve as a prediction market is in no way a ponzi scheme. I'm not going to argue with an idiot. We addressed your concerns in our thread. This is a thread about your product. Please do not slander ours in it. 

Well I decided to go for the jugular.

https://bitcointalksearch.org/topic/m.3199026

Let's see them try to refute the claim that bitshares is a ponzi.

Anybody who wants to read cunicula's detailed economic critique of MasterCoin can find his thread about it here: https://bitcointalksearch.org/topic/usd-derivative-implementations-technical-posts-only-283666

He did a pretty good job of collecting all the economic criticisms in one place, although note that the thread is self-moderated, and he has a pretty high threshold for what he considers off-topic. For instance, he deleted my reply as not technical enough:


Interested parties wanting to discuss his criticisms can try posting there, or in one of several MasterCoin threads.

I don't use any predictive models. Anyway predictive models are not verifiable. Ask David Li about that yourself.
He's an actuary by the way. Not an economist.

But thanks for volunteering to make yourself scarce. I hope you'll stick to that.

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


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.


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.

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)).

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.

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.

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?

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!

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

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

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.

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.

 

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

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

edit:bitshares, not mastercoin.

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).

 

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-

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.
  

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

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.

 
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.

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?


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

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