5 ms·

> This analysis is obviously wrong, if the important thing was establishing a global clock, you could just use GPS receivers Is it so obviously wrong? From the

by pdpi 9y ago

> This analysis is obviously wrong, if the important thing was establishing a global clock, you could just use GPS receivers Is it so obviously wrong? From the first paragraph of the introduction to Satoshi's Bitcoin Paper: "In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions". GPS is a trusted system, whereas bitcoin is designed to be completely trust-less. The reason why timestamping is a difficult problem is that if I publish two transactions spending the same money, the network must agree on the order of events (which is to say: must assign different timestamps to the two transactions) so that one is considered valid, and the other invalid. Doing this without proof-of-work leaves you vulnerable to Sybil attacks, where I can pretend to have an overwhelming amount of nodes in the consensus, and vote for the more favourable (to me) transaction to be considered the canonical one.

danbruc 9y ago
I just looked into the paper [1] for the first time but it says exactly what I wrote. Hashes in the blocks linking to previous blocks establish the ordering of transactions, proof of work limits the voting power of participants. The terminology could be somewhat more precise in distinguishing between the different components and their roles but it is still rather unambiguous about what does what. Chapter 3 - Timestamp Server A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it. Chapter 4 - Proof-of-Work The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. [1] https://bitcoin.org/bitcoin.pdf https://bitcoin.org/bitcoin.pdf
- gtrubetskoy 9y ago
  You are right that PoW does not establish order. The PoW "ticks" have a temporal order, but the way it is represented in the blockchain is cryptographically using a Merkle tree, and there is no "rule" that the real life appearance of "ticks" must match the blockchain order. Note that the paper says "_also_ solves", implying that the "representation in majority decision" part is secondary. If you think about it, the winning miner does not really get to decide anything at all, since the block has to exist before the winning SHA is found since it is the input to the SHA.
  - danbruc 9y ago
    I would argue the »also« is misplaced, that is really the only thing thing that the proof of work does. If you read the chapter, there is only an explanation how it works before the »also« but nothing else that is solved by the proof of work. And the miner does get to decide which transactions get included in the block, it creates the block, the block does not exist before.
    - gtrubetskoy 9y ago
      Think of it this way: the block is the input to SHA. When the puzzle is solved, that block happens exactly at the time the puzzle is solved, and no one cannot dispute it. There is no other way (or at least none that I can think of) to link a pile of data to a point in time. The only way you'd get this level of accuracy with a traditional clock is if you could measure/record Planck Time, which isn't possible and might never be. And if we could have Planck Time accuracy clocks, such a timestamp wouldn't come with a cryptographic proof like the PoW timestamp. Everything else is secondary, an add on. The ordering is determined be the longest chain, recorded as a Merkle tree, transactions are tied by the strength of Elliptic Curve crytpography, miners motivated by rewards, etc. But without that timestamp, none of it would work.
      - danbruc 9y ago
        Nope. You find a good hash at a specific point in time, but that is nothing special, every event happens by its very definition at a specific point in time. Committing a database transaction, potentially including finical transaction records, occurs at a specific point in time. But that is all without consequences, nobody will know about this event until you broadcast and they receive your block. And the message about the new block will arrive at different nodes at different times. End if you are really inclined to pull physics into this - which in my opinion hardly makes any sense - you have to face the fact that simultaneity is relative. So you are really not tying the discovery of the new block to any specific point in time. Everything anybody can really say is that it happened before they received the block and after the block that is referenced by the previous block hash was mined which itself may have happened any time before they first received that block. The previous block hash establishes a happened before relation between the events of creating the blocks in the chain and including a transaction in a block establishes a happened before relation between the creation of the transaction and the creation of the block. But nothing ties anything to any specific point in time. And proof of work plays no role here at all, you can simply calculate a single hash of a block and send it to me and that proofs that the block existed before I received that hash, no need to work hard to find a fancy hash with many leading zeros.
danbruc 9y ago
The reason why timestamping is a difficult problem is that if I publish two transactions spending the same money, the network must agree on the order of events (which is to say: must assign different timestamps to the two transactions) so that one is considered valid, and the other invalid. No, the system must not decide on the temporal order of your two transactions and in the extreme case, if you make them at the exact same time, it can not because neither one precedes the other one. In this specific case of an attempted double spending the system must only decide to accept at most one of your transactions and it must agree on which one gets accepted, if any. If one of the transactions gets accepted this will establish an ordering of the two transactions but this ordering is a result not an prerequisite. A miner may randomly include any one of your two transactions, if individually valid, without regard to the time it was made. The inclusion in an accepted block then renders the other transaction invalid but this is still not really judgment about the time those transaction were made at, it is just a statement that one is valid and one is invalid. Ordering is really only important insofar that you can only spend coins that you have received before, i.e. a spending transaction must not precede a receiving transaction. And even then the order in which the transactions are made does not matter. Nothing stops you from creating a spending transaction before the receiving transaction, the spending transaction will just be invalid and not get included in a block until the receiving transaction is made and included in a block.
state_less 9y ago
Couldn't we save a lot of energy and have a distributed stores of identities (public keys) with ledgers, something like a git repo per identity? Whenever I want to spend money, I just commit a changelog to my repo, I want to transfer some credit to identity X, signed with my identity (private key). I sign the ledger with my private key and commit the entry to the distributed store. Push out the changes to anyone who will listen. If you want to forget my identity and transactions, you may, but if I'm credit worthy, my identity will probably be remembered and followed. Github could remember a repo for each of us, but users of the network would want to mirror the repos, index the repos, and keep an eye out for modified histories. I imagine there are likely problem(s) with the idea, can someone explain the problem?
- danbruc 9y ago
  The problem is, where do your coins come from? Who or what is allowed to bring coins into existence and what prevents them from just creating as many as they like? The second problem is, how do you resolve conflicting transactions spending the same coins?
  - state_less 9y ago
    There wouldn't be any coins, instead double entry accounting I (pubkey:ae32...) owe (pubkey:af41...) 10 US dollars. Medium of exchange is agreed upon by the two parties, USD is one option. If you're my friend or a business, and you see my balance is deeply negative, maybe you don't give some service. If your my friend or a business, and my credit is not too bad, you follow my repo and give me some service. You commit a change that says, (pubkey:ae32...) paid (pubkey:af41...) 10 US dollars and reference my repo and commit. I don't think there could be double spending because the receiver of the money acknowledges the credit offer on record (the git repo that paid). If there are identities and entries in my ledger that are questionable, maybe you don't count them. For example, you might say credit only counts from those identities that are willing to answer a two-factor sms challenge. Or, if my git repo is credited by a google account, that's something worthwhile that could count toward my balance.
    - 9y ago

by pdpi 9y ago

danbruc 9y ago

I just looked into the paper [1] for the first time but it says exactly what I wrote. Hashes in the blocks linking to previous blocks establish the ordering of transactions, proof of work limits the voting power of participants. The terminology could be somewhat more precise in distinguishing between the different components and their roles but it is still rather unambiguous about what does what. Chapter 3 - Timestamp Server A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it. Chapter 4 - Proof-of-Work The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. [1] https://bitcoin.org/bitcoin.pdf https://bitcoin.org/bitcoin.pdf

gtrubetskoy 9y ago
You are right that PoW does not establish order. The PoW "ticks" have a temporal order, but the way it is represented in the blockchain is cryptographically using a Merkle tree, and there is no "rule" that the real life appearance of "ticks" must match the blockchain order. Note that the paper says "_also_ solves", implying that the "representation in majority decision" part is secondary. If you think about it, the winning miner does not really get to decide anything at all, since the block has to exist before the winning SHA is found since it is the input to the SHA.
- danbruc 9y ago
  I would argue the »also« is misplaced, that is really the only thing thing that the proof of work does. If you read the chapter, there is only an explanation how it works before the »also« but nothing else that is solved by the proof of work. And the miner does get to decide which transactions get included in the block, it creates the block, the block does not exist before.
  - gtrubetskoy 9y ago
    Think of it this way: the block is the input to SHA. When the puzzle is solved, that block happens exactly at the time the puzzle is solved, and no one cannot dispute it. There is no other way (or at least none that I can think of) to link a pile of data to a point in time. The only way you'd get this level of accuracy with a traditional clock is if you could measure/record Planck Time, which isn't possible and might never be. And if we could have Planck Time accuracy clocks, such a timestamp wouldn't come with a cryptographic proof like the PoW timestamp. Everything else is secondary, an add on. The ordering is determined be the longest chain, recorded as a Merkle tree, transactions are tied by the strength of Elliptic Curve crytpography, miners motivated by rewards, etc. But without that timestamp, none of it would work.
    - danbruc 9y ago
      Nope. You find a good hash at a specific point in time, but that is nothing special, every event happens by its very definition at a specific point in time. Committing a database transaction, potentially including finical transaction records, occurs at a specific point in time. But that is all without consequences, nobody will know about this event until you broadcast and they receive your block. And the message about the new block will arrive at different nodes at different times. End if you are really inclined to pull physics into this - which in my opinion hardly makes any sense - you have to face the fact that simultaneity is relative. So you are really not tying the discovery of the new block to any specific point in time. Everything anybody can really say is that it happened before they received the block and after the block that is referenced by the previous block hash was mined which itself may have happened any time before they first received that block. The previous block hash establishes a happened before relation between the events of creating the blocks in the chain and including a transaction in a block establishes a happened before relation between the creation of the transaction and the creation of the block. But nothing ties anything to any specific point in time. And proof of work plays no role here at all, you can simply calculate a single hash of a block and send it to me and that proofs that the block existed before I received that hash, no need to work hard to find a fancy hash with many leading zeros.

danbruc 9y ago

The reason why timestamping is a difficult problem is that if I publish two transactions spending the same money, the network must agree on the order of events (which is to say: must assign different timestamps to the two transactions) so that one is considered valid, and the other invalid. No, the system must not decide on the temporal order of your two transactions and in the extreme case, if you make them at the exact same time, it can not because neither one precedes the other one. In this specific case of an attempted double spending the system must only decide to accept at most one of your transactions and it must agree on which one gets accepted, if any. If one of the transactions gets accepted this will establish an ordering of the two transactions but this ordering is a result not an prerequisite. A miner may randomly include any one of your two transactions, if individually valid, without regard to the time it was made. The inclusion in an accepted block then renders the other transaction invalid but this is still not really judgment about the time those transaction were made at, it is just a statement that one is valid and one is invalid. Ordering is really only important insofar that you can only spend coins that you have received before, i.e. a spending transaction must not precede a receiving transaction. And even then the order in which the transactions are made does not matter. Nothing stops you from creating a spending transaction before the receiving transaction, the spending transaction will just be invalid and not get included in a block until the receiving transaction is made and included in a block.

state_less 9y ago

Couldn't we save a lot of energy and have a distributed stores of identities (public keys) with ledgers, something like a git repo per identity? Whenever I want to spend money, I just commit a changelog to my repo, I want to transfer some credit to identity X, signed with my identity (private key). I sign the ledger with my private key and commit the entry to the distributed store. Push out the changes to anyone who will listen. If you want to forget my identity and transactions, you may, but if I'm credit worthy, my identity will probably be remembered and followed. Github could remember a repo for each of us, but users of the network would want to mirror the repos, index the repos, and keep an eye out for modified histories. I imagine there are likely problem(s) with the idea, can someone explain the problem?

danbruc 9y ago
The problem is, where do your coins come from? Who or what is allowed to bring coins into existence and what prevents them from just creating as many as they like? The second problem is, how do you resolve conflicting transactions spending the same coins?
- state_less 9y ago
  There wouldn't be any coins, instead double entry accounting I (pubkey:ae32...) owe (pubkey:af41...) 10 US dollars. Medium of exchange is agreed upon by the two parties, USD is one option. If you're my friend or a business, and you see my balance is deeply negative, maybe you don't give some service. If your my friend or a business, and my credit is not too bad, you follow my repo and give me some service. You commit a change that says, (pubkey:ae32...) paid (pubkey:af41...) 10 US dollars and reference my repo and commit. I don't think there could be double spending because the receiver of the money acknowledges the credit offer on record (the git repo that paid). If there are identities and entries in my ledger that are questionable, maybe you don't count them. For example, you might say credit only counts from those identities that are willing to answer a two-factor sms challenge. Or, if my git repo is credited by a google account, that's something worthwhile that could count toward my balance.
  - 9y ago