Quote from: aaaxn on June 01, 2013, 07:00:51 PM

Quote from: kjj on June 01, 2013, 01:53:35 PM

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".

Yes, it prevents replaying. Don't keep us from your wisdom. Say why such efficient txs are not "useful" and why are "centralized"

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

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

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

No. It is thing that has all requirements of pegasus but only pony features.

It is very common for people that don't understand the system very well (which you may or may not be) to vastly underestimate how much we got "for free" from our transaction -> transaction system.

Because each transaction is unique, it has a unique hash, which means that the transaction redeeming an output from it is also unique. This means that each signature is unique, etc, etc. In short, a replay in bitcoin is just the same transaction again, not a new instance of "Move X from A to B".

I'm not really keen on speculating about what senderLastMod means, and you don't seem inclined to tell me. Hopefully this means that you've solved some really hairy problems in distributed computing and are too busy writing your system to explain how it all works.

More likely, you think that you can use either the index of the latest version of the ledger or a per-address sequence of some sort as the nonce that protects your signature. Both of these options have big problems in the real world.

You seem like a smug little prick. Either you came by that bearing honestly, in which case I don't need to tell you where this scheme falls apart, or you are talking about things you don't really understand, in which case I don't want to tell you.

I suspect the second, so I'll conclude with a hint. "transaction rate vs. convergence"