Quote from: aaaxn on May 31, 2013, 09:02:13 PM

Quote from: kjj on May 31, 2013, 08:21:22 PM

Give me a list of your 24 bytes, and I'll give you a partial list of capabilities you've thrown away. Without knowing your scheme, I'd guess that some subset of "secure", "useful", "decentralized" is not possible with the information you are keeping. Most likely, you've lost at least two of those.

1 + 5 + 5 + 5 + 8 = 24
This is simple pay to address transaction. I could probable make amount field even smaller and account offsets to until there are more than 2^32 simultaneous non-zero accounts.

Without knowing exactly what you mean by "senderLastMod", I'm can only speculate. I'm hoping it is something that provides replay resistance, because that would mean that you decided to keep "secure" at the cost of "useful" and "decentralized".

Quote from: aaaxn on May 31, 2013, 09:02:13 PM

Quote from: kjj on May 31, 2013, 08:21:22 PM

If we've had the scripting debate before, I'll just refer you back to that. I'm not sure how many people there are out there that think it wise to upgrade every node in the network all at once for every new transaction type. I thought that one was too many.

A scripting system lets everyone figure out what they need without needing any (new) help from the rest of the network. Writing new software for each transaction does in theory, allow more transaction types, and in that sense can be more "powerful", but it just isn't going to happen in a decentralized system. Do you also argue that no one should own a horse because a pegasus would be much better? In this case, the horse is just a pony, but the pegasus is still not real.

Reality check:

Quote from: Gavin Andresen on May 30, 2013, 05:38:19 PM

Security, yes (including potential for denial-of-service attacks of various sorts).

But demonstrate a spiffy, compelling use of new opcodes on testnet and we'll talk about making them standard.

Yup, a pony is an immature horse. Still more useful than a pegasus.