Would I be able to control what private key is used to generate that wallet? If I create an account offline, isn't it still generated by your software?

Yes, I've had hardware failures in the past where I lost 300 PTS. I want to have all the private keys and ability to recover from just those.

So how does one backup their accounts is really the question - and we should put good instructions on that.

I imported a private key and I want to send all my funds there, just in case. I can't seem to be able to locate the list of my BTS public addresses.

How is it different from Open Transactions with Smart Contracts?

Not familiar with OT and their Smart Contracts. However, Ripple's proposal is using a secure sandbox that allows you to write in any programming language you please, is a very good move from practical stand point.

Also, not sure if OT allows Smart Contracts to run offline by Smart Oracles. There are some really good pieces in this whitepaper and I would love to see what Bitshares is planning for Smart Contracts.

I'm not a huge fan of the Bitcoin scripting and escrow as it currently stands. We need something more innovative and easier for developers to get involved. What Ripple's whitepaper proposes I think is a step in the right direction.

This is where I think something like Ethereum's Turing complete scripting might be useful. But as much as I like the idea, I think forcing everyone to execute code is an overkill. If you make groups of delegates promise to run a certain script however this becomes very interesting.

UPDATE: Holy Shit, Ripple just released a paper that proposes exactly that. Bravo! Love the secure code integration with NaCl as well.

https://ripple.com/blog/smart-oracles-building-business-logic-with-smart-contracts/

I think this kicks Ethereum's butt 1000x times over!!!

Yes, because we may need to be able to quickly change the criteria, we may find that sometimes feeds contain bad data that needs to be filtered, exchanges go down, etc. etc.
For that I prefer to have multiple feeds and be able to say with confidence - this a very good price approximation.

But I see what you are saying - this is brainstorming, and if you decide to go that route, it will be in the RPC, since it is how everything else works.

So then a hybrid model as BM proposed would work:

1) Limit fluctuations to 50% range in 24 hour period (or less decided by the delegate)
2) Additionally allow delegates to exclude transactions based on their own criteria via RPC - I see BM's point that all it takes is 1 delegate to still be able to get their transactions in. But I think that should make it a bit harder to manipulate the market.

I think 2) is still good to have even if you don't see value in it initially. Imagine we experience some abuse, we might be able to very quickly deploy a patch and recommend community only vote for delegates having such and such filter in their system, until this is resolved. The most responsive and flexible delegates will win the community's hearts.

Good point about needing just one delegate to secure a bogus transaction.

I'm not disagreeing with your approach, However this is still more of an ad-hoc solution. My point is that it is hard to update people's clients, so try not to embed that functionality in the main client itself. Instead - open up the RPC, so that a delegate can choose a plugin, and switch between them if needed.

That way you can launch, but delegates can pick a strategy after BTSX has launched. And best of all you would be very flexible. I wouldn't mind developing plugins delegates can use. I already have code that continuously scrapes and saves feeds.

I was proposing a python script as a solution, as it requires a minimal installation and is mostly platform independent. Writing/editing/updating plugins would then be very easy.
The other nice thing about a python plug in (or any script you like) is that it is mostly readable, so it's going to be hard to sneak in malicious code.