1) Smaller transactions - transactions could use just account tree offsets instead of addresses / public keys. We can address more accounts than we will probably ever need with 5 bytes. Addresses takes 25 bytes and public keys 65 bytes.
In addition to this, 32-byte hashes are not necessary to verify receipt of previous transactions. Peers who have not even communicated with each other before can reference transactions like so:
[timestamp - 4 bytes for each second]
[2-4 bytes of account offset, depending on what is most useful based on transaction activity - 2-4 bytes once for each tx that shares this offset]
[remaining 1-3 bytes for account offset]+[1 byte pseudo-hash]
The 1 byte pseudo-hash could be bigger, but it limits one account to 256 transactions per second, although the client will have to be aware of pseudo-hash collisions. When Visa is only like 4,000 transactions per second, this can't be that big of an issue. So the maximum one transaction could cost in wasted bandwidth is 10 bytes, but on a busy network, most transactions will only cost around 3 bytes to verify receipt or reference it with another peer. This is presuming my initial idea of using timestamps to identify specific transactions. It also allows for an easy way to locate transactions in the transaction block chain, though this is going into my design, but it's the one I know. *shrug*
Although bitcoin could use some protocol tweaking, it still *at best* has to send 32 bytes, but right now just goes ahead and wastes the full 300 bytes or whatever a typical tx is. 32 bytes->3 bytes on a busy network is gigabytes saved daily per node.
2) Including messages in transactions. We don't need to store transactions indefinitely so we can permit short messages attached to payments (eg. order id). This would improve user experience a lot.
8 bytes I think is an ideal number that allows for setting up a receipt/order system/identity proof. I think bank-like intermediaries (preferably anonymous ones, but that is technology that has to be proposed and advanced outside the network) will be commonly used to preserve anonymity. Account ledgers have some caveats that they are slightly less anonymous than pseudotransactions a la bitcoin. Reusing account numbers needs to be encouraged by lower transaction fees, because it is in the interest of the health of the network. If there are intermediaries that provide you with 8-byte mini-addresses, you can preserve that anonymity completely from everyone except the bank, unless there are ways to provide this anonymously in the future. Those who want bitcoin's pseudonymity can still do it, but tx fees will be higher.
3) We can get rid of sending change back to ourselfs because we can spend any amount of bitcoin from our account.
This is considered part of bitcoin's pseudonymity as only you and the receiver know which part of the tx is the payment and which is the change. But we all know that bitcoin isn't all that anonymous, and with an account ledger making things even trickier, the idea of pseudonymity needs to be redressed.
1) Accounts with descriptions. We can allow attaching custom names to account eg. 'Payment address for shop.example.com'. This description could be presented to users paying to this address. Huge user experience boost.
I had this idea for early encoin proposals, but I don't like it because it will create a rush of custom address stealing. If businesses are public on the chain, users can associate the addresses manually. If they use intermediaries, this could still be addressed with using business->user account numbers in the tx message.
2) Multi signature accounts. We can make accounts with multiple pubkeys attached and require M of N signatures to spend from this address.
3) Limited accounts. We can define maximum withdrawal limits per time period for accounts.
Easy peasy stuff with a ledger. Gotta make sure to have "master" keys that can change those account options, not the accounts themselves. Keep the master key cold and let the hot wallet do its work without fear of a total catastrophe if there is an incident.
4) We can extend account types if needed. This system is actually more powerful than bitcoin scripts (we can always make accounts with scripts).
Yes, but there needs to be a process of acceptance for this. Say, a voting system.
Even if account types are just complex uses of the scripting system, to save the data required to store these simply (and to make sure everyone has the exact same ledger), the account "types" need to be defined and everyone needs to agree on it.
Feel free to extend this list.
Anyone who plans on reusing a custom transaction could set a custom transaction type up themselves, basically a script-hash storage system. Then it could reference the custom type in a tx and only supply the variables needed to suit the script-hash, saving data. Of course there have to be fees to store this stuff, but people who use the same script-hash a lot could save money on a fee-per-function type tx fee.
A somewhat out-there possibility is to have a proof-of-work storage function. Small networks could use the ledger's proof-of-work (or proof-of-consensus) as a timestamping service and have the final say on the order of that network's events.
I have some other ideas somewhere, but it would require digging up really old notes.
