I think we diverged here. I was kind of under the impression that we were coming up with a BIP 10+ that was more versatile (like, having a compact binary representation) so it could also be implemented in your device.
The protocol which I proposed is built on top of Protocol buffers. Having a separate parser for another format just to comply with BIP10 doesn't look smart enough.
I'd really like to see this "protocol" standardized across devices and applicaitons -- which was the original goal of BIP 10, but I was the only one using it, so it never really got the versatility of a real "standard"... I stopped developing it when it worked for Armory, knowing it would be expanded later.
The conversion from BIP10 to something built on top of PB can be quite straightforward, so even BIP10-compatible software might convert the format for the device easily. To be honest, I didn't study internals of the BIP10 protocol yet, I just watched the protocol format.
...that there won't need to be any special conversion for your device to be able to understand it
You still need some desktop software to work with the device. As far as Armory or Electrum will support this device and Armory or Electrum implements BIP10, there's really no need why device itself must understand BIP10. Or any simple desktop (command line) tool can convert BIP10 format and pass the transaction into the device over USB.
It sounded like you said the device could regenerate all of its addresses/public keys from the root ... but given the other limitations of the device
It will be computed by the computer, not by the device. I don't see problem here.
The protocol can easily be unified with all other devices/applications (i.e. BIP 10+) if you can have the device recognize its own addresses/pubkeys. I was hoping for that unification, but it may not be achievable/efficient to do so.
This protocol is low-level layer for communication between the device and desktop software. This protocol must be optimized for low-resource devices and must be really minimal. There's no need why this should use BIP10 at all.
So the real divergence here was that I assumed the device would be somewhat "independent." It sounds like, instead, your device will be wholly dependent on a host computer to do most of the work for it, and the device will literally only sign. There will always be a computer-in-the-loop with your watching-only wallet to reformat the thing-to-be-signed into this low-level format for the device. I had anticipated the device take, from any computer anywhere, a BIP10-like data stream, recognize it's own public keys/addresses, and get user confirmation to sign it.
Okay, we're on the same page now. My point is valid, that a BIP10+ could potentially serve this purpose if we added extra complexity to accommodate devices that don't even know their own address pool, but it's not necessary.
So, if you have some enormous transaction to sign, let's say with 100 inputs and the transaction data was 100 kB, can you at least hold 100 OutPoint-Value pairs in RAM? i.e. you feed in first supporting transaction and output index (because your transaction will be spending that output from that tx) and the device will hash it and confirm that the hash and then store the hash and output value in RAM. Then repeat for all supporting transactions to collect a list of "verified" outpoint-value pairs. Then when you feed in the transaction to be signed, it can go through it's local memory to confirm each outpoint that belongs to you to be signed.
Then, it sounds like, if that transaction is actually 100 kB, then you can't even hold the whole thing at once. If you have to sign 30 inputs, you would pass it in 30 times, each time with a different txin-script-in-txout-script-place-and-all-others-blanked. The thing can accumulate the hash as it goes, and then pass out the signatures one at a time when it's done reading the final transaction.
Is that too crazy? Or should the device be limited to handling transactions that will fit nicely into its cache? It could be a requirement of the software that interfaces it (Armory, Electrum, etc), that it will prevent the user from sending tx bigger than X kB...? However, even if this tx is within the size limit, there's no guarantee that any of your supporting transactions is within the size limit.