Quote from: clemahieu on January 18, 2015, 10:42:39 PM

I called parts of it a block chain since the send/receive blocks contain a hash of the previous block and it has a one-follows-another order. It's different than other cryptos in that one block is one transaction, a send or a receive, where others contain many transactions.

Thanks for spending the time you did looking at it, sorry about the lack of comments that's admittedly in poor style.

These differ from off-chain transactions in that each chain is replicated to all peers so all account actions are observed and validated by everyone. Rather than packing all transactions in to a single chain, all transactions for a single account are in a single chain.

On the double spending front, since all blocks for each chain are replicated to everyone, nodes can ask and publish their view of signed Y-follows-X blocks. If anyone instead sees a signed Z-follows-X block this is a fork and needs resolution. Unlike monolithic blockchains, a fork in this system only affects a single account instead of everyone, again working toward scalability where we don't stall everyone because one section has an issue.

Resolution is done through a weighted vote system where losing blocks and dependents are rolled back. Senders can be sure they're not receiving a double spend by observing votes and tallying them, if they observe no forks or a resolved fork they can safely accept the transaction in to their chain. Notice though that resolution is never needed in the normal, well-behaved case. Forks only happen with signed, conflicting blocks; only accounts that are misbehaving by intentionally creating forks will every be put up for resolution.

Let me know if any of what I wrote doesn't make sense.

So a block is taken as a single tx id with timestamp? If so this seems to fall into the category of Transactions as Proof of Work. I still see a number of challenges with this system. First up of course consensus; at what point can a transaction block be viewed as verified and have an acceptable level of cryptographic confirmations inside a network with an unknown number of peers. I actually see hard-coded rounds of confirmations as a possibility for this. Secondly, how do you make the attack you have just described as costly as possible. Since the Bitcoin community is always very passionate about strong security, that is so far unmatched by anything else, I am actually particularly intrigued by this point. Of course we can look at typical solutions like including a transaction fee, expanding the proofhash to multiple layers and reward good actors for their work.