Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the Bitcoin protocol actually works

michaelnielsen.org

Post reply on HN
Print view View original

11–20 of 58 posts

Re: How the Bitcoin protocol actually works

#11

Post by lsc »

javert wrote: post #4
fersho311 wrote: post #2

Absolutely love this quote from the article: "Money is like gas in the car – you need to pay attention or you’ll end up on the side of the road – but a well-lived life is not a tour of gas stations!" - Tim O'Reilly

It would be better to just be explicit. Money can be an incredibly useful thing to have, but getting happiness is a lot more complicated than just getting a lot of money.

A platitude is only interesting if the language used to convey it has some poetry to it. Otherwise it's just a platitude.

Re: How the Bitcoin protocol actually works

#12

Post by scott_karana »

diminoten wrote: post #7

The smallest of nits to pick, but Readability has issues with the "images as text" behavior of the variables and numbers in the crypto parts of the post. Otherwise, I'm very sorry that I didn't find this until after Thanksgiving. As many of you are likely similarly tagged, I'm the "computer" guy in the family, and so whenever something happens in the news that's got anything to do with computers, I'm the guy people b…

Yeah, and I find they're more difficult to read. Anyone have suggestions for a good solution, which still allows for image fallback?

Re: How the Bitcoin protocol actually works

#13

Post by sp332 »

jere wrote: post #5

Amazing post. I thought I had a pretty good understanding of Bitcoin, yet this is the first time I've even heard of an associated scripting language. I can't wait for the post detailing that. Here's the wiki article for now: https://en.bitcoin.it/wiki/Script

Someone is running a competition right now. To win, you have to find a collision using various hash functions. https://bitcointalk.org/index.php?topic=293382.0 The rules of the competition are encoded in the bitcoin transaction using Script. For example:

  OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL
which means SHA1(x) == SHA1(y) AND NOT (x == y)

Re: How the Bitcoin protocol actually works

#14

Post by bcoates »

hendzen wrote: post #6

From the article: "I don’t understand why double spending can’t be prevented in a simpler manner using two-phase commit. What drawbacks and advantages does it have compared to the full Bitcoin protocol? uppose Alice tries to double spend an infocoin with both Bob and Charlie. The idea is that Bob and Charlie would each broadcast their respective messages to the Infocoin network, along with a request: “Should I accept…

I don't think this exactly right -- an evil node can't send a false nay because it would have to be able to forge the conflicting transaction, the signature prevents that.

Bitcoin already essentially does the 2PC that the author is asking about for unconfirmed transactions. The problem being solved is that the Byzantine Generals problem is unsolvable for anonymous actors, as a malicious participant can create a majority of evil voters, winning any dispute resolution by 'Sybil attack'.

The proof of work system allows a newly joined node to determine the current consensus even when it's disputed, without having any idea who is on the network, so long as it has at least one link to the true hashing-power consensus. It also acts as a commitment protocol -- once you've signed your winning block to the network, it's nonrepudiable even by you.

With an alternate source of identification, a pseudo-anonymous 'Infocoin' ledger should be able to function and scale just fine without all the PoW expenditure--or in other words, you must have a system of making identities expensive, and Bitcoin's is Proof of Work.

Re: How the Bitcoin protocol actually works

#15

Post by gus_massa »

diminoten wrote: post #10

> Of course, any still-pending transactions in A will still be pending in the queues of the miners working on fork B, and so all transactions will eventually be validated. I don't understand this. So you have fork A and fork B, and once fork B wins, what happens to the transactions being done on fork A? Discarded? Do transactions sometimes not ever get verified? From what I've quoted, I'm guessing no, transactions in…

The non incompatible transactions will be present in both forks, and they will get validated and fixed whatever fork wins. This includes most of the transactions that are not related to the double spending.

In the case of a double spending, each transaction can live in only one of the forks, and the decedents [1] transactions can be validated only in the same fork. When a fork wins, all the transactions that are incompatible can’t be added and they disappear.

[1] Sopuse that X sends the same bitcoins to A and B. Then A send these bitcoins to A1, that sends these bitcoins to A2. During the same time B send these bitcoins to B1, that sends these bitcoins to B2. Then you have two forks, one with the A, A1 and A2 transactions and another with the B, B1 and B2 transactions. Only these transactions have problems and one half of them will disappear, all the other transactions will apear in both forks.

Re: How the Bitcoin protocol actually works

#16

Post by Anderkent »

rallison wrote: post #8

Great article. There is a lot in the bitcoin protocol that is possible that the vast majority of people have never heard of, some of which this article touches on. For an idea of some of what could be done, see the Contracts section on the bitcoin wiki: https://en.bitcoin.it/wiki/Contracts In the near future, we may start to see things like multi signature transactions* and the like. In theory, it could open up some…

There's even a web service for easy multisig: https://www.bitrated.com/

Re: How the Bitcoin protocol actually works

#17

Post by maaku »

michael_nielsen wrote: post #9
hendzen wrote: post #6

From the article: "I don’t understand why double spending can’t be prevented in a simpler manner using two-phase commit. What drawbacks and advantages does it have compared to the full Bitcoin protocol? uppose Alice tries to double spend an infocoin with both Bob and Charlie. The idea is that Bob and Charlie would each broadcast their respective messages to the Infocoin network, along with a request: “Should I accept…

Original post author here. Thanks -- your comment pretty much nails the answer to my question. Edit: A problem with this is that it would be necessary for a naysayer to exhibit the other transaction (proof of double spending). But they couldn't forge such a transaction, since they don't have the private key necessary to generate the signature. So I'm still a bit puzzled by this. Edit 2: And it appears that bcoates is…

Btw, Ripple is basically a two-phase commit protocol. The problem is trust - ripple has basically decided to trust a centralized list of nodes, whereas bitcoin does not require this trust.

Re: How the Bitcoin protocol actually works

#18

Post by maaku »

> Early in the section I mentioned that there is a natural way of reducing the variance in time required to validate a block of transactions. If that variance is reduced too much, then it creates an interesting attack possibility...

You've described a 51% attack. The security model of bitcoin assumes these are economically infeasible to mount.

> Suppose Bitcoin mining software always explored nonces starting with x = 0, then x = 1, x = 2,\ldots. If this is done by all (or even just a substantial fraction) of Bitcoin miners then it creates a vulnerability. Namely, it’s possible for someone to improve their odds of solving the proof-of-work merely by starting with some other (much larger) nonce...

No, this does not improve their odds. No miners are scanning the same ranges, because the block header is different for each miner (due to different coinbase transactions and timestamps, if for no other reason).

Post reply on HN