Hence the negative maker fee encourages users to wait (which is the opposite of liquidity).

There are two factors at work here, liquidity, which is the depth of the orderbook and traded volume, which is makers and takers coming together. Having an orderbook 100M USD deep with no trades would still have huge liquidity.

I fear this is argument is another straw man: If you keep the overall trading fee the same as it is now but divert a fraction of it to the makers, how can you possibly change the taker's behaviour?

How would memo encryption prevent someone with an ability to analyze traffic to see who you're sending messages to? Could your ISP see it? Could anyone see it?

Indeed it does not. I guess my point is that the anonymity features implemented by the blockchain ought to be enough to cover all possibilities. If they're not, then its not true anonymity. You don't need a new protocol for that. Bitshares design needs to be good enough to cover it.

The primary issue I have is that putting in "special cases" for BTS asset that don't apply to all assets makes the code more error prone and the system more complex to explain in general.  Currently most of the code is written in a manner that it doesn't care what the asset types involved are, they are treated equally.

On the flip side, no one wants to see, for example OKCOIN.BTS in order to get around the fee problem...

In your example, OKCoin would get up to 80% of the BTS fees IF they are responsible for registering and referring the account that placed the trade which generated those BTS fees.  In the case of an account that OKCoin did not register or refer, why should they collect fees on both sides of the trade when someone else referred/registered the account that generated the BTS fees?  Am I missing something?

The only thing you are missing is why okcoin has no incentive to join the BTS network. If they join bitshares, they have more costs and less revenue than if they just opened their own BTS/CNY market.

Quote from: hybridd on December 06, 2015, 10:10:47 pm

With other cryptocurrencies, typically I would use a blockchain explorers api to do this. I'm unsure if @roadscape 's service has a way of doing this so this is a question to him as well.

Suppose I only have the tx id (from receiving funds) i.e. 1.11.510752, how can I determine more information about this transaction (i.e. who sent it)?

GetRecentTransaction(string txid)
https://github.com/wildbunny/c-graphene-api/blob/master/GrapheneRpc/GrapheneWallet.cs#L251

This function is for looking up by hash id, rather than object id. For object lookups, I would use get_object instead.

I agree. I'd like to see a design for parity where risk is equal on each side of the trade. This is made difficult because of the need for fungible longs.

To keep this simple, let's start with a design without fungable longs and go from there.

BTS/USD market:

* Longs and shorts trade on margin in a CFD style market
* The only currency in use is BTS (different to the current design where bitUSD is also used)
* Long BTS orders post BTS collateral
* Short BTS orders also post BTS collateral
* A matching long BTS order with a short BTS order begins the contract
* Both sides need to maintain their positions in order to avoid getting margin called
* Both sides start in BTS and end up in BTS
* Either side can close their position at any time, or get margin called in which case that contract is closed
* The other party which didn't initiate the close (directly or indirectly) gets rematched with next eligible order on the market

Thoughts?

I mean over most time periods that you might choose to measure a trend.

https://books.google.co.uk/books?id=NwFw3p0pXtIC&pg=PA104&lpg=PA104&dq=taming+the+lion+the+trend+is+your+friend&source=bl&ots=4sLVQ1sMgx&sig=t3YUBjkZD7GN_nGfLB3kGEExFFQ&hl=en&sa=X&ved=0ahUKEwiUje_pz8LJAhXJnBoKHT31BY8Q6AEIKTAC#v=onepage&q=taming%20the%20lion%20the%20trend%20is%20your%20friend&f=false

It's certainly the case that within one timeframe, markets are mean reverting, not trending... I've never looked at it over multiple time frames simultaneously, though,