Topic: BTC violates GAAP, result a mess. (Read 13750 times)
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.
Any answers for Jtimon?
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?
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?
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.
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.
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".
If you mean last sending transaction hash then you need to store last transaction hash forever.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".
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.
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.
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.
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".
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.
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.
Quote from: jtimon
Why is it a mistake on the part of ripple devs to substitute inputs/outputs with GAAP?
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.
Do you mind to explain the reason? That may answer the question.
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.
That's true for both approaches.
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?
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 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?
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".
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_SigningBut 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".
Quote
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.
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. 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.
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.
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".
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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
It protects against reorganization attacks.
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?
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?
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
While the GAAP, the Generally Accepted Accounting Principles are simply unknown and totally ignored.
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
While the GAAP, the Generally Accepted Accounting Principles are simply unknown and totally ignored.
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.
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 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!
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://bitcointalksearch.org/topic/m.2375477
I have a good feeling that BitCoins will be the answer to many of the world's problems, and not just in regards to Cyprus-type bank scandals.
Here are some pictures I have of an idea I had for awhile. Basically the idea is that financial records should not lie, and there should be a common and reliable way to represent true financial information, with vastly less overhead. It's based on the idea of taking BitCoin mainstream.
https://sites.google.com/site/kmarinas86/economics/bitcoin/Satoshi per Second - Preview.jpg
**** Full Image
https://sites.google.com/site/kmarinas86/economics/bitcoin/Satoshi per Second - Header.jpg
https://sites.google.com/site/kmarinas86/economics/bitcoin/Satoshi per Second - Balancome.jpg
https://sites.google.com/site/kmarinas86/economics/bitcoin/Satoshi per Second - Menus.jpg
Of course, I imagine some people would cringe at the thought of the idea of having financial records online like that, but from the standpoint of increasing the efficiency of the financial system, reducing office overhead, wouldn't this enable us to take short work weeks and spend less time in the office? If you don't understand how I am saying that, then please speak out, and let us hear your point of view.
Background image source:
http://farm6.staticflickr.com/5299/5401765996_6175f579fa.jpg
Rapids above Toketee Falls, Umpqua Highway, Oregon by Alaskan Dude, on Flickr
- kmarinas86
Here are some pictures I have of an idea I had for awhile. Basically the idea is that financial records should not lie, and there should be a common and reliable way to represent true financial information, with vastly less overhead. It's based on the idea of taking BitCoin mainstream.
https://sites.google.com/site/kmarinas86/economics/bitcoin/Satoshi per Second - Preview.jpg
**** Full Image
https://sites.google.com/site/kmarinas86/economics/bitcoin/Satoshi per Second - Header.jpg
https://sites.google.com/site/kmarinas86/economics/bitcoin/Satoshi per Second - Balancome.jpg
https://sites.google.com/site/kmarinas86/economics/bitcoin/Satoshi per Second - Menus.jpg
Of course, I imagine some people would cringe at the thought of the idea of having financial records online like that, but from the standpoint of increasing the efficiency of the financial system, reducing office overhead, wouldn't this enable us to take short work weeks and spend less time in the office? If you don't understand how I am saying that, then please speak out, and let us hear your point of view.
Background image source:
http://farm6.staticflickr.com/5299/5401765996_6175f579fa.jpg
Rapids above Toketee Falls, Umpqua Highway, Oregon by Alaskan Dude, on Flickr
- kmarinas86
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":
Looks intriguing. You have certainly put a lot of thought and effort into making those images / mockups. Nice work.
I don't really understand how it would all work though. I put in a budget.... and then what exactly?
I don't really understand how it would all work though. I put in a budget.... and then what exactly?
In cooking, you can take a cup of flour, a tablespoon of butter, etc. of what you got. From the ingredients you have, there is a certain amount of cake you can produce.
In my proposal, we have a thing called a "Balancome statement".
https://sites.google.com/site/kmarinas86/economics/bitcoin/Satoshi%20per%20Second%20-%20Balancome.jpg
Left column: Income as SPS (Satoshis per second)
Right column: Expenses+Savings as Parts per total
In the right column of the above example, we have the following entry:
"300 parts to Mortgage (92% Good)"
"17X1ygqtjL5XBApKRC384tiYFkTfVKZArA"
"300 parts" = The amount of parts of the total incoming to be paid toward the mortgage
"Mortgage" = The label set by the user in the user's Chart of Accounts
"(92% Good)" = A measure of how much of the obligation toward the mortgage is being satisfied
"17X1ygqtjL5XBApKRC384tiYFkTfVKZArA" = The account name of the creditor to whom the mortgage is being paid
On the bottom we have a button called "Turn on Auto Balance" which will recalculate the parts allocation to each account, to reduce possible delinquency risk. Priority to each account can be set in the user's Chart of Accounts. Below the "Turn on Auto Balance" button we have an "Edit Portioning" button, which allows manual adjustment of parts share going towards each obligation.
Below is the picture of the concept navigation menu, which includes a link to "Edit Chart of Accounts". There is also a sub-menu consisting of multiple log off options including:
- Leave website
- Log into a different account
- Create a new individual account
- Create a new group account
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.
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).
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 !?
DONE. No further information is needed, as this bitcoin address is unique (only used once, exactly for the reason of P buying T).
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 !?
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.
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.
....
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.
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.
Imagine that a customer/merchant might use in any case the wrong address.
How can that be repaired?
How can that be repaired?
You are familiar with the payment protocol that is planned?
- https://bitcoinfoundation.org/blog/?p=85
Note this as well:
Quote
PaymentRequests include a user-friendly description of what the payment is for
- https://gist.github.com/gavinandresen/4120476 
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!
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!
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.
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...
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?
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?
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.
Jump to: