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

Unexpected Ways in which Bitcoin Dodged Some Cryptographic Bullets

bitcoinmagazine.com

Post reply on HN
Print view View original

11–20 of 76 posts

Re: Unexpected Ways in which Bitcoin Dodged Some Cryptographic Bullets

#11

Post by nhaehnle »

simondlr wrote: post #9

Besides dodging bullets, it amazes me that Satoshi had the foresight to include a scripting language into the outputs of transactions, envisioning a future where contracts could be built onto the blockchain. For a proof-of-concept, Bitcoin didn't need it. It could've just supported the ability for owners of addresses to claim outputs (in a hard-coded manner).

The irony, of course, is that last time I checked, large parts of this scripting language were disabled in the official client due to security concerns.

Re: Unexpected Ways in which Bitcoin Dodged Some Cryptographic Bullets

#12

Post by oskarth »

sillysaurus2 wrote: post #3

Who created Bitcoin? This comment seems to offer many clues: https://news.ycombinator.com/item?id=5547590 There are two groups that are on the suspects list for having engendered bitcoin, one group centers around Trinity College, another is a bunch of loosely affiliated international collaborators. Both groups are on the record with precursors to bitcoin (papers, software), neither has admitted openly that they were…

> "...computationally impractical to reverse" was found in both the patent application and bitcoin's whitepaper.

That's the first time I have heard that one. If there are no other textbooks / papers / patents were this phrase is used, this seems like a pretty strong indicator to me. A search on Google Scholar for that exact phrase gives (at the time) the two expected results. http://scholar.google.com/scholar?hl=en&q=%22computationally...

Alternative hypothesis: (a) Nakamoto paid close attention to research, read the patent and liked the phrase. (b) The phrase is common lingo, but Google Scholar doesn't index it. For example, it could be used in a private mailing list. Both (a) and (b) seems like they could quite easily be investigated by someone with domain knowledge together with some knowledge of how patents are distributed.

This seems like too simplistic a reasoning. Anyone care to explain what I am missing?

EDIT: The exact phrase "computationally impractical" seems to be very common, with thousands of citations before 2008 http://scholar.google.com/scholar?q=%22computationally+impra... It seems to me that reversibility might simple have been a "theme" in crypto circles around that time, which could explain the coincidence that two different groups independently glued the phrases together.

Re: Unexpected Ways in which Bitcoin Dodged Some Cryptographic Bullets

#14

Post by rtpg »

simondlr wrote: post #9

Besides dodging bullets, it amazes me that Satoshi had the foresight to include a scripting language into the outputs of transactions, envisioning a future where contracts could be built onto the blockchain. For a proof-of-concept, Bitcoin didn't need it. It could've just supported the ability for owners of addresses to claim outputs (in a hard-coded manner).

apparently originally he wanted to make a capability for a bunch of different transactions but realized that it would be easier to just stick q scripting language in there. Another data point for the "lazy programmers are the best programmers" thesis

Re: Unexpected Ways in which Bitcoin Dodged Some Cryptographic Bullets

#15

Post by enimodas »

ploureiro wrote: post #13

"my own BitcoinJS fork (which also adds other improvements) does use plain numbers to store the number of satoshis." Why wouldn't I feel tempted to use his fork?..

my thoughts exactly. For those who don't know, never ever use floats for things like money. Try in windows calculator for example sqrt(4) - 2 and see why.

Strangely enough he talks about floating point rounding errors in one of the next paragraphs?

Re: Unexpected Ways in which Bitcoin Dodged Some Cryptographic Bullets

#17

Post by vbuterin »

enimodas wrote: post #15
ploureiro wrote: post #13

"my own BitcoinJS fork (which also adds other improvements) does use plain numbers to store the number of satoshis." Why wouldn't I feel tempted to use his fork?..

my thoughts exactly. For those who don't know, never ever use floats for things like money. Try in windows calculator for example sqrt(4) - 2 and see why. Strangely enough he talks about floating point rounding errors in one of the next paragraphs?

> For those who don't know, never ever use floats for things like money.

This is normally a very good rule to follow. The reason is that floating point is binary, whereas cash is decimal, so even an innocent number like 0.4 has no exact representation in binary (it's actually an infinite tail: 0.011001100110011...).

Here, however, I'm using floats NOT to store decimals; every single value that I store is an integer. There is absolutely no danger in using floating point numbers to store relatively small integers like 1253251126; the issue only arises in the context of very large numbers (specifically, those above 2^53) and decimals. If anyone can come up with a remotely realistic series of integer manipulations that will cause an inaccuracy in Javascript where all values always stay below 2^50.9, I will certainly abandon my choice of moving to integers at once; otherwise, I see no problem.

Re: Unexpected Ways in which Bitcoin Dodged Some Cryptographic Bullets

#18

Post by Luc »

enimodas wrote: post #15
ploureiro wrote: post #13

"my own BitcoinJS fork (which also adds other improvements) does use plain numbers to store the number of satoshis." Why wouldn't I feel tempted to use his fork?..

my thoughts exactly. For those who don't know, never ever use floats for things like money. Try in windows calculator for example sqrt(4) - 2 and see why. Strangely enough he talks about floating point rounding errors in one of the next paragraphs?

It's explained rather well in the article, over several paragraphs, why it's okay to use floating point in this case.

The first thing we did in the programming class at university was to learn how the IEEE floating point standard works...

Re: Unexpected Ways in which Bitcoin Dodged Some Cryptographic Bullets

#19

Post by nly »

Regarding the choice of the secp256k1 curve: ECDSA signature verification is fairly slow and sipa, one of the Bitcoin developers, has been developing a faster implementation[1]. If anyone has any crypto expertise and can review the code, or otherwuse can provide further optimisations or patches, I'm sure it'd be appreciated.

https://github.com/sipa/secp256k1

Re: Unexpected Ways in which Bitcoin Dodged Some Cryptographic Bullets

#20

Post by daniel-levin »

> As a result, most of the decisions that Satoshi Nakamoto made in 2008 we are essentially stuck with.

Every single time I read something about what 'Satoshi Nakamoto' did in designing, implementing and securing Bitcoin, I grow more skeptical that one person, or even a small group of people, created Bitcoin. It is very difficult to believe that something this sophisticated was developed by anyone other than a well financed, possibly nation-state backed organisation.

This article suggests that Bitcoin was made difficult or impossible to fork by-design, which implies that the creator doesn't want to allow anyone to seize control of Bitcoin.

Paradoxically, the more you learn about Bitcoin, the more mysterious it becomes. Who would go through all that trouble to create it? What can they gain from Bitcoin's existence?

Post reply on HN