Topic: BTC violates GAAP, result a mess. - page 4. (Read 13750 times)

Serialization means you cannot start next transaction until previous one completes. What I meant was that transaction which includes current best block hash is valid and can be executed in any subsequent 100 blocks. You can easily make one transaction off chain and then execute many others in mean time. Your first transaction i still valid if you broadcast it before 100th block is mined.

No, including hash of previous block still requires that you serialize transactions. You can't, for example make one transaction off-chain (as part of a protocol, for example), and continue to make & confirm transactions before that one ends up on the chain. The obvious solution is to allow not one, but more than one reference to an older transaction, up to a configurable amount. That way when you make a transaction you can specify how many future transactions can reference it, thereby allowing yourself as much concurrency as you need without running into the trap of maintaining history forever that sequence numbers put you in. Let's call these configurable number of references "outputs" - do you see where I'm going with this?

What bitcoin currently has is simply a better engineered version of your proposal.

I know it is not a flaw of bitcoin. Just two things:
1) Massive multi-node transaction processing for single account has little real world uses
2) You can allow such processing with second approach I proposed.
3) Even with per account sequence nodes would just need to rebroadcast tx not included in previous block with updated nonce.

EDIT:
4) If your really need to operate under system as bitcoin then nothing stops you from creating new account for every transaction always spending full account balance and sending change back to yourself. You can basically emulate most of bitcoin coin flow in account ledger system.

No i didn't. You can include any number of simulatenous tx in one block. Only after block is included sequence changes. There is also other way in updated post.

Congratulations, you've just centralized & serialized the transaction generation process (per-account). Good luck doing things like pre-authorizing offline transactions, or out-of-order transaction processing.

EDIT: That was mean and I apologize. There's nothing wrong with being ignorant so long as you seek out knowledge. A TxOut-based system lets you "sub-divide" an account (into separate transaction outputs), thereby letting you do things like out-of-order transaction execution or multi-node processing of the same account. This is a benefit, not a flaw of bitcoin's design.

I thought it was fairly obvious, but yes it is some kind of per account sequence. Could be simple counter, but this forces to keep empty accounts forever. Hash of block which include last spend operation from sender account would be better. You can safely emit multiple concurrent tx. If all are included in same block then all are valid. If some of them were left you just rebroadcast them with updated sequence.
It can be current best block hash and network could accept such tx in any of let say next 100 blocks. Network would discard duplicate tx in 100 blocks window so replaying would still be disallowed. There are multiple valid solutions.

I'm really asking honestly, but just don't like your arrogant tone and one liner replies without any arguments but always negative and invoking some kind of secret knowledge I should already know about.
So last time: why keeping per account sequence gives you a lot of real world problems? You guarantee uniqueness of all transactions this way and I don't see why this should any worse than bitcoin. Please show me how to exploit such system. If you don't want to tell me it's fine, just stop pointless attacks.

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"

Going to try to explain you once more with several SIMPLE ARGUMENTS why bitcoin has some of these properties you cannot seem or willing to understand.

As I already pointed out to you in another thread, the main idea behind bitcoin is that is it decentralized (= no central authority decides what is correct) and there is no trust between the nodes (a node not sticking to the rules cannot bring the system down). And this in comparison to the normal centralized banking system.

You don't seem to have a problem with what you call the technicalities of hashes, signatures and the block chain: this is indeed the first part of the bitcoin solution to the decentralized/no trust problem. It solves the problems related to deciding what is correct (= blockchain), and the prove you actually hold some coins (the signatures & hashes).

So now we come to the part where you don't understand why:

• transactions are made up the way they are ("destroying" coins, "create" new coins and the "change" thingy);
• there is no simple balance with adding/subtracting;
• there is no "reason of payment" or "comment" field with each transaction;
• bitcoin "struggles to simulate cash".

Let me start with the last point: bitcoin does not struggle to simulate cash, but it is rather the opposite: because of the solution Satoshi developed to the second part of the problems related to the decentralized/no trust problem (see below), bitcoins behave more or less like cash we know today. I think Satoshi made only the analogy to cash to help to understand this totally new form of "money".

So now the "other" problems that need to be solved when doing something decentralized with no trust.

First of all, all transactions are publicly know to everybody.
In analogy to your bank account: LvM, do you want everybody in the world to know the exact balance of your bank account, and each and every detail of every transaction you do ?
I don't think so. So that is why there is no "reason of payment" field, and there are no "accounts". Instead, there are bitcoin "addresses" that hold an amount of bitcoins.

Secondly, concurrent transactions can occur.
This is why in bitcoin there isn't a "simple" balance.
A simple example used in many programming tutorials on concurrency involves keeping track of a balance. And these examples show it is very easy to get improper balances when doing concurrent updates. In fact, you need to "lock" the balance before you start the transaction: after you get a lock on the balance, you can read it, update it and release the lock again.
Translated to bitcoin and the block chain: something is considered "correct" and "safe" when at least X blocks (X about 6) have passed since including the transaction into a block, what would mean you can only do 1 transaction every hour (on average 10 minutes between blocks). Balances are clearly not suitable.
Instead, bitcoin uses another kind of transactions: Starting point: X coins are transferred to an address A. When you want to transfer Y (Y<=X) coins from A to B, there is a transaction:

• that moves all X coins (because a partial move would mean you introduce balances which are not practical, see above)
• that sends Y coins to address B
• if Y

This transaction scheme allows for much more concurrency (somebody can own several bitcoin addresses and/or a bitcoin address can have multiple unspent "coins"), and allows easy verification of "double spending attempts" (an output is either used/spent or unused/available).

Because of this implementation, there is some analogy with "cash": If you need to pay 30 euro and you have a 50 euro bill, you spent the 50 euro bill and get a 20 euro bill as "change".

Oh, certainly LvM. I haven't ignored anyone on this forum until today.

Even best BTC clients like Armory are more like a tool or toy for developers than for commercial usage where (at least in my applications) thousands of electronic payments with all banks and currencies in the world can be initiated and recorded at the push of a button.

Never had problems to integrate "banking" into my commercial applications.
With BTC in its current state its simply impossible for me.

...and therefore I would like BTC to become a perfect alternative to state manipulated and controlled currencies.

In the present condition of BTC as a very(!!) primitive payment system which cannot be repaired on higher levels,
but as-it-is stubbornly defended  by ignorants knowing NOTHING about GAAP, nothing about the Golden rules of accounting this goal seems impossible to achieve.

Thank you, I listened to it.
The Prof Grundfest is w/o subtitles a bit difficult to understand for me.
Seems to speak mostly about crazy political questions (Obama, evil banks and governments etc.).
Might be ok.

What I like most is my namesake Ludwig von Mises,
the LvM Institute with articles like
America's first central bank was borne of a corrupt political deal
http://mises.org/daily/4270/Central-Banking-as-an-Engine-of-Corruption
or books like:
Ron Paul, END the FED: http://www.ronpaul.com/books/end-the-fed/

Yes, it prevents replaying. Don't keep us from your wisdom. Say why such efficient txs are not "useful" and why are "centralized"
No. It is thing that has all requirements of pegasus but only pony features.

That's exactly what is proposed here.
Why not do it?

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


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

i have watched this thread grow and am really confused about why anyone thinks it is interesting.

as a business owner, i understand that GAAP is a good set of principles to obey when operating a business, especially a publicly traded one. without a set of standards like GAAP, the US would certainly have had several more Enron-like events.

that said, what occurs to me is that GAAP is just that - a set of standards - and you cannot hope to encode the old set of standards into a new form without dragging all the bullshit of the previous financial system along with it. bitcoin is a new system that has its own flaws and attempting to make it GAAP-friendly would have made it ungainly in the utmost.

i fail to see how anything LvM has posted makes a substantive distinction between the bookkeeping associated with any other electronic payment system and bitcoin. all the usual niceties of double entry accounting can be applied to BTC as they would any other currency.

"One"? Of what

Before we continue. I wrote and must ask you again:

Would you really deny that?

You can have only one and always derive other from it. Storing it twice is a waste.

Bitcoin timestamps have +- 2h accuracy ;]
You cannot rely on it. Also person making payment have now way of knowing when his transaction will be included in block so can't calculate account balance after tx. There can be multiple payments to same account submitted simultaneously.

There is no way blockchain can check validity of such 'links' so it is totally useless. You can as good write such links in your notebook or post it on website.

aaaxn:
Not duplicate, I called it mirror-inverted.
Payer and receiver have an account.
Both are changed by the payment differently. Right?

More about GAAP here:
http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system
http://en.wikipedia.org/wiki/Generally_accepted_accounting_principles
http://en.wikipedia.org/wiki/International_Financial_Reporting_Standards
etc..


Yes. Same as in the present blocks. Where is the problem?

Yes. With a link to "normal" banks, of course. Would be just a nice additional feature.

Sorry. Seems I expected too much basic knowlegde of GAAP (Generally Accepted Accounting Principles)
More questions?