A confirmation (creating a block) is an expensive operation. However, every operation can in principle be performed by any computer. Suppose that a seller waits for 6 confirmations for a transaction T0. After the seller receives confirmations and gives goods, the buyer inserts into the network 7 prepared confirmations confirming a conflicting transaction T1, and T1 expels T0. Money disappears from seller's account.

If the buyer spends 30 days in preparing 7 confirmations and the network spends (1/6/24) days producing every confirmation, than the buyer should own only (1/6/24)/(30/7) = 1/617 part of the network -- not so much. If this fraud is possible, should not seller's behavior (how many confirmations to await) depend on the amount of transferred money?

Yes, the size of transactions will be smaller in my design, that's why I am proposing it.

"Transactions" says that a transaction may contain multiple outputs. If I understand correctly from "Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System", a transaction may not be deleted if some output of that transaction is not spent. "Spent" = referred as input in some other transaction. Therefore every node can calculate how much money each Bitcoin address owns. Then we can refer in transactions to Bitcoin addresses instead of transaction hashes.

IMHO this new system is better. Each transaction contains numbers: money transferred; balances of each involved Bitcoin address; time. A transaction may not be deleted if it is last for some account. To calculate balance of a Bitcoin address, take the last transaction involving that Bitcoin address. We do not need to check in the database that each output is spent only once. Structure of the database is simpler. Transactions with incorrect time will be rejected by the same algorithm which rejects double spending (I can elaborate). There are no "coins" (outputs of transactions), thus accounting in this system is closer to payment systems with central authority.