[Announce] Project Quixote - BitShares, BitNames and 'BitMessage'

[favdesu]

P.S. There is very high quality of discussion in this thread. Participants are very astute thus far.

true, but to be honest, I'm lost since page 6. this is too deep for the average person to follow, if you just want information/status on the project.

How about you open a bitmessage channel for this conversation?

[1714842704]

1714842704

[AnonyMint]

P.S. There is very high quality of discussion in this thread. Participants are very astute thus far.

true, but to be honest, I'm lost since page 6. this is too deep for the average person to follow, if you just want information/status on the project.

How about you open a bitmessage channel for this conversation?

This is a Bitcoin Forum > Bitcoin > Project Development thread. Thus, I assume it is for developers to discuss how to get the design correct.

I suggest bytemaster can start a thread in Bitcoin Forum > Bitcoin > Alternate Cryptocurrencies, if he wants to present a less technical thread.

There needs to be some place for us to discuss the deep issues on this proposal.

For example, what is the point of bytemaster telling you BitAssets are wonderful (putting the cart before the horse so to speak), when I have very simply proven upthread they will go to 0 value.

[bytemaster]

cunicula is correct, BitAssets will go to 0.

It is very easy to explain. Both the short and the long have an incentive to ask and bid (respectively) a lower price. Both seller and buyer want a lower price (at the moment they transact). Period.

Short wants to sell for a lower price, so he is protected on the downside. Long wants to buy for a lower price, so he can gain more on the upside.

If I am going to go short, I want to sell for as high a price as possible because I have borrowed the asset and will have to buy back at a lower price in the future.     Thus the foundation of the rest of your conjecture that BitAssets will go to 0 is gone.

[AnonyMint]

cunicula is correct, BitAssets will go to 0.

It is very easy to explain. Both the short and the long have an incentive to ask and bid (respectively) a lower price. Both seller and buyer want a lower price (at the moment they transact). Period.

Short wants to sell for a lower price, so he is protected on the downside. Long wants to buy for a lower price, so he can gain more on the upside.

If I am going to go short, I want to sell for as high a price as possible because I have borrowed the asset and will have to buy back at a lower price in the future.     Thus the foundation of the rest of your conjecture that BitAssets will go to 0 is gone.

Damn, I brain farted (in bed), inverted my logic on long needs higher price, short needs lower price (trying to do too many things at same time).

Okay excellent. Now I can excited about BitAssets again.

So then I continue with the thought process I was doing to redesign BitAssets to make symmetric the stochastic range of preferences on both sides, long and short.

If instead of borrowing to go short, both short and long put their collateral as backing for the BitAsset, and they agree to subtract the (L x) movement in price (higher from short, lower from long) from their half of the collateral and give it to the other party. Then they can agree to any term of contract expiration. We can even support leverage, by making L > 1.

Example, if short ask and long bid meet at 1 BitUSD for 10 BitShares. They both put up 10 BitShares of collateral. If L = 1, and at the end of the agreed expiration, the market price for 1 BitUSD is 6 BitShares, then the long gives 4 of his collateral to the short, and the BitUSD (BitAsset) is retired. (Problem: how do we determine market price?)

My expectation is that by balancing it this way, instead of your current asymmetric design (your design short gets margin, but long never does and no expiration date), then the shorter-term expirations will much more closely track the value of the designated BitAsset.

Why?

1. Both long and short have a balanced set time preference.

2. Shorter-term positions remove the secular trend of the designated asset from the equation.

3. The short and long are more frequently renewing their positions in the market place of bid / ask, thus resetting their target price to the current real-time price of the designated asset.

The problem with my design above as compared to bytemaster's design is that there is no buying of a BitUSD to cover, thus there isn't a 1-to-1 trade for each covering. Rather my design expects a "market price", but such doesn't really exist.

So let's fix my design.

My solution is in the above example, the long must buy a BitUSD and give it to the short. The long keeps the remainder of his collateral, plus takes 2 BitShares from the short's collateral. This is done automatically by the miner of the block. Note this is what I originally thought BitAssets were designed to do. I later learned from bytemaster's example upthread, that his design is asymmetric. In this case, leverage can still be paid out, by giving the appropriate calculation of collateral to the short, along with the BitUSD.

But my design still has a problem. The BitUSD the long buys can't be one that expires. So this creates N classes of each BitAsset, one for non-expiration, and N-1 others for different expiration terms. But how does the BitUSD with no expiration get created? We are back to bytemaster's design in order to create the BitUSD with unlimited expiration time. So what have I just described? Options on the BitAsset?

The asymmetric design has the advantage that the long can hold his/her position indefinitely. Both designs could be offered in the system.

Can anyone make any other observations of ramifications between my design and bytemaster's design for BitAssets?

[bytemaster]

One of the design goals was having something people could 'hold' long term and would be suitable for non-speculators to transact in. 
Fungibility of positions was also important.
Having the ability to derive meaningful price information for automatic margin calls / settlement.

All of that said, your approach would work to some extent assuming you had a settlement method.

[blackswan]

Interesting project.  I'm very excited to watch it develop.

If you guys are looking for a user interface designer, I might consider it.
My latest in-development project: http://kryptotrader.com

[bytemaster]

Latest Article: http://letstalkbitcoin.com/own-your-identity-with-bitshares/

[AnonyMint]

One of the design goals was having something people could 'hold' long term and would be suitable for non-speculators to transact in. 
Fungibility of positions was also important.
Having the ability to derive meaningful price information for automatic margin calls / settlement.

Re-read mine. I think I just described options on your BitAsset?

All of that said, your approach would work to some extent assuming you had a settlement method.

I was editing my post while you were reading it. Re-read the last part about settlement. It is same as for your design.

Seems these options will add symmetric supply and demand for your design, thus helping to track the price of the designated asset?

[AnonyMint]

I would probably come on board as a coder, if you let me contribute Scala code (I would try to code faster than you, hehe so more code would be Scala than C++). Then I would be responsible for integrating with the C++ code and teaching you Scala. Doesn't sound realistic, so perhaps I have to be a bystander. I don't think you want to ship and require the Java Virtual Machine to be installed. Can't force my will on the majority here.

Maybe I can write a Scala version of your code in parallel, e.g. Bitcoin has a bitcoinj version of the client. I am contemplating my options now.

[bytemaster]

Not mentioned in detail in the white paper, BitShares also enable options trading.

Options work like this:
Suppose I have $100 BitUSD
I will give you the option to Buy them for 1 BTS any time in the next 1 month (a specific block number).
In exchange for that option, you would give me .01 BTS today.
You of course would not exercise that option until the price was above 1 BTS.
In order to exercise the option, you must send me 1 BTS to claim the 100 BitUSD.

The 100 BitUSD are 'locked' in the blockchain for the duration of the option.  After the deadline, if they have not been claimed then I can spend them normally.

So in addition to shorts/longs, options provide another way to speculate.

As for your claim of asymmetric motivations between short/long positions this is not a problem because it would be accounted for in the price which would be slightly biased.

Note:  the goal isn't price parity, it is exchange rate hedging.   So 1 BitUSD will be worth more than 1 USD almost all of the time.  How much more depends upon relative expectations of future dividend rates.

[bytemaster]

I would probably come on board as a coder, if you let me contribute Scala code (I would try to code faster than you, hehe so more code would be Scala than C++). Then I would be responsible for integrating with the C++ code and teaching you Scala. Doesn't sound realistic, so perhaps I have to be a bystander. I don't think you want to ship and require the Java Virtual Machine to be installed. Can't force my will on the majority here.

Maybe I can write a Scala version of your code in parallel, e.g. Bitcoin has a bitcoinj version of the client. I am contemplating my options now.

I have a strong desire for the 'protocol' to be open and not defined by an 'implementation' like bitcoin.   Having a parallel code-base would force us to produce a detailed spec independent of any implementation and resolve many problems faced by using Bitcoin Qt as the 'defacto standard definition'. 

It is encouraging to me to see that you have evaluated the idea and found it worth investing your time in creating an implementation.

[AnonyMint]

Not mentioned in detail in the white paper, BitShares also enable options trading.

Options work like this:
Suppose I have $100 BitUSD
I will give you the option to Buy them for 1 BTS any time in the next 1 month (a specific block number).
In exchange for that option, you would give me .01 BTS today.
You of course would not exercise that option until the price was above 1 BTS.
In order to exercise the option, you must send me 1 BTS to claim the 100 BitUSD.

The 100 BitUSD are 'locked' in the blockchain for the duration of the option.  After the deadline, if they have not been claimed then I can spend them normally.

So in addition to shorts/longs, options provide another way to speculate.

Those are asymmetric again.

Your options don't appear to create symmetric demand for the BitAsset in the same way as my proposal does, because one side has to put up much more capital than the other?

As for your claim of asymmetric motivations between short/long positions this is not a problem because it would be accounted for in the price which would be slightly biased.

Note:  the goal isn't price parity, it is exchange rate hedging.   So 1 BitUSD will be worth more than 1 USD almost all of the time.  How much more depends upon relative expectations of future dividend rates.

I understood that already from the white paper.

Why do you think they will only be slightly biased? I am concerned that asymmetry is pernicious, meaning I expect there is no equilibrium.

Why do you think otherwise?

Having symmetric options on your asymmetric asset, might stabilize it.

[AnonyMint]

I would probably come on board as a coder, if you let me contribute Scala code (I would try to code faster than you, hehe so more code would be Scala than C++). Then I would be responsible for integrating with the C++ code and teaching you Scala. Doesn't sound realistic, so perhaps I have to be a bystander. I don't think you want to ship and require the Java Virtual Machine to be installed. Can't force my will on the majority here.

Maybe I can write a Scala version of your code in parallel, e.g. Bitcoin has a bitcoinj version of the client. I am contemplating my options now.

I have a strong desire for the 'protocol' to be open and not defined by an 'implementation' like bitcoin.   Having a parallel code-base would force us to produce a detailed spec independent of any implementation and resolve many problems faced by using Bitcoin Qt as the 'defacto standard definition'.  

It is encouraging to me to see that you have evaluated the idea and found it worth investing your time in creating an implementation.

As I said from the start, there is a lot innovation here that I am interested in.

But I don't agree with every design decision you are making.

So I am trying to think of how we can help each other reach our respective goals, with the least disruption of our respective scarce time.

Modularity comes to my mind. There may be modules of functionality we agree on.

Also HIGH-LATENCY mix-net is crucial. You haven't mentioned it at all.

[AnonyMint]

Can we design it such that the cross-chain transactions will interface blockchains using competing protocols (e.g. no dividends)?

I think yes?

So then I can launch a slightly different protocol, but we can share much code?

[td services]

Just to be clear:  Only the BitShares ID and BitShares Mail system will be released in beta at C3.   Rushing a crypto-currency to market without ample testing and review is something we want to avoid.   That said, a large part of the BitShares blockchain has already been defined including the transaction types.   I have even generated and validated 5 blocks to prove the basic behavior as a crypto-currency with dividends.  You can view my debug block-explorer output: http://the-iland.net/static/chain.html for an example of how the numbers work.    Anyway, just showing you that we have a plan and will be systematically rolling it out as time permits.

Do you have a planned date when mining will start? I thought it also was this fall, maybe I misread something.

Also, will the mining code be available to test mining prior to the actual start?

Finally, how do the current investors plan on earning a return on their investment in Bitshares?

Thought I'd ask again since I think the questions got lost in all the economics discussion. This has a large impact on my mining approach and timing.

[bytemaster]

Can we design it such that the cross-chain transactions will interface blockchains using competing protocols (e.g. no dividends)?

I think yes?

So then I can launch a slightly different protocol, but we can share much code?

Cross-chain transactions are compatible with Bitcoin.    After much work I was unable to create an efficient, secure, means of having 'one currency' with a 'fixed supply' split among multiple chains without allowing a 51% attack on one chain to steal 100% of the value stored on that chain.   So all cross-chain transactions work like https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

[bytemaster]

Just to be clear:  Only the BitShares ID and BitShares Mail system will be released in beta at C3.   Rushing a crypto-currency to market without ample testing and review is something we want to avoid.   That said, a large part of the BitShares blockchain has already been defined including the transaction types.   I have even generated and validated 5 blocks to prove the basic behavior as a crypto-currency with dividends.  You can view my debug block-explorer output: http://the-iland.net/static/chain.html for an example of how the numbers work.    Anyway, just showing you that we have a plan and will be systematically rolling it out as time permits.

Do you have a planned date when mining will start? I thought it also was this fall, maybe I misread something.

Also, will the mining code be available to test mining prior to the actual start?

Finally, how do the current investors plan on earning a return on their investment in Bitshares?

Thought I'd ask again since I think the questions got lost in all the economics discussion. This has a large impact on my mining approach and timing.

We have a method to our madness, but that is our trade secret.   As for timing code availability, we are considering a competition on the algorithm so the final candidate is not known at this time.

[AnonyMint]

we are considering a competition on the algorithm

I assume you mean the GPU/ASIC-resistant PoW. I purposely haven't responded to your request for my algorithm, but I will share at the right time, when I get closer to releasing something.

[AnonyMint]

Can we design it such that the cross-chain transactions will interface blockchains using competing protocols (e.g. no dividends)?

I think yes?

So then I can launch a slightly different protocol, but we can share much code?

Cross-chain transactions are compatible with Bitcoin.    After much work I was unable to create an efficient, secure, means of having 'one currency' with a 'fixed supply' split among multiple chains without allowing a 51% attack on one chain to steal 100% of the value stored on that chain.   So all cross-chain transactions work like https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

I don't want you to control the money supply of my coin. I want mine to debase at 5% per annum, all going to miners, no dividends. I just want to make sure that if my blockchain accepts transactions from your blockchain, that you reciprocate. Can we design a general interface for this so any altcoin can participate reciprocally?

I would probably try to support your other features, but I have to study them in detail before I can say for sure.

Isn't the entire point to get more options out there for the market to choose? If it is all opensource, why do you care which protocol wins? Surely you can continue to innovate on what ever takes the lead in the market. I want your Asset, ID and messaging features. It is just the details that I have to review first.

I don't know your business model, perhaps it is making clients for the communication, etc.. I am thinking it would be best for you to not tie your clients too tightly to one variant of your protocol and design as much modularity as you can, so your efforts aren't lost if you need to change things or some other altcoin protocol is winning more marketshare.

As for atomic operation, Sergio described a very simple algorithm. For example, Bob has BTC and Alice has BTS, so put a TX in BTS blockchain saying that Alice is waiting for TX from Bob in BTC on the BTC blockchain. Put a timeout, but it is non-repudiable during that timeout period. Bob then can safely send the BTC TX. The BTS blockchain automatically sees the BTC TX and finalizes the TX to send Bob BTS.

What do you think?

[bytemaster]

Can we design it such that the cross-chain transactions will interface blockchains using competing protocols (e.g. no dividends)?

I think yes?

So then I can launch a slightly different protocol, but we can share much code?

Cross-chain transactions are compatible with Bitcoin.    After much work I was unable to create an efficient, secure, means of having 'one currency' with a 'fixed supply' split among multiple chains without allowing a 51% attack on one chain to steal 100% of the value stored on that chain.   So all cross-chain transactions work like https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

I don't want you to control the money supply of my coin. I want mine to debase at 5% per annum, all going to miners, no dividends. I just want to make sure that if my blockchain accepts transactions from your blockchain, that you reciprocate. Can we design a general interface for this so any altcoin can participate reciprocally?

I would probably try to support your other features, but I have to study them in detail before I can say for sure.

Isn't the entire point to get more options out there for the market to choose? If it is all opensource, why do you care which protocol wins? Surely you can continue to innovate on what ever takes the lead in the market. I want your Asset, ID and messaging features. It is just the details that I have to review first.

As for atomic operation, Sergio described a very simple algorithm. For example, Bob has BTC and Alice has BTS, so put a TX in BTS blockchain saying that Alice is waiting for TX from Bob in BTC on the BTC blockchain. Put a timeout, but it is non-repudiable during that timeout period. Bob then can safely send the BTC TX. The BTS blockchain automatically sees the BTC TX and finalizes the TX to send Bob BTS.

What do you think?

Any trading system that requires one chain to 'monitor' another chain is not scalable.   The chains must function with 0 knowledge of the other chain.  Clients may support both chains, but only those clients care about both chains.    I don't want to inherit BTC's scalability issues by requiring 'miners' to see the BTC TRX.