Bitcoin Forum
May 09, 2024, 09:51:22 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3] 4 5 6 7 »  All
  Print  
Author Topic: BTC violates GAAP, result a mess.  (Read 13691 times)
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 01, 2013, 05:54:47 AM
 #41

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


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
1715248282
Hero Member
*
Offline Offline

Posts: 1715248282

View Profile Personal Message (Offline)

Ignore
1715248282
Reply with quote  #2

1715248282
Report to moderator
1715248282
Hero Member
*
Offline Offline

Posts: 1715248282

View Profile Personal Message (Offline)

Ignore
1715248282
Reply with quote  #2

1715248282
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
LvM (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 01, 2013, 10:03:53 AM
Last edit: June 01, 2013, 10:19:46 AM by LvM
 #42

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

aaaxn:
Quote
Duplicate same data twice?  Stupid.
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..

Quote
Using timestamps in distributed network?

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

Quote
Foreign currency account without any way to link them to real world accounts?
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?

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 01, 2013, 10:48:11 AM
 #43

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..
You can have only one and always derive other from it. Storing it twice is a waste.

Quote
Using timestamps in distributed network?

Yes. Same as in the present blocks. Where is the problem?
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.

Quote
Foreign currency account without any way to link them to real world accounts?
Yes. With a link to "normal" banks, of course. Would be just a nice additional feature.
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.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
LvM (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 01, 2013, 11:58:28 AM
 #44

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..
You can have only one and always derive other from it.

"One"? Of what Huh

Before we continue. I wrote and must ask you again:
Quote
Payer and receiver have an account.

Both are changed by the payment differently. Right?

Would you really deny that?

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
behindtext
Full Member
***
Offline Offline

Activity: 121
Merit: 103


View Profile WWW
June 01, 2013, 01:29:19 PM
 #45

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.

kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1025



View Profile
June 01, 2013, 01:53:35 PM
 #46

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

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

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.
Reality check:
Security, yes (including potential for denial-of-service attacks of various sorts).

But demonstrate a spiffy, compelling use of new opcodes on testnet and we'll talk about making them standard.

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

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
LvM (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 01, 2013, 02:10:23 PM
 #47


all the usual niceties of double entry accounting can be applied to BTC as they would any other currency.

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

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 01, 2013, 07:00:51 PM
 #48

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".
Yes, it prevents replaying. Don't keep us from your wisdom. Say why such efficient txs are not "useful" and why are "centralized"
Yup, a pony is an immature horse.  Still more useful than a pegasus.
No. It is thing that has all requirements of pegasus but only pony features.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
LvM (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 01, 2013, 09:17:20 PM
 #49

Dear OP please listen to this interview about GAAP

http://www.youtube.com/watch?v=RtvTOJISXKg

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 Cheesy 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/

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
LvM (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 01, 2013, 09:20:09 PM
 #50

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



BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
LvM (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 01, 2013, 09:21:38 PM
 #51

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.

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
galambo
Sr. Member
****
Offline Offline

Activity: 966
Merit: 311



View Profile
June 01, 2013, 10:54:26 PM
 #52

Oh, certainly LvM. I haven't ignored anyone on this forum until today.
bfever
Jr. Member
*
Offline Offline

Activity: 39
Merit: 1


View Profile WWW
June 01, 2013, 10:58:34 PM
 #53

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.

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.

...

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.

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

kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1025



View Profile
June 02, 2013, 01:30:57 AM
 #54

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".
Yes, it prevents replaying. Don't keep us from your wisdom. Say why such efficient txs are not "useful" and why are "centralized"
Yup, a pony is an immature horse.  Still more useful than a pegasus.
No. It is thing that has all requirements of pegasus but only pony features.

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"

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 02, 2013, 06:55:22 AM
Last edit: June 02, 2013, 07:30:56 AM by aaaxn
 #55

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.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
maaku
Legendary
*
expert
Offline Offline

Activity: 905
Merit: 1011


View Profile
June 02, 2013, 07:02:09 AM
Last edit: June 02, 2013, 07:13:01 AM by maaku
 #56

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

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

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 02, 2013, 07:07:19 AM
 #57

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


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 02, 2013, 07:27:52 AM
Last edit: June 02, 2013, 12:02:49 PM by aaaxn
 #58

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


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
maaku
Legendary
*
expert
Offline Offline

Activity: 905
Merit: 1011


View Profile
June 02, 2013, 04:18:29 PM
 #59

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

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

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 02, 2013, 05:28:27 PM
 #60

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


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
Pages: « 1 2 [3] 4 5 6 7 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!