Will a video/summary of the panel be released?

Coinjoin is an interesting concept, we are taking a slightly different approach:   Coin-Never-Join.   If 95% of all transfers have a single input and single output and no address is ever reused then you get the same effect.  After many such transactions performing a single join of two of your addresses to combine 'dust' doesn't actually convey much meaning that can be tracked.

Can you explain a bit more? What is different about BitShares X that allows people to use only single inputs/outputs and unique addresses 95% of the time whereas this isn't particularly common in Bitcoin?

Reddit announcement: http://www.reddit.com/r/Bitcoin/comments/1vd2r1/we_want_to_replace_youtube_dropbox_facebook/

Quote from: bytemaster on January 15, 2014, 11:35:14 pm

Other Comments: This paper shamefully ignores Momentum as a memory hard POW.

Maybe he thinks you still work at Let's Talk Bitcoin 

"As Let’s Talk Bitcoin’s Daniel Larmier pointed out in his own exploration on this concept, in a sense Bitcoin itself can be thought of as a very early prototype of exactly such a thing." 
  http://blog.ethereum.org/?p=10/bootstrapping-a-decentralized-autonomous-corporation-part-i

To be fair, that's a repost from September: http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/

Thanks for the comments Dan

Quote from: bytemaster on January 10, 2014, 10:57:45 pm

… With a little careful work I can always round down so that these rounding errors act as a kind of extra 'fee' the network charges users and no new coin ever gets created.

I think rounding down both sides and destroying a few satoshis is the best way.

I agree. Everything about BitShares thus far seems exceedingly elegant, and a rounding solution that might result in supply inflation doesn't fit.

Today I fixed many bugs while cleaning up the console output which now dumps all log messages to a file.  The display of market data is partially implemented, but I do not yet find the CLI interface intuitive so I cannot cross #2 off my list quite yet.   

1) Clean Up CLI interface and remove console SPAM
2) Add display of market data (order book and current prices)
3) Add automatic margin call functionality
4) Implement client/server model for network communications
5) Add calculation of interest due and earned for short/long positions
6) Add calculation of dividends earned on bts positions.
7) Integrate PTS and BTC wallet import tools
Initialize genesis block and validate I can spend AGS and PTS balances.
9) Implement JSON-RPC API to go with CLI interface.

• Where is Consensus + Proof of Stake in this list?
• I understand that we are talking about MVP, but explicitly adding a full security review at the end of the list seems like a good idea considering how ridiculously important this code is.
• With the new branding, is this thread now referring to BitShares BEX?

These updates are great. Please continue keeping your head down and churning out quality code as fast as possible.

Isaaaaah, I like your thinking. Please continue stirring up dust everywhere you can.

From Vitalik Buterin/Ethereum: http://blog.ethereum.org/?p=39/slasher-a-punitive-proof-of-stake-algorithm

Thoughts on how this compares to the PoS+consensus of BitShares X?

Dan, here is what Charles wrote in response: https://bitcointalk.org/index.php?topic=412878.msg4497464#msg4497464

I'm not going to fully address Dan's concerns here. The questions he listed indicate they either didn't read or didn't comprehend the whitepaper. For example, the entire philosophy of Ethereum is to be a base layer for innovation thus the particular economic model of a DAC running on top of Ethereum is beyond the scope of our design. A person could indeed have dividends in a sub-currency, yet this point seems to have been missed or ignored.

As for P2P exchange, we have a close relationship with Open Transactions and combined with a namecoin style contract provided in the whitepaper and bitmessage makes a significantly more efficient distributive exchange than is possible with BitShares. Trust is not required as auditing can be done on Ethereum blockchain and we wouldn't suffer any bloat. 

Things like 7 again demonstrate either a lack of comprehension or ignorance of our design, contracts are more than robust enough to launch a proof of stake subcurrency. 6 seems to ignore ethereum script is turing complete and thus you can compile a language like c++ into it (anyone ever used coffeescript to write js)?

On a side note, I am honestly curious how Invictus intends on building DACs without a turing complete language? It seems like you would end in an infinite inductive process of having to build a bigger feature set for the next set of DACs. I guess they have a different philosophy and this is fine. I wish them well and hope they find success for the market's benefit.