Hm, PGP signatures are a good idea. I'd still use the numbers from an already established system though, so you needn't bother with generating the numbers yourself. Coincidentally that'd also prevent you from cheating.

Speaking of which, what prevents you from just buying ten thousand tickets for yourself at no cost? ;-)

Yeah, I had the same problem.

BtW: If you look at the makefile, sha.{h,cpp} are already compiled -O3; using a higher optimization level for the remainder of the program is probably not going to help much.

Here's the German translation for the client.

It may require some modification, because, on average, German sentences are a third longer than English ones and thus may not fit the available space. Also, I couldn't test the access keys (e.g. E&xit) properly, so I may have introduced collisions there...

How would the attacker get hold of a valid certificate that claims it's for www.somewebsite.com without actually controlling said domain?


Not necessarily. StartCom, for example, is recognized as a valid CA by almost anyone (Opera being the exception). CACert ist also included in popular Linux distributions (e.g. Debian).


Ehm. DNSSEC _is_ a standard, and the root servers and many TLDs are already using it, although it will only become fully functional later this year. It's true that it is not as efficient as it could be (and was rightly criticized thus by people like Daniel J. Bernstein), but with .com, .net and .org adopting it within the next year or two, I'd pretty much say it's a done deal.


Well, I was working with the premise of IP payment, because that's what you brought up in the snippet I replied to with that paragraph. Of course you can just use a Bitcoin address (unless the payee wants you to pay DCC-style...)


^^

The thing with security is that you have to be aware of what _could_ happen. I don't walk around with 1000$ in my wallet, precisely because it could be stolen, for example. If Bitcoin becomes an accepted currency, attacks *will* happen -- just think of all the phishing that's going on with Paypal and normal banks. If there's a way, it will be exploited by criminals.

I'm by no means an expert on this, but I think even a free certificate includes a "this is for website www.example.com"-field, and you can only get a certificate if you actually control that domain (can receive email sent to the domain), so I don't think forging that is trivial. Firefox, for example, explicitly pops up a warning if a certificate is for a domain other than the expected one.

The remaining weak link then is DNS, but while possible, it is non-trivial to forge that, especially when you're watching the destination-page, and can't know who is going to want to visit it beforehand. Also, DNSSEC is slowly becoming the norm, so that possibility also goes out of the window within a few years.

The reason why I bring up TOR is that bitcoin complements it very well. TOR preserves anonymity, and bitcoin allows for anonymous transactions.


Suppose someone doesn't want to know the payee who he/she is? Without TOR the IP address is revealed, which, at the very least allows the other party to know the approximate geographical location.

Actually, gavinandresen raised a very good point here. For example, when browsing over TOR, a malicious exit node could indeed replace bitcoin addresses very easily. Contrary to what you said, SSL would fix the issues raised, because when the content is hidden, the attacker can't even know whether there is a bitcoin address on the requested page at all, much less replace it. Spoofing DNS would also be detected because the certificate wouldn't be valid (unless the attacker managed to spoof an SSL certificate, which is still very very difficult).

The thing to note here, though, is that the bitcoin client itself can't do anything about all of this, only the websites that use Bitcoin can -- and, for example, bitcoinmarket and bitcoinexchange already do.

I think he meant that you could replace the $-signs with ฿-signs. That's the currency-symbol the community adopted for bitcoin. I think it's using Unicode though, and the website does not declare the required content encoding currently. Changing that could be as simple as adding a <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> header, but it might be more difficult if the database depends on the encoding somehow.

I'm done with the FAQ, it's attached to this post. I've also attached the front_page again, because the "Advantages:" before the list of bullet points needed to be in its own paragraph (I assume from the structure of the files that three blank lines serve as paragraph-break in whatever  CMS is used for the homepage).
 
I'll also take a look at the .po-file, but it'll probably take a few days.

It's good that someone is thinking along the lines of how security/anonymity could be compromised.

Yes, you know both sender and recipient of a payment. The recipient's key is always included, and from there you can trace the coin back to the previous recipient, i.e. the current sender.

My 2฿ worth of thoughts:

Ideally the Bitcoin wallet should be encrypted, and future versions will implement that. Now, leaving malware out of the picture (which would probably just send all bitcoins to the hacker in question instead of tracing transactions back), when both your computer is confiscated and you are forced to reveal the password, you're probably already in big trouble... you'd have to already have screwed up other than by using bitcoin in an unsafe manner. Personally I don't worry about this, but it is good that somebody does.

As an aside: Bitcoin can be used over the TOR network, so one can hide one's IP address. There are also the web-based wallet services, which might make it harder to trace a transaction that went through them. On the other hand, they could do some tracing of their own... The deciding factor here is which coins are chosen for which transactions.

As for coin lineage, yeah, that might be a problem. Currently it is a best practice to give out a different address to every sender, and only give it to them. An outside observer you can't know if the next recipient (or rather crypographic key) the coin is sent to is one of your aliases or someone else entirely. Bitcoin Currency Exchanges (or any high-volume user) might be a problem here, but otherwise one probably doesn't have enough data to infer much about the transfers, it just becomes untractable if every person has a lot of different addresses. One additional point here is that old transactions expire after a while, and the space is reclaimed -- that wouldn't stop a serious attacker, but it's helping a little.

My pleasure.

I've fixed the problems SmokeTooMuch mentioned (thanks!) in the attached version. I also should have the FAQ translated soonish (first draft is done).

We also might want to update the numbers. Even though the FAQ explicitly states that it dates back to October 2009, claiming 500 generated Bitcoins per day as achievable amount might give rise to disappointment.

Even though I've started using Google's Tools now, it would probably be a good idea to put all of this under version control. That'd also make it easier to see when the original page changes and you need to update the translation. I especially like how http://whygitisbetterthanx.com/ does it -- with one branch per language in a git repository (see bottom of page).

Edit: Bitcoin front page is done. Would be good if someone else could proof-read it though. SmokeTooMuch?

Eh, me too... this post finally got me started, actually. I'm using Google's Translation Toolkit, so if you want in on the fun, PM me with your Google account name, and I'll invite you to contribute to or comment on the translation.

Hi!

It appears that bitcoin was mentioned in a (semi-)notable publication for the first time (as far as Google would tell me): Open source innovation on the cutting edge (InfoWorld). I don't think they really conveyed how the system works, but I think it's another sign that Bitcoin is gaining traction.

Congratz, Satoshi! 

Erm. I don't think this is a good idea. If someone wants to chat about Bitcoin on IRC s/he can just fire up a normal IRC client and visist the Bitcoin channel on freenode: irc://chat.freenode.net/bitcoin (Edit: Apparently the Forum doesn't like non-http URLs...)

Can I just butt in with a question on why that is? To me it seems that if Bitcoin uses public-key cryptography to transfer ownership of the coins, it should be a trivial matter to include a short message that is only readable by the recipient.

Yep, your understanding here is correct. It does not matter what exactly gets hashed, and no, you can't cheat without first breaking SHA-256, which is considered difficult.

The salient property of cryptographic hash functions is that they are as random as is possible while still being deterministic. That's what their strength depends on -- after all if they weren't random, if there were obvious patterns, they could be broken that way. So the ideal hash function behaves just like a random number generator. It does not matter what you feed in, timestamp or not, whatever's put in there, the hash should still behave randomly (i.e. every possible outcome has the same a-priori probability of occuring). Incrementing by one works just as well as completely changing everything every step (this follows from the avalanche property). However, the initial value, before you start incrementing, must be (pseudo-)randomly chosen, or every computer will start at the same point, and the fastest one always wins, which is not what is wanted here.

Hi! Welcome aboard!

Have you read the FAQ yet? Among other things it has a link to the Bitcoin whitepaper. The minutiae of the protocol and inner workings are, unfortunately, only "documented" in the form of the application's source code.

The basic idea is that coins are signed cryptographically, so you can only spend coins you actually own. To spend a coin you sign it over to someone else using their public key -- the address is a signature of that key and serves to identify it.

To prevent you from making a copy of a coin and spend it twice, the clients form a P2P network that records which coins have already been spent in a long chain that is linked by hashes (see the paper). The IRC channel merely is a relatively simple way to get the IP addresses of a few other participants, so you can join the network.

Apart from recording all transactions, the hash-chain also serves as a sort of distributed clock that makes sure you can't alter past transactions or create many new, bogus ones to DoS the system. To make a new block valid, the clients have to twiddle a nonce inside a block until the block's SHA-256 hash is below a target number. The target number is adjusted about once every two weeks to adapt the difficulty of generating a valid block to the computing power of the network -- basically this ensures that a valid block of transactions is generated about six times per hour, no matter how many or few people are participating.

Karmicaids, thanks for taking the time for such a detailed reply.


Oh, I thought you meant that when you spoke of using freenet. The user runs freenet and Bitcoin would communicate with it using its control protocol. However, running Freenet requires considerable computer resources, especially bandwidth, and personally, I do not want to run a freenet node for that reason alone. That's why I wanted this to be optional.


I had the impression that you did not want to re-invent the wheel, and that's why popularity played a part -- that the existing acceptance of magnet links in other software was a plus.


Okay, sorry, seems I haven't made entirely clear what I mean here. I'm aware of how magnet links refer to content, rather than a location in a hierachical namespace.

Perhaps it's just a difference of mental models: For me, a bitcoin transaction is, for lack of better words, not a thing so much as a process. In my mind, magnet links refer to things (usually a file -- whether by content hash or by location), and trying to use them to refer to a process strikes me as a little awkward. Magnet links identify things you then have to go fetch, while a bitcoin transaction is completely described by the link itself (although you still have to say "Yes, send the coins." once you click the link).

To me it seems that using magnet links would be to (ab)use them for something they were not meant to describe, as they orignated as a replacement for ed2k://, freenet://, et al., describing how to get a file.

A bitcoin-link should be more like mailto: than magnet: IMHO.


Yeah, my mistake, sorry.


IIRC the web server is pretty much integrated into Freenet itself. You can use the simpler FCP protocol to talk to a Freenet instance, but because of the type of content on Freenet, not many people are willing to host a publicly accessible instance, so you would have to run your own. I don't begrudge that you want to be able to do this, I'm just not willing to do it myself. I'd much rather host a TOR hidden service -- that's why I suggested to use a general, full-featured URL as the details parameter, instead of making it freenet specific.


Well, yeah, I meant the bitcoin signature. I called it address, because that's what it says in the bitcoin client (i.e. "Change your address"). I indeed thought that one should use different aliases, just like the exchange sites currently do: You get an address (or signature, or whatever) to send coins to, and because that address was only given to you, the recipient knows the payment is from you.

A system to translate aliases would of course be nice, but I think that's better handled with an address book or mybitcoin.com or something.


Yes, exactly! The text for the sending party can use the normal route. But what if I want to pre-specify the text that should be sent?

This has an analogue in mailto:-links: If you want someone to send you an email, you can also specify a subject he/she should use: mailto:alice@example.org?subject=Test. So if I am selling something on, say, ebay, I can give the buyer a bitcoin link that includes the message "Payment for Ebay auction #12345", so he/she does not have to enter it themselves, possibly making a mistake if the code is more cryptic than #12345.


Sorry, I mistakenly tend to use the terms URI, URL, etc. interchangeably because you enter it into the address bar %). Again, sorry if this lead to confusion.

What I wanted here was to make this additional information general. Some examples might clarify this:

• https://www.myonlineshop.com/purchaseDetails/123456
• http://pastie.org/942292
• freenet://[a ressource on freenet]/
• http://kpvz7ki2v5agwt35.onion/wiki/index.php/PurchaseDetailsHere
• magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C

The creator of the link chooses where to put the additional details, and the recipient decides whether he needs the supplemental information badly enough to install Freenet/Tor/I2P. That's one of the reasons for including a short message in the link itself: the additional information should not be critical to the transaction.


But wouldn't that make the use of Freenet mandatory? I would like this to stay more flexible.

Also, if I were to run an online shop, I'd rather have people look the details up on my own website rather than them having to install freenet. That might also link my shop's reputation with Freenet, which given Freenet's reputation, might be undesirable.


Yup. That's another reason for wanting to also allow normal HTTP(S) URLs. If I have not misunderstood, you seem to want to make the use of Freenet for transactions mandatory, which is something I strongly disagree with.


Not every single transaction needs bulletproof anonymity. Think Open Source projects receiving donations, or online shops. If you (a) need more details than the short message parameter provides, and (b) you want to be totally anonymous, you can just specify a freenet or Tor or I2P-URL (or URN? -- this is confusing :-/ ). If you don't need the added anonymity, you don't have to make the effort to run Freenet/Tor/I2P/whatever.


Well, we're all together in this. I just hope to arrive at the best possible system. :-)

Thank you for your thorough explanation, and patience with my suggestions.

I think that using magnet-links just because they are already somewhat popular does not outweigh the disadvantages. Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.). Bitcoin would have to rely on application-specific xBitcoin-parameter(s), and since we probably don't want to mix files with bitcoin transactions in a single link, there's no really compelling reason not to use our own, seperate format, especially since magnet-links aren't officially recognized either.


Woah! Going from a lightweight URL-handler that brings up the Bitcoin client to requiring Freenet is a bit of a leap. This really should be optional.

However, it really would be very nice to add additional information to a transaction. Building on ec's initial post, and the need for further details, I think we should have the following url parameters (or shorter versions of them):

• address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.
• amount (optional): The amount to send.
• message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)
• details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.

Hi all.

This may be a stupid idea, and if it's not stupid, may not be viable for the next few years, but I thought I'd toss it out there anywhere:

What about Multicasting?

IPv6 is supposed to have better multicasting support than IPv4, and if I did not misunderstand the Bitcoin protocol, most messages need to be broadcasted to the entire network. Theoretically a node could send such messages to a global multicast address, and everyone will receive it in a bandwith-efficient way.

That would make bootstrapping in the traditional sense obsolete, since the client would just have to subscribe to the multicast channel. The remaining "Give me block xyz" requests could be handled by optionally including a field in messages to the multicast channel that basically says "My address is 2001:db8::42, and I'm willing to answer direct queries for specific blocks". After listening to the channel for a while, such a packet should come around, because, at the very least, new blocks will be announced there every so often.