Bitcoin Forum

CASH simulation and GAAP fundamentals

At first glance you cannot really believe it, BUT:
BTC indeed tries to simulate CASH for CASHLESS transactions.
Result is a mess at the lowest level.

Beginning with Satoshi Nakamotos paper talking without any(!) reflection or explanation in its title about
"Bitcoin: A Peer-to-Peer Electronic CASH System"
http://bitcoin.org/bitcoin.pdf
Bitcoiners relentlessly struggle to simulate CASH of pure and genuine CASHLESS transactions, not hesitating a second to ask themselves, why this not at all understandable or even realizable intent should make ANY sense at all.

https://en.bitcoin.it/wiki/Change

"Money has no earmark".  
Forgetting this old wisdom they desparately try to simulate that.

WHY ???

Even real cash in a real wallet is normally inseparably mixed together so that we cannot know, which bills or coins came from A or B or C. To "trace" each bill or coin would even if real cash just be nonsens.

Instead of adding/substracting transferred amounts quite simply to/from the balance of the accounts involved...
they insinuate indeed, that they cannot but "destroy" all the money in the paying account and indeed create "new" BTC for payers and receivers assigning the "change" even to new so called "outputs". Armory does its best and provides the option to assign these "changings" to the "first input" address (whatever this exactly might be).

Obviously this "cash/change" idea also has nothing todo with technicalities like hashes, signatures, encryption, P2P db/network....
There is just NO explanation, why these confusing, time and space consuming pseudo-cash simulations exist at all.

Almost sure:

WITHOUT these cash motivated "changings", combined with almost each transfer creating "new" BTC to be "traced"

the internet traffic and blockchain size could be reduced by about a half.

But nobody sees, critisizes and tries to change that? - Cannot believe it.
All we find is the usual Satoshi liturgy -salted with the usual nebulosities and contradictions-  repeated, repeated, repeated....

"THE PRIMARY INNOVATION BEHIND BITCOIN" (sic)
https://en.bitcoin.it/wiki/Introduction
looks like worship the golden calf :D

While the GAAP, the Generally Accepted Accounting Principles are simply unknown and totally ignored.

While experienced in GAAP, electronic banking/bookkeeping I understand almost nothing about the details of ECDSA pp.

But nobody can tell me, that the "cash" idea has anything todo with technical things, with security, P2P or whatever else.

Instead of all simulated "changes" we need (also due to legal reasons)
two or three additional fields within the transfer records.

Within each tx record should be the field: "Reason of transaction" or "Posting text"
and if really not yet there - a field for the balance resulting from transfers belonging to this account.

If user A has an account, a so called "address" or "public key" (pbkA)
a GAAP conform transfer record could simply look like:

Transfer FROM A:
pbkA,  to,   time, reason of Tx, amount payed,    new balance
Transfer TO A:
pbkA,  from, time, reason of Tx, amount received, new balance

The field "to/from" contains the account ("address") of the other part.
The field "time" is needed for each transfer to update the balance accordingly.

For user B sending/receiving BTC to/from A we have the same (mirror-inverted).
Same if A has another account and transfers BTC between them.

Indexed by public key and transaction time all accounts can be quickly and easily found, checked and if needed, reconstructed/recomputed within milliseconds.

That's the core and basically all we need for each user aka public key or address.
Additional technical fields might be needed for ECDSA, encryption, P2P database/network problems...
Security and anonymity remain untouched. Real privacy doesn't exist anyway.

"Double spending"
btw a misleading "cash" orientated notion, praised as "The primary innovation behind bitcoin"
https://en.bitcoin.it/wiki/Introduction

better:
Spending more money you have
is simply avoided
1. by checking the balance of the account before any payment is really processed,
2. by an early reduction of the balance, i.e. before a payment is further promoted, confirmed etc.

Compared with the current logic and structure of transactions
see the TxBinaryMap, kindly provided by etotheipi in
https://en.bitcoin.it/wiki/File:TxBinaryMap.png
the time and space needed to check, execute and save transactions could be reduced by lets say 80%
Quite a lot of software and fields needed only to somehow workaround a false basic assumption could also be abandoned.

Having abolished not more or less than the "cash" simulation Bitcoin could become a well usable and understandable, quite normal money system
with the extraordinary advantage that there is no Helicopter-Bernanke and no other state governed central bank unscrupulously inflating the money expropriating its owners.

So LvM proudly declares his not at all revolutionary but basic idea to
Bitcoin Improvement Proposal BIP #1.
:D :D :D

At Pentecost the Holy Ghost hopefully has not forgotten the bitcoiners and their "Heroes" again.
:D :D :D

Carry-overs

We see a lot of discussions and proposals regarding the ever growing BTC blockchain (BC)....

https://bitcointalk.org/index.php?topic=88208.0;all (compressed BC by Etotheipi)
https://bitcointalk.org/index.php?topic=109467.0;all (Size BC in centuries by Nebulus)   
https://bitcointalk.org/index.php?topic=152219.0;all (Solution to Never-Ending BC by spartacusrex)
https://bitcointalk.org/index.php?topic=169204.0;all (MC2 by Tacotime
https://bitcointalk.org/index.php?topic=189239.0;all (Decrit by Etlase2)
https://bitcointalk.org/index.php?topic=195275.0;all (Mini-BC by Bitfreak! + Aaan)
etc...
[EDITED above a bit, May 31, 2013]

As far I could see, they all forget the normal way to simply avoid all size problems.
So it really must be recalled that thousand year old GAAP avoid ever growing books and now databases quite simply and naturally by
"carry-overs".

Carry-overs need just ONE entry to transfer the last balance of each account into a new database,
leaving and keeping(!) all previous (thousands or millions!) transactions in an (unchangeable but readable) "archiv"
(where there can be found if really needed - normally almost never again).

These so-called "year-end closings" and "carry-overs" are done annually (and are legally prescribed).

In BTC this could be done more or less often, i.e. always if there are "too many" transactions in the database making it too large for effective usage by clients and the P2P network.

Using this everywhere -indeed worldwide!- quite normal way of all bookkeeping the actual "blockchain" could be kept
small and handy and would not be bloated ad infinitum.

In BTC we just have todo with a very small part of GAAP: with payments only.

Impossible, complete nonsens, to keep all transactions over say 5, 10, 100, 200... years in ONE always to be transferred and checked database.
But till now I saw in BTC nowhere any usable solution for this
from the very inception foreseeable issue.

For a correct and efficient GAAP-conform payment system only the (slightly changed) TRANSACTION records are needed
Details decribed above: https://bitcointalk.org/index.php?topic=211835

"Blocks"

Another, but smaller problem are the "blocks" and their "miners" wanting more and more undefined (illegal?) amounts of money for transactions also.
First designed to produce new BTC the creation of blocks indeed is thought to continue forever!!
Even if all 21 Mio BTC are created.
Might be due to the present but in the long run unusable database structure,
not easy, but unavoidable to change!!

I like this idea

I normally try really hard to understand posts when it appears that the author isn't a native English speaker, so I read this whole thing four or five times, and I still can't...

Hey, wait a minute!  Are you the same LvM from the binary map thread (https://bitcointalk.org/index.php?topic=197324.0;all) that was saying that there were no logical differences between bitcoin and other currencies?


I assure you that you are not the first person to suggest a scheme of balance tracking.  Hell, you probably aren't even in the first thousand.  Feel free to augment your research into cryptocurrencies by looking into why no such proposals have gone anywhere.  Hint:  It isn't because we are all just too stupid to see your brilliance.

As it was also suggested to you in the German forum section: Please read about the inner workings and goals of Bitcoin before coming up with criticism, especially about a certain implementation like bitcoin-qt.

You can create a GAAP bitcoin client probably, but it likely won't support all features of Bitcoin. If you want a stricter set of features to implement GAAP in a cryptocurrency you're free to fork Bitcoin and present your work as an alternative currency - if it really works out well there, it is not impossible that this might be implemented in Bitcoin itself too. I do not believe that e.g. Multisig is really considered in any GAAP.

Accounting is intended to work well WITH money, not to BE money in my opinion.

didnt someone tell you in german section to read about bitcoin..

dont feed the troll?

Yep its a mess

Sorry, sorry
that my English, German and other language abilities are'nt just as perfect as dead certainly yours.

Is somehow new for me however, that imperfect use of a foreign language might be an argument.
Anyway. That seems to be the best argument to ignore arguments.
Perhaps I will use this nice feature myself in the future.
What about their authors German or Spanish abilities?

OH, YES! Not to forget!

We see here and there very very impressive and compelling arguments against GAAP.
Even if insulting me I must admit that I can't understand them.
But quite certainly I am silly and wrong.

Oh, no, no.  You don't get to pull this shit.

Your ideas are nonsense because you don't have a clue what bitcoin is.  This is clearly and extensively documented in the thread I linked.

We spent days trying to teach you about bitcoin.  The problem is not your imperfect command of English.  The problem is you.  I'm not going to waste yet more time explaining what is wrong with your alleged ideas.  Refer back to the other thread to see why.

So I admit contritely:

In BTC we indeed have to revise >1000 years old, worldwide accepted and used basic logic,
discovered btw centuries before Columbus discovered America. :D

But BTC is new and hence above any "old" logic?! Its just magic?!
Isn't it? Believe it or perish!
Or is "sorcerous" a better word for this new phenomenon?

Its a pity and regrettable that nobody seems able to really explain BTCs centuries overwhelming new logic,
the howto to record money transfers,
so that the rest of the world and idiots like me could at least try to understand it.

Bitcoin is in no way incompatible with GAAP.  Your incorrect understanding of bitcoin appears to be incompatible.

Repent! The GAAP is nigh!

While LvM isn't half as kooky as BenRayfield (WARNING Transactions and Addresses will soon be used as high volume data storage (https://bitcointalk.org/index.php?topic=60386.0)) he is slowly getting there. I don't think that LvM will ever match the famous Mentifex, but who can really tell?

http://www.nothingisreal.com/mentifex_faq.html

Bitcoin != accounting system.

If you find that the software "ledger" for example violates GAAP, please feel free to call them names and whatnot. A subset of the possibilities of Bitcoin can be made GAAP compliant and I even agree that using this as a kind of "standard" way of handling things might have made it easier in the beginning. Bitcoin can however do things (and is intended to do them!) that cannot be covered by an accounting system. This is by design and won't change without good reasons. "Because accountants can't process that using GAAP" is not a good reason imho.

Just because the most used bitcoin client exposes unspent transactions spendable by a certain private key as "account" does NOT mean that this has to be an account in the sense of accounting at all!

If I'm understanding well, what he proposes is for the chain to maintain a ledger with pairs (address, total balance) and transactions just saying "substract X from account Y and add them to Z" instead of "spend everything in Y, X in Z and the rest back to Y". Very similar to Ripple's ledger.
This would be a huge refactor and a hardfork, but I haven't actually heard any argument or explanation why the system isn't like that from the beginning.
Saying "you don't know what we don't use GAAP because you don't know bitcoin" doesn't help.
Please, some one explain him (and me) why GAAP is worse than cash/change in any aspect.

Essentially, the ledger system offers no advantages (or only fictional advantages), and has a host of disadvantages.  This really has been discussed to death.  I'm not making that up to get rid of him, I just don't want to rehash the whole topic for the 99th time.

There are two main problems, and plenty others that are more subtle.

First, a ledger system provides no meaningful resources savings (no reduction in storage space, no reduction in memory usage, no reduction in network traffic, no reduction in CPU usage) because we are already very lean, meaning that our transactions are very close to the absolute minimum amount of information necessary.

Second, a ledger system is necessarily less flexible and useful.  None of Mike's contracts would work in a ledger system without adding trusted third parties.  You could regain that functionality by emulating the current scripting system with the scripts attached to disposable accounts rather than disposable transactions, but why bother?  Bitcoin puts the complexity where it belongs, in the transaction.

As for accounting, there is nothing about bitcoin that is incompatible with it.  The problem seems to come up when you try to map accounting functions to bitcoin functions based on their names.  "Transaction" means something totally different in bitcoin than it does to an accountant.  Same with "account", "balance", etc, etc.  All of the ideas are compatible, as in, you can take an accounting-account and find an analogy in bitcoin, but that analog won't be a bitcoin-account, or a bitcoin-address, it will be something else, and that something else may not be "real" in bitcoin world.

I find the whole accounting discussion to be particularly tedious because the same thing is true in the real world, and yet, no one shows up on banking forums whining that bank-accounts are not exactly the same as accounting-accounts.

Thank you for the summary, kjj.
An "account" could be just an address/keypair. I think there could be some reduction in storage since the last block could include a ledger with all "account balances" removing the need for the whole merkle branch until coinbase for proof of inclusion of an output. Well, this would only serve for something like trust levels (ultimate compression algorithm), since some nodes will still want to validate the whole chain from the beginning.

Also "script per account" instead of "script per output" sounds like saving, although I guess this depends greatly on "account reuse" which is discouraged for privacy and security.

I believe that this may have been discussed to death, but a I'm not sure if in the context of "trust levels". Anyway, a link to an old thread would probably help to read the most common arguments and their refutals.

Regular users have no particular storage requirements in either system.
Miners need either the full UTXO set or the current ledger.  These are essentially the same thing, the same information.

If someone chooses to fully validate, they will need either the full transaction list since block 0, or the full transaction list since block 0.  :)  The trust/verification tradeoff is a bit different between the two systems, but in either case, you need essentially the same data to be able to perform similar verification.

The UTXO set is somewhat larger than the summary ledger in the degenerate case where someone is willing to operate with very little verification.  But that is a single-shot savings (per node), while the summary ledger is necessarily larger than just the delta from the previous version (which is what bitcoin really boils down to) leading to higher ongoing costs.

You've gotta be kidding? :D :D

OK. Nobody expects or suggests a complete accounting system.
But BTC is a payment system, used to transfer money.

Or would you even deny that BTC is used to transfer money?
I was told by another "Hero" that BTC is "just money" and nothing else. :D
The next one just told us: "Bitcoin is in no way incompatible with GAAP." :D


One example please, just ONE. I am almost sure, you are wrong.
Anyway. We cannot build more complex things on sand.
Might it be you have no idea how flexible and efficient GAAP really is?

In the wiki this basic notion GAAP doesn't appear at all.
https://en.bitcoin.it/w/index.php?search=GAAP&button=&title=Special%3ASearch
Conclusion: Bitcoiners know nothing about GAAP. Can be seen everywhere.

See no reasoning for your daring statement, kjj.
As showed in detail using GAAP would save plenty of resources (~ 80%).
Estimated 50% just by avoiding these funny "changings", endless more using carry-overs if needed...



See nothing special in Mike Hearn's so-called "contracts", namely:
Providing a deposit, Escrow, Assurance contracts, Using external state, Trading across chains, Rapidly-adjusted (micro)payments to a pre-determined party or whatever else.

All quite normal commercial transactions. Not at all hindered or restrainted by GAAP. Mike doesn't claim that himself.
On the contrary!
Mikes examples show again how difficult it might be to solve normally not at all existing "problems" with current BTC.

https://en.bitcoin.it/wiki/Contracts

I couldn't understand the point of your post as it seems English may not be your first language and quite a bit was incomprehensible, but I have to point out that this statement is false.

Money is earmarked. Look at the face of any denomination of dollar bill, there is a serial number which is on both the left and right side of the bill. Every dollar you earn and spend is QUITE traceable, if it weren't there would be FAR less risk involved in robbing banks and people wouldn't have to pay their taxes.

Many major criminal organizations are brought down specifically by tax evasion or the fact that the money in their possession has been traced back to a high profile robbery or they were given money by undercover agents/officers in exchange for drugs, guns, etc.. and the money with those serial numbers is found in their possession thus linking them to the illegal purchase/sale. I'm not saying these actions should be condoned, but the potential implications for governments and private entities to trace every sale, purchase and money gift are repulsive.

The idea behind bitcoin (aside from a decentralized currency which does not rely on governments or private entities like banks and the federal reserve) is that it is nobody's business but your own what you are spending your money on. Governments and private entities should not be able to track your purchases (which believe me, with cash everything you buy is tracked and recorded SOMEWHERE) nor should you be subject to taxation at every turn when buying/selling or gifting monies to another person.

In the U.S.A. we were promised no taxation without representation which essentially means that the people should not be taxed unless we have a fair say in our governmental proceedings, yet time and time again our government continues to rule against the will and desires of the masses. We are essentially living in a semi-benevolent dictatorship and we are paying out the ass (via taxes) for the luxury of living in this semi-benevolent dictatorship.

Bitcoin was created as a tool to assist in fighting back against taxation, invasion of privacy and in a way it helps to put some of the power back into the hands of the people.

@c4n10

I agree to your statement and esp. your political considerations.
No taxation without representation! Fine! :D

With Money has no earmark I remind what imho is meant with this (not?) popular saying:
the number printed on bills or where bills and coins exactly came from normally does not matter.

The Romans likewise used the slogan:
"Pecunia non olet" - Money has no smell. :D

In criminal and other special cases this might be different of course.
But even clearly stolen, robbed or extorted money can be acquired in good faith.
Thats the law at least since the old Romans.

BTC nevertheless tries to simulate such "earmarks" with its cash/change theatre, normally not relevant in cash and simply impossible in cashless transactions. A source of endless subsequent problems only.

You seem to be living under the peculiar delusion that accounting is primary, and that money exists to facilitate accounting.  However popular that delusion may be among accountants, around here, it just makes you sound silly.

I assure you that a business that wants both accounting and bitcoin can have both easily.

I'm not really sure what your argument is.  Either GAAP is flexible and can work with bitcoin, or bitcoin is incompatible with GAAP.  You can't seem to make up your mind.

Personally, I think that the profession of accounting will adapt to bitcoin just fine.  They may need to throw out some of their generally accepted principles*, the ones that make no sense in a bitcoin world, but new ones will take their place.

P.S.  In no way have you "shown" anything in your incoherent posts, far less "in detail".  If someone else has "showed in detail" your mythical ~80% savings, please feel free to point me to it.  Note also that my posts were about the technical problems with ledger-summary cryptocurrencies as compared to ledger-journal systems (like bitcoin).    If you feel that I'm wrong about them, you are free to make your own GAAPcoin and we'll see how the two systems fare in the arena.

*  Note that I make a clear division between accounting, and a body of standards that accountants use when dealing with the fiat world (GAAP).  This is not an accidental division, but an intentional one.  To argue that bitcoin is incompatible with accounting would be silly.  To argue that bitcoin must conform to present systems for accounting is just as silly.

Yes I know that. Its always the same with you. Cannot help it. Not my fault if you cannot understand my English.

Your imputations are rigth from the beginning as clearly as possible answered.
Anyway: I am not inclined to write esp. for you the same things twice, in the end again and again.

If you have exact counter-arguments lets hear them. :D
Good night.

This is not true. Ledger system done right provide big savings in memory, because you don't even have to store old past transactions. You can discard it after they are buried under enough blocks. See this for details https://bitcointalk.org/index.php?topic=195275.0
Furthermore there is always only single entry for each address while bitcoin can hold any amount of unspent outputs for single address.
Transactions in such system are much smaller, because you don't even have to include pubkey hashes but just offsets of account in db. I made some calculations and tx could be as small as 24 bytes + signature.

Well bitcoin is more flexible only in theory. Most functionality of scripts is turned off until developers decide such scripts are nessesary and won't bloat blockchain, network etc. It's effectively not more flexible than account ledger.
Bitcoin scripts are constrained while with ledger you can make more powerful concepts because you have access to turing complete programming language and current network state. You can make complex constructs for example to make secure atomic laundry (https://bitcointalk.org/index.php?topic=195275.msg2289285#msg2289285) and much more.

It is easily possible and actually recommended to use addresses as "transaction identifiers" instead of Tx hashes - so addresses are only used once, ever. That way the UTXO set would be equal to the "addresses with balance" set.

Something that might be hard to emulate with ledger systems would be different colored coins in one single address for example:
1 cCoin Satoshi representing 1 share of ASICMINER, 1 cCoin Satoshi representing 1 share of TradeFortessBTC.
If 1 Satoshi gets transferred off now, which one was it? Currently one can loot at the outputs used, with a ledger not so much.

My understanding of accounting is that you take finalized transactions and store them in a certain format.
Bitcoin however can deal with transactions that are not finalized, might never be finalized, depend on external events to be finalized, stay in limbo until one of the participants moves, depend on several parties to collude... and that's just the current functionality that is considered standard (there's much more possible with nonstandard scripts).

It seems to me (using a maybe bad analogy) similar to complain about web sites because they are breaking typography rules developed over the centuries when typesetting books and anything else to read - there are no chapter markings, "quotes" are a misused term all over the place and a title page often is done in a way that would make Mr. Gutenberg cringe!

It would just cause UTXO to be spread over many addresses instead of one. It wouldn't affect number of outputs. With account ledger one person gets payment to same address and they are merged. This is source of savings.

You just shouldn't mix different colored coins under one address. Such coins need to be separated anyway, so you wouldn't accidentally spend it. Such rule could be even enforced by network if colors are public.

Foreign currency accounts

Based on GAAP foreign currency accounts could quite easily be provided by BTC if there is just one little additional field in the GAAP-conform transaction records defining the currency used in the specific transactions (USD, EUR, BTC, XRP, JPC.... whatever)

And software beeing aware not mixing different currencies.

This very, very easily implemented feature would be a GREAT advancement in a worldwide used system like BTC.
Neil Armstrong would say: "One small step for BTC, one giant leap for mankind." :D

This doesn't save as much (of anything in particular) as you'd hope.  The problem is that you are comparing the pathologically bad case of bitcoin to the pathologically good case of the alternative.


This is perverse logic.  You are again comparing the worst case in one system to the best case in another.

Enlighten me. Bitcoin smallest transactions are ~250 bytes. Tx signature takes ~70 bytes. With account ledger smallest transaction would take 24 + 70 = 94 bytes while tx to address not currently in db would take ~22 bytes more and be still 2x smaller than bitcoin. Average tx would probably beat bitcoin even more (no need to combine inputs)

These were description of capabilities. No logic behind it. Programming language is more capable than scripts simple as that. Scripts are more flexible in theory but in reality they must be artificially limited to prevent abuse.

EDIT: Nice recent example of how scripts degenerated in 'convince developers your script use-case is important'
https://bitcointalk.org/index.php?topic=220273.msg2320603#msg2320603).

Carry-overs

Using balances is a very good idea, much better than current BTC.
But deleting old transfers is not GAAP-conform, therefore a bad idea.

See above about closing books and carry-overs: We start a small new database, but keep all previous transfers available in archives.

https://bitcointalk.org/index.php?topic=211835.msg2307474#msg2307474

Any BTC user should be able to read and download the archives.

Legally financial books must be kept available for at least 10 years.

Anyone can keep archived transactions for how long he want (and it's validity can be checked by anyone). I think especially node should keep all history of its own addresses. Full history is just not necessary for payment processing so standard nodes would just drop it and save history logging for specialized nodes.

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.

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.

<tx type, offsetSender, offsetReceiver, senderLastMod, amount>
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.

Reality check:

I love when people post ways to improve BTC without trying to make it into something tangible... I'll believe an account-tracking cryptocurrency is better when I see one that is better.

aaaxn:
Please explain the transaction records you propose more detailed.

Do you agree to my proposal?

https://bitcointalk.org/index.php?topic=211835.msg2221423#msg2221423

A field for the used currency could be added
(see foreign currencies account https://bitcointalk.org/index.php?topic=211835.msg2328815#msg2328815).
A numbering is possible but not needed (due to the timestamp, which could be date+milliseconds).

Or where a distinctions?
Please do not forget. Each transaction has 2 sides: payer and receiver.

So we need for each transaction 2 records, one for the payer, one for the receiver.
The entries in the corresponding fields are just mirror-inverted.
The amounts could and should simply be: - (minus) for the payer, + (plus) for the receiver

And please forget and ignore all the stuff and nonsens kjj is writing.
Insultings are no arguments, prove only that their author does not have them .
 

You don't seem to know much about how bitcoin operates and programming at all. Duplicate same data twice? Stupid.
Using timestamps in distributed network? Foreign currency account without any way to link them to real world accounts? You don't know what you are talking about.

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?

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.

"One"? Of what ???

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

Would you really deny that?

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.

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.

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

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.

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 :D 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/

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

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.

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

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<X, the rest (the so-called "change") is sent to another address owned by A. It can be the same as the original address, but because everything is publicly available, it is normally a new or another address owned by A, so that it is not immediately clear to everybody what is change and what is the actual payment.

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

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"

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.

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.

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.

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

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.

@bfever:


OK. BTC behaves more or less like cash. But it can't since cashless.

The field "reason of payment" should be encrypted, readable by sender/receiver only.
For commercial use the sender of money (not the receiver) has to decide for what he pays.



Thats the main problem.
Your "addresses" in my view are accounts with just one turnover only.
The question is: why only one?
To hide transfers and balances this way cannot be very successful, since all public.

The enforced "changings" make things even WORSE.
Each silly hackers (like me) see at a glance: which amount was there and where it's all gone.
Enlarging the transaction sizes almost twice the "change" is nothing but eyewash.

Better to use a reliable marketplace/escrow deposit where your BTC are mixed with all others they keep for others.
Trustees seem to use their "own" addresses to send "my" (legally their) BTC to anyone else.
Public tracing of transfers from there seems impossible.

The trustee would function almost exactly like any bank
(except that fiduciary money of a trustee is not endangered by bankruptcy).

But in this case an (encrypted) field "reason of tx" is definitely necessary for commercial usage.
A merchant and his computers not able to know WHO payed him for WHAT cannot use BTC.

Very important always to check the legal implications (place of jurisdiction etc.).
Thousands(!) lost their money trusting obscure BTC providers.


Yes, this is a normal problem with all banking, esp. if clients have their own networks using the same bank account for transactions.
The bank in all such cases simply refuses to accept transfers which exceed the disposable limit (balance).

Don't see why this should be very different in BTC.
Sure. In case of BTC the bank management is decentralized (P2P).
But logically its the same bank (blockchain).

Might happen, that different servers involved not yet know about transactions via other servers and the resulting balances.
But where is the problem, to ignore/delete all transactions exceeding the limit?
Seems easier to check that by the resulting balances instead of "earmarking" millions of BTC and even Satoshis as used/unused and create them "new" by simulated "changings".

In my view the main difference between BTC and normal banking is the public P2P database.
The rest (something else than transactions?) would and should allow quite normal banking procedures, making things much easier for developers and users. In the moment I cannot even try to include BTC into my applications.

Continuation from this thread: https://bitcointalk.org/index.php?topic=56424


*resisting the urge to answer something stupid*

Just a question: Would you care to explain, where the difference between the UTXO-Set, the Account-Tree (of the last proposal by bitfreak) and your "carry-overs" is?
And a polite request: Could we try to not further derail the Armory-thread, and carry on discussion about blockchain-scalability issues in the corresponding threads?

The GAAP criticisms are tiresome, but every problem someone has (especially if 99 different folks have it) is an opportunity.  This one is pretty big from the first-mover advantage point of view.

Programmers who make a BTC client which has exportable GAAP compliant translations in XML for quickbooks and other small and medium business software applications are going to make some fast cash.  This will also remove some barriers to adoption and make your own bitcoins worth more as more folks will want them.

The pieces of GAAP that aren't in bitcoin already can be left for the accountant to fill in in the XML or in the destination application.  Since it fills a need, it could even be a non-free client wallet addon to one of the other software packages.

I stopped reading after the first page.
Leave Bitcoin, as the protocol, as it is.
Write a new client software which implements GAAP.
Solve the trust issue in not having a full copy of the blockchain.
Profit.

Alternatively:
Create a fork which is lightweight and GAAP compatible.

I would suggest to try #1.

Ente

It seems we agree.  There are many GAAP compliant software packages. 
These deal with the unit-of-account issues which are always needed in multi-currency systems.
There are losses in currency translations which can be similar to how it deals with bitcoin.
The "missing fields" are not the problem of bitcoin, but of the GAAP software, these fields are also missing on dollar bills.
So the GAAP software package rewrites which include bitcoin and other alternatives are going to be available sooner or later.
It is not an impossible challenge, and needs nothing added to the protocol.

No, there neither is nor will ever be any GAAP compliant software for current BTC.
One simple Example: There is not even a "Reason of payment" field usable by the SENDER of money.

It's simply impossible to remedy all the deficiencies of the lowest level at higher levels.

Very, very bad that there are no financial experts explaining basics
to bloody laymen worshipping BTC with its cash/change and other nonsens like a golden calf.

Is your claim that quickbooks can never be used to make payments with BTC because if quickbooks puts a reason of payment in its ledger it will somehow break bitcoin?
Or are you completely misunderstanding my proposal as being one where bitcoin is changed to accommodate GAAP rather than accounting software be expanded to accommodate bitcoin?

GAAP compliant necessities cannot be achieved by "quickbooks" or any other higher software using BTC in its present condition.
Via BTC, for example, the always needed reason of payment cannot be written and transmitted from sender to receiver.

BTC as a (normally quite simple) payment system should and easily could provide the (simple) basics needed for professional money transfers.

Instead of taking care of the primaries first, all BTC discussion is filled with and buried behind the jargon and lingo of cryptologists, i.e. logically secondary questions and other self inflicted problems. The exploding size of the blockchain could be reduced by avoiding those obviously ridiculous "changings". And completely avoided by GAAP conform carry-overs.... etc.

Again you stick to the classic way of bank accounts, and only accepting this strict convention.

Let me try to rephrase:

The "problem" we face is: person P buys a thing "T" from merchant M, and P initiates the payment to M.
Now M needs to know that P paid for T when the payment arrives.

Traditional solution: M has a known bank account B, P can transfer the money to this account B. But because everybody else buying from M pays to this same account, M needs additional data. As the bank account of P is not known to M, something like a "reason of tx" field is necessary to relay the information "I'm P buying T".

Bitcoin solution: When M and P make the deal, M gives P a bitcoin address A. P pays the necessary bitcoins to this address A.
DONE. No further information is needed, as this bitcoin address is unique (only used once, exactly for the reason of P buying T).
An elegant solution that covers your problem of "merchant needs to be able to know WHO payed for WHAT", and at the same time keeping some privacy (nobody can link address A to M, except P).

Aren't we using IFRS?

This reason for payment record is the responsibility of the compliance software.  Not the responsibility of the currency.

Easy or not, it is the wrong place to solve that problem.  Compliance regimes vary with geography, jurisdiction, and time.
The burden of them must be tied to those compliance regimes, not to the currency, even when the currency is software.
The fact that bitcoin goes further toward making compliance easy than any other currency existing, does not change where the responsibility rests.
GAAP compliance software is the place for it. 
The same is true for PCI compliance software, FINcen compliance software, and the plethora of other local and regional regulation authorities.
Not all compliance regimes are even compatible with each other.  If currencies were responsible for all compliance, a global currency would be forever impossible.

Where is the "Reason of payment" field on my 10 EUR bill that I used in the bar last night to pay for a beer? How can they even do accounting if they don't know that?! ::)

Come on, so you just silently put this bill on the bar or did you attach message to it?

You are not aware what CASH is. Cash is not only bills or banknotes. Cash is every form of money (in paper, metal, wood, digital or whatever form) that you can instantaneously spend without increasing anyone's debt!

"Another one"...
I didn't sign anything, I didn't write a reason for payment and I also didn't receive a receipt (though if I really wanted to piss off the staff I could have requested one).

The thing is not that I just handed out money randomly, what I want to highlight is that also "traditional" money does NOT in all of it's forms (especially not in it's physical, most basic incarnation!) carry all the fields and features that the OP wants Bitcoin to include.

For Ripple, which is designed much more like a transfer of value (or rather trading) system, this might be a more valid concern - Bitcoin however does not try to be a replacement for SEPA transfers but for cash. I agree that Bitcoin transfers are paperless, they are not designed to be printed on paper though. Having them "in hand" is equal to having private key(s) + internet + client to sign&broadcast transactions + UTXOs for that private key(s).

I don't see the point of forcing the payment initiator to attach a certain unique statement to a payment that helps you find this entry in your ledger that it refers to when you can make him pay to a certain unique address instead that helps you find this entry in your ledger. If it would be possible to not just get 1 bank account but a few billion bank account numbers for the price of one, I guess this would be also employed in the traditional banking payments, as you can remove a source of potential error from the user.

So you simply agree that you attached message to your payment and not being able to do so would be real PITA. You could probably workaround this issue but hey, why don't just fix it?

The simple reason is that you don't fix accounting compliance matters in the currency, you put those fixes in accounting software.
The accounting software stores all the additional fields that are important to it as a part of the transactions.
Then the small business quickbooks software, can send a payment to the larger company SAP software (which has to contend with multi-jurisdictional compliance issues) which further issues payroll in 11 different countries.

The fact that there isn't a currency that does GAAP compliance on its own may be because GAAP rules change, and currency is not meant to change, it is meant to be stable.

The surest way to get a project to fail, is to try to make that project do things that it ought not be doing.

Attaching message to payment is about convenience, not about GAAP compliance. Is bitcoin success depending on NOT FOLLOWING any of GAAP rules?

No, but it might depend on ignoring them on occasion.
The currency remains the wrong place to put this convenience.
Bitcoin AND ALL CURRENCIES are not the place to solve this problem.

The right places could be in a bitcoin wallet, the accounting software, or in the financial service provider, or in any of the volatile entities that rise and fall with the constantly changing regulatory environments in the thousands of jurisdictions worldwide.

This is not an example of a design flaw, but one of design success.  By not attempting to resolve problems outside the domain of the currency, the currency is more resilient and stable.

It also provides for the industrious Bitcoin Wallet programmers to localize wallet software that can accommodate the peculiar regulatory issues of the different constituencies.  The competitive software market can decide how to send these additional messages to each other through bitmessage, or through some other channel that satisfies the standards.

Another issue which can get complicated is the "unit of account" field.  Again it is a complicated issue for a multi-jurisdictional currency.  And it is best solved in the accounting software, not in the currency.

To make the point a more clear, GAAP may not be the prevailing standard for much longer even in the US as there is an increasing tendency to adopt the "principle-based" system of IFRS over the "rule-based" GAAP.  If compliance needed to be incorporated into the money, such a change would be less feasible.  If the US had to burn and reprint all the dollars to comply with a different standard, that would be a mess indeed.

There are many pieces to an economic ecosystem, resolving issues in the proper places helps to keep it tidy, what the OP is suggesting is a way to make it messier rather than cleaner, but it IS a problem to be addressed, just needs to be done in the right places.

I'd be interested to know that as well.

Traditionally, currency systems were designed the way OP suggests.  Not sure what was the rationale for designing the transactions this way.  It's certainly irregular, but perhaps there was some kind of articulated reason somewhere.

It's certainly possible to have a TX format as OP suggests.  Not sure how you could implement complex transaction types ie. Contracts though.  It is true that it would far more efficient as far as computing balances go.

Because it makes good engineering sense.

Technically we have a balance sheet anyway:  the set of unspent transaction outputs (UTXO).

It certainly does not make engineering sense for payment system to keep track of non-necessary information about UXTO when all user care about is account balance. So please elaborate.

On the contrary, forcing me to write "I, [name here], used this bill to pay for a beer in the evening of the 8th of June 2013 in the pub named [insert name]" on each and every bill I use would be a PITA.
The bar will either just have an internal receipt system where the barkeeper enters my purchase + note or even just do a total "We had xxx EUR before opening, we have XXXXX EUR after closing" calculation. Why should I as customer be exposed to their accounting practices? It's in my best interest to consume alcohol an NOT fill out forms or attach messages to my payments!

Also the payment of the change money (coins...) I received back should have come with a "message" - again, I didn't need or want that, as it was and still is simply not possible and also not necessary to follow GAAP in these kind of cash transactions.

If one simply follows recommended usage patterns in Bitcoin and uses each address exactly once, these addresses itself become the "messages" or identifiers for each and every transaction. Also it is not necessary to know where money actually came from (outside of KYC territory) to do proper accounting of it. I still don't see the issue where you cannot do proper accounting with Bitcoins. Just because the internal lingo is a bit off (imagine "account" as a bunch of addresses instead of a single one and you're golden) does not mean that this system is doomed, badly engineered or completely impossible to use in accounting.

You are totally missing the point. Your money and change comes with message. You don't need to write it down of course. You can say it. YOu can point your finger to beer, whatever. Person to person contact is inherent feature of cash and that is why you don't need to write message on notes. You always see person you trade with. It is part of 'cash protocol'. Bitcoin is different and without ability to attach message it is similiar to making cash transaction without ability to see or communicate with other side

Jeff, thanks for the response.

Was there some kind of recorded discussion about why it was done this way?

yes we have the set of UTXOs, but the entire chain must be traversed in order to compute this set!  Thus computation issues are built into the system.  If you were to have a tx format like OP suggests, you could eliminate much of the computation(to find a balance, you just find the last tx with account X as destination).

Of course I really don't know how you could implement the scripting system with this.

you can do something like this with Bitcoin, simply by embedding a hash of your message(or the message itself if brief enough) in the script field.

Right!
And then the wallet software or cash register or accounting package can be used to assign whichever variables the particular regulatory regime requires at the time.

Without the current design, you cannot have a zero trust system.

Most efficient designs are of course possible, but decrease trust.  SPV is an example.

And who says system is doomed or makes accounting impossible? It is just inconvenient and require a lot of work to do simplest thing. I don't understand why one have to defend every little bitcoin feature. Even one that are just byproducts of system design (attaching messages to txns is disabled because it would overload network and bloat blockchain)

Right.  Why confuse the money with a "payment system"?
When you send money online with your bank, you can add all sorts of information to it that are not a part of the money.  They are a part of the payment system.

It isn't the issue for Bitcoin, it is the issue for the Bitcoin payment system, which includes wallet software and accounting packages and etc

Wow, it's really powerful statement and really questionable. I hope it comes with formal proof :)
Blockchain system can secure almost any underlying data structure (think of namecoin) and I don't see why it cannot be account ledger.

You snipped the relevant, quoted context for the response given.

The entire transaction history is required for a zero trust system.

this is true.

however what makes Bitcoin unique is the 'mining' aspect.  So you need a way to enforce this economy of transaction processing.

I recently developed an alternative, but it's not 'zero trust', it's more 'many trust'.  In other words the block chain depends on trusting many parties not to collude.  This kind of scenario is implicit in many financial schema, ie. Digital Gold Currencies, Community Currencies, etc.

https://docs.google.com/file/d/0BwUFHE6KYsM0ZkxLVmFwbXQ3ck0/edit?usp=sharing

https://github.com/BlueMeanie/ConfidenceChainsSimulation/wiki/Features

I don't think a 'zero trust' currency actually exists.  It will appear to exist up until the time someone exploits it.  For instance Bitcoin trust model is very robust, but we must trust that someone doesn't overload the system with computing power(51% attack).

Hi Jeff,

you can have the entire transaction history while adhering to the suggestions of OP.  It would just be more efficient to compute the account balances.  You might lose something though, perhaps you know?  :)

-bm

I remember the discussion from about 8 years ago.  Recording was specifically prohibited during the discussion.  The reasons for that may be obvious.

Bitcoin blockchain has hardcoded checkpoints, which means earlier blocks can never be changed. if bitcoin used account ledger instead of uxto list, all transactions before checkpoint could be forgotten without reducing security.

bfever:

Yes. I do!!!! :D
And I know what I am talking about. :D


Yes, fine.
Difficult and strange enough, but might work in this very simple example
THOUGH any legal caveats, exceptions, conditions, reservations cannot be articulated by the sender (P). 

Commercially we have quite a lot of additional legal and practical problems with the (useless*) workaround of changing addresses.

Example:
If customer P has to pay -due to different contracts- more than one bill for things like T1,T2..Tx he has to get from M more than one address A,B,C,D... to be used for his 10 or 20 payments. Might be a bit difficult for a normal customer to use for each invoice another address, esp. if he does not want to pay a special bill. If P on the other hand wants to pay the sum of all bills by ONE transfer problems arise on both sides.

Our merchant M might have hundreds or thousands different customers daily. So he has to produce and transmit hundreds, thousands special addresses to his customers.... Even with perfectly integrated QR-Codes this is not just fun.

In normal life we register the bank accounts of all our customers/merchants just once in our accounting system.
Bank accounts of merchants are printed on each letter/invoice.

With current BTC you have to change thousands of these entries ("addresses") daily.
Even for the same customer buying several things in different contracts.

Result is an error-prone MESS with daily thousand probabilities of errors.
Imagine that a customer/merchant might use in any case the wrong address.
How can that be repaired?

All this hide-and-seek behind different addresses only to avoid a simple field reason of payment !?


Privacy is NOT guaranteed by this not very elegant but cumbersome way since all public.
All customers even know the NAME of the receiver and can check what their merchant M is doing with the money received. All customers can (and legally may?) publish their knowledge in the internet.
Result: the whole world, esp. all competitors can check it regardless of all the addresses used.

Better we forget complicated and eyewashing ideas producing error-prone workload and problems only.

Not to speak of the other problems BTC is producing with its current concept  -
easily avoided by simplest GAAP needed and used for each payment system in the world.

=====================================


As already said:
That's impossible with current BTC since there is no such record/field to use.

But very interesting indeed to see how you or anybody else can produce a software, able to write into a not existing BTC field.
lol :D
If the field is provided any software could do that, of course.


Also already said:
A "currency" is "responsible" for nothing.

BTC is a payment system not just a currency.

https://bitcointalk.org/index.php?topic=211835.msg2321400#msg2321400

Money which cannot be transferred is useless.


Nope.

Paying your beer or anything else with cash is ALWAYS accompanied by an explicit or implicit reason of payment.

You just said it yourself (YOU payed "for a beer"). :D :D

BTC molesting the complete net with its clumsy, useless, really infantile "Cash/Change" simulations
simply forgot this simple, obvious and most important FACT.

btw: Asked you a few questions you did not answer.
https://bitcointalk.org/index.php?topic=211835.msg2321400#msg2321400

Call it as you like. The "cash/change" simulation is not my idea. :D

btw:
Debts and claims as juridical things have nothing todo with the relative items claimed or debted.
Apples and a claim or debt of apples are quite different things.

With money and anything else its exactly the same.
Money is money and an apple an apple. Not a "debt" as sometimes insinuated.

this system of inputs and outputs was indicated in the Satoshi whitepaper.

Oh noes!  We can't just use one invoice for everyone, but we have to make one special for each order.  The horror...

Seriously, can you guys stop feeding this troll?  He has absolutely zero understanding of how bitcoin actually works, so he made up a bunch of nonsense in his head, and now he whines on the forums that his imaginary version doesn't work right.

For example...


This is so full of fail that I'm not sure where to even start.  I guess I could say that addresses don't delete themselves once used, but I think my words would fall on (willfully) deaf ears.

 I ran into something the other day that shows how different the bitcoin system of accounting really is.

 It occurred to me that if we could have a very simple CREDIT system, then we could also hedge the price of BTC.  ex.  If I think BTC is going to appreciate, then I LOAN out BTC.  If I think BTC is going to depreciate, I BORROW BTC[1].  It's that simple really.  Most instruments and market functions can be derived from this basic credit device.

 So all we need to do is have a time release TX right?  as in - make a TX going out(the loan) and make another TX going in that is time dependent.  Sounds like it would work right?  problem is that you cannot SPEND the money if the TX is already created, even if it's time dependent.  Thus, I cannot cash the BTC out for USD while I have it on loan.  Thus the Bitcoin system ISN'T a system of credits and debits as accountants would expect.  It has very different qualities.  You can derive credits and debits from the basic data.  A Bitcion TX is NOT AN ACCOUNT LEDGER.  Bitcoin devs will probably read this and say: 'no duh?' - but for those coming from the accounting worldex, who expect these features will no doubt be suprised to find they dont exist here.  Bitcoin's TX structure ensures that there can never be unsettled transactions.  You can NEVER have a TX that results in 'sorry funds are not there' - simply can't happen.

 It reminds me of the common issue of managing multithreaded bank accounts: http://msdn.microsoft.com/en-us/magazine/cc817398.aspx , something tells me the thing we're looking for is related to that.  The Bitcoin system of account protects against many kinds of corruptions such as indicated in the link.  In Bitcoin the order of TX might be rearranged so the transaction flows must be explicit.  The TX structure, historically, is not coincidental it was conceived as an integral part of the system from the start.  It's mentioned in the whitepaper.
 

[1] this is what the notion INTEREST RATES are all about.  DING!

You are familiar with the payment protocol that is planned?
- https://bitcoinfoundation.org/blog/?p=85

Note this as well:
- https://gist.github.com/gavinandresen/4120476

The words are not for the troll alone.  This criticism is not altogether uncommon and truthfully, 99% of the people on the planet know less than LvM does about bitcoin.
Who knows, maybe we are writing his term paper for him (or some one else reading this).  Its not horribad to rehash this criticism every once in a while.  It won't be the last time.

LvM, I have to agree with kjj, this is so completely wrong.

In your system, there is indeed one "destination address" for each merchant (in fact not completely true, most merchants do have more then one bank account),  and that is exactly why you NEED TO ADD a "reason of payment", otherwise the poor merchant can't know who paid for what. And exactly for each customer (hundreds or thousand each day as you say), there has to be some kind of additional data attached (in our country, big companies use the "structured message", but it could also be for instance the invoice number), which is not choosen by the customer, but by the merchants (otherwise the merchant again can't automate the receiving payments as he has no clue how a customer will indicate/format his "reason of payment").
So where is the difference between that "structured message" and a bitcoin address associated with one purchase/invoice/whatever ? The customer needs to enter additional information (the reason of payment or the bitcoin address) in both scenario's.

You also say that whole thing with different bitcoin addresses is not hiding anything. So please, can you indicate how many bitcoins I have ? Or how many MTGox has ? I don't think so.

G.A.A.P. is an inferior "accounting protocol" in any case. The best A.A.P. would be, to quote the Geico Commercial: "So easy, a cave man could do it." I have came up with an idea of this sort:

https://bitcointalk.org/index.php?topic=225783.msg2375477


The model above proposes eliminating the need for a separate balance sheet, income statement, and statement of cash flows. (FYI: These are three main types of financial statements prepared by accountants.) Instead of a record of transactions, a blockchain here tracks a record of income sources and their allocation. The balance sheet, income statement, and statement of cash flows can then be compiled from the blockchain using automatic software. Transactions that might occur twice every week (such as visits to various US stores) can be condensed to a single event on the blockchain, saving valuable information storage. This is made possible by the concept which I have dubbed the "Balancome Statement":


Literally everything accounting should be simple enough to work on an interface of such simplicity as I envision. This will keep the blockchain size low while still meeting the demands of businesses to do their accounting in BitCoin without adding any significant burdens. This will also be required to encourage the general public, who do not want to constantly engage in currency conversions, to solve real day-to-day financial imbalances and manage financial risk with a few clicks or taps. If we expect BitCoin to go to something like $1,000 or more per BTC (i.e. market cap of over $10 billion), we will NEED something like this.

You make this too complicated. Use Fair Market Value accounting. Declare gains and losses on the income statement and other documents as needed. In short, account for BitCoins the same way you would account for gold or silver. Problem solved.

I'm still not sure you people understand what LvM is proposing, so I will rephrase it.

Ripple.com uses what he wants instead of inputs/outputs. It also has a scripting system.
Why would they regret to use a regular ledger instead of inputs/outputs?

I don't think they will. Personally I don't think inputs/outputs are inferior enough to change it at this point.
As said, the refactor would be big, and you would need a hard fork. But I'm still missing why Satoshi didn't make it a balances ledger from the beginning.

Why is it a mistake on the part of ripple devs to substitute inputs/outputs with GAAP?

It protects against reorganization attacks.

I don't see why reorgs are a problem using sequence numbers to serialize the transactions from an address.
But that makes you remember empty addresses and their sequence numbers forever to avoid replays.
If they used the hash of the last transaction from each address, you could forget about empty addresses or "destroy accounts".

By the way, unlike the OP I don't want a memo field in the chain and I know the current setup can perfectly work with accounting systems. I'm just curious about the technical arguments in favor of inputs/outputs.

About scripts...I think in Ripple they have 2 types of transactions: regular transactions and contracts; but don't take my word for it. In any case, I don't take that as a serious argument in favor of the UTXO approach.
Anything can be done with BOTH approaches if designed properly. And I don't see why contracts should be more complicated with a ledger instead of an utxo. In fact, it seems to me that the language can be of a higher level (easier to use) if you chose the ledger.

If you add a hash of the previous transaction, and if you extend your proposal to allow transactions to include more than one parent input, then guess what? That exactly describe the transaction output system bitcoin actually uses. I don't think they are as different as you or LvM think they are.

And the transaction hash provides an index useful in adding whatever additional elements are needed for the variety of ever-changing accounting standards - to the external compliance software, and outside the block chain.

If you mean last sending transaction hash then you need to store last transaction hash forever. If you mean last receive transaction than you have problems with incoming transaction invalidating your outstanding spend transactions. It's not good way. I think it's best to use current best block number with limited duplicate search. http://bitfreak.info/mbc-wiki/index.php?title=Transaction_Signing


Not so fast you need to include more constraints like always spending entire account balance and keeping separately coins sent to one address in multiple chunks. But in general you are right. You can think bitcoin of special case of account ledger.

It is a balance ledger.  It's a log structured database.  The reason is because you want to trust each successful miner with only a single set of modifications to the database (the TXs).  It makes sense to use a log structured database to keep track of the ledger.  Unfortunately, its a bitch to parse and distribute, prune and whatnot.  But the underlying reason is the same that this kind of DB is used for example in SSDs. 

BTW OP, does gold violate GAAP? 

No, that's true with sequence number, but not with hash of last sending transaction, that's exa what I'm trying to avoid.
If an "account" is forgotten in the ledger when its balance reach zero, you can have problems with sequence numbers, because if the owner of the "resurrects the address" anyone storing the full log can replay the transactions. With the hash of the last sending transaction you can avoid this, you just use the first receving transaction hash as the first hash to build on top of.
Your solution on the other hand is fragile to reorgs.


So it seems the protection against reorgs is the answer.
You maaku claim they're equivalent. Any advantage then over a more ripple.com-like data strcture?

Here's one for the other approach: shorter transactions for the basic use case of sending an amount from one address to another. You don't even need scripts for the basic case.


Do you mind to explain the reason? That may answer the question.

That's true for both approaches.

A couple of hours ago I purchased a Coke bottle from a vending machine. I inserted a 2 euro coin, pressed a button, got a Coke bottle and 20 eurocent coin in change.

There was no "reason of payment" field in either the 2 euro coin or the 20 cent coin. Trust was involved, of course. And of course the transaction ends  up in some kind of a GAAP compliant ledger eventually (likely bundled into other nameless transactions).

An analoguous scenario with Bitcoin would be a vending machine that accepts Bitcoin (this one only accepts physical coins and phone calls). It's not the currency's responsibility to do the accounting. Bitcoin does something a bit like accounting but it doesn't do it because of accounting convenience, instead it does it in order to be trustless and decentralised. Because it does things like this it's actually easier to handle Bitcoin in an accounting software than physical foreign currency.

To clarify again, I don't want a reason of payment field and I undesrtand that GAAP can be implemented on an upper layer without problem.
I'm interested in the protocol core data structures.
Both approaches are equaly powerful: all functionality can be implemented on top of both.
To me the simplest approach is to just keep balances on addresses and made contracts (script) a special case.
But Satoshi preferred the inputs/outputs approach for some reason I ignore.
Does anybody know the reason?

Any answers for Jtimon?

yes (https://bitcointalk.org/index.php?topic=211835.msg2318811#msg2318811)

GAAP uses arbitrary rules for compliance which change from time to time.  They are also inconsistently enforced, regional rather than global, and essentially transitory.
In short, GAAP compliance doesn't belong in the core protocol.  It is easy enough to do at another level or with already planned BIPs that it need not be further addressed in this context.

That was essentially the answer I was given in 2005, (but without the BIP enhancements) and it still applies.