What exactly is BitShares TV?

Not going back to the old system.

Making shorts pay the fee up front disincentives covering early and market making.

I wasn't seriously advocating going back to the old system.  Rather, comparing and contrasting the two systems led me to realize that there is a crucial difference between them with potential economic implications:

Under the old system, the discount (premium) is captured (paid) by the buyer, whereas the new system spreads it around to all BitUSD holders.

The ultimate effect of this is that the price signal of interest rates doesn't actually stimulate demand.  I.e. if the average yield for BitUSD is APY but the top of the book is a short offering to pay 100% APR, nobody has an incentive to buy the order because their BitUSD will only get 5% (plus a tiny amount).

Let's say the 100% APR short pays K BitUSD over its term.  The BitUSD holders and the bidder buying the short would "want" to get together to make a mutually beneficial deal where the bidder buys the short, generating 0.95*K [1] in extra profits which the BitUSD holders and bidder split among themselves (the bidder wants some reward for tying up his capital for however long the short was alive).  There are a variety of ways you could potentially implement this.

This is closely related to the idea of a BitBond market.

[1] It's only 0.95*K because shorting new BitUSD into existence at 0% APR would lower the yield for a little bit, the APR offered by the new short must be greater than or equal to the average APR offered by all existing shorts in order to break even.

If they sharedrop on reddit karma the internet will transform instantly overnight

There's a brilliant idea for a new BitAsset

Will the current wallet build and run on ARM based hardware?

ARM is not a supported configuration.  It might work, it might not.  As far as I know, none of us and no community member has attempted an ARM build; you'd be the first person to try.

And if so can I run it on the new Pi Model A+:

There is far too little RAM for the current client.  As bytemaster said, we're planning some lighter tools but they aren't ready to go right now.  When the tooling is in place, I plan on testing Raspberry Pi based cold storage.

If the Pi A+ is not up to the job (256MB of RAM) then what spec do I need to be looking for?

I'm not sure if we have an official recommendation for amount of RAM, but we know that 2 GB seems to be too low.  You might be able to run the CLI wallet only with 4 GB, but 8 GB or more would be better.

I'm really keen to run my wallet on ARM based hardware.

Before buying hardware, you might want to look into qemu-arm-static which will allow you to chroot into an ARM-based Linux environment on x86.  If you can get the client to compile and run on an emulated ARM machine, odds are good it will work on real hardware.

The reason I want two machines is that I'd like to have one that I carry with me when traveling etc and one that I have permanently at home for easy access if the other one is lost.

What you really want is to back up your wallet onto a flash drive.

Obviously I password protect my wallet at the moment (in fact I think it's required with the new BitShares client). I'd like to password protect my two new wallets with exactly the same password. But I'm unsure for certain how the passwords work - I'm guessing the password does not live on the blockchain. Can anyone confirm? So if I lost one of my new A+ Pi wallets (assuming they can be used) am I right in thinking that if I changed the password on the one I didn't loose then the lost wallet would still retain the old password? I guess what I'm getting at is that a lost wallet cannot have it's password remotely changed via the blockchain. The password is local and stored with the instance of the wallet correct?

Any clarity someone can shine on my lack of understanding here would be most helpful.

The password is not stored anywhere, rather it is used to encrypt the wallet on the local hard drive.  There is no way to change the password remotely; the only way to change it is to use the client to decrypt your wallet with the old password and re-encrypt it with a new password.

On the bright side, if someone steals your traveling computer with your wallet file, it is useless unless they also know or can guess your password.  If this happens, I'd recommend creating a new TITAN account with a new client data directory, then transferring all your funds from the old account to the new account.  That way, if the thief eventually guesses your password, the old private keys will be useless since they no longer control any funds.

I'd recommend doing frequent wallet backups to multiple removable media devices which you keep in multiple geographic locations until we have better tools for cold storage and lightweight clients.

Where can I find the non-draft version of this?  http://bitshares.org/bitshares-reloaded/ points to an under construction page.

Okay.  I think I'll remove or adapt the existing proposal code, and work on implementing the OP.

Currently, mandatory upgrades [1] are implemented by updated clients changing semantics on a hard coded block number.

This has the disadvantage that non-updated clients aren't aware of the upgrade taking place, rather they eventually see all delegates signing off on a malformed chain when the new semantics eventually allow a previously invalid transaction.

I propose allowing delegates to publish the following transaction types:

    wallet_delegate_propose_upgrade upgrade_name upgrade_id upgrade_quorum proposal_expiration_block upgrade_effective_block
    wallet_delegate_support_upgrade upgrade_id

upgrade_id is the hash of a JSON object hard-coded in updated clients, specifying the upgrade's parameters.

    blockchain_get_upgrade_support upgrade_id

The upgrade process then looks like this:

- Developers create code to implement new semantics
- Developers create upgrade_id
- upgrade_quorum is the number of delegates which need to sign the upgrade (usually 51)
- After proposal_expiration_block passes, wallet_delegate_support_upgrade operations on this upgrade_id become invalid
- upgrade_effective_block is the block when the new semantics go into effect

Currently checking whether an upgrade is enabled is done by statements like this:

    if( pending_block_num == BTS_V0_4_17_FORK_BLOCK_NUM )
    if( pending_block_num > BTS_V0_4_21_FORK_BLOCK_NUM )

The hardcoded constant BTS_Vx_y_z_FORK_BLOCK_NUM will simply be replaced by get_upgrade_effective_block(upgrade_id).

The get_upgrade_effective_block() function will be the upgrade_effective_block if at least upgrade_quorum delegates issued wallet_delegate_support_upgrade transactions before the proposal_expiration_block.

[1] "Mandatory upgrade" is preferred to "hardfork" for marketing reasons.

An interesting paper on a new data structure [1] was mentioned on HN [2].

If I read this right, it's a cheap challenge-response protocol for verifying a node performed a computation honestly.

I picture this as being able to potentially solve the "every node must compute every instruction of every transaction" scalability issue with Turing-complete Ethereum-like networks.

The core design idea I had was to publicly post the result of some computation, then if any nodes disagree they can challenge.  In a challenge, both sides post a bond, then you run the challenge-response protocol in the paper on the blockchain.  The loser forfeits their bond.

You could have a standing bond attached to the posted result which will be forfeit on any successful challenge.  You could have every standing bond accumulate inflationary shares proportional to its size, thus incentivizing people to certify third-party computations by bonding their funds to those results.  You should independently verify the computation before posting such a bond, however, since if you post your bond to an incorrect result then you will lose the bond because someone will be able to successfully challenge you.

I'm not sure how feasible any of this is in practice, I just wanted to post about some of the ways this paper directed my thoughts.

[1] http://people.csail.mit.edu/nickolai/papers/vandenhooff-versum.pdf

[2] https://news.ycombinator.com/item?id=8598244