I'm about to reply to your PM as well, but just to make one thing very clear, I don't think you need to apologize here. If it was a mistake, I'm glad that you are helping to clear up my name, but in the big picture I'm grateful that you're putting in the time to do this research in the first place. The only thing that would tie this whole mess up properly is if somebody finds Tom Williams.

As I said, because of the fact that we used the same hosting, I can't fault people for seeing a connection.

So the apology is accepted and I very much respect how you handled the whole thing. Please don't let this incident discourage you from investigating me or anybody else.

I don't understand the connection? I started WeUseCoins and I've never heard of frank@root66.org.


According to our AddThis share widget 5262 people tweeted about weusecoins.com. Twitter search shows you only the latest tweets (note they're all from last week). I tweeted about it here and here.


Not sure if this has been pointed out already, but WeUseCoins is hosted at Leaseweb, so yeah. It is one of the largest hosting providers in Europe, but still I can't really fault anybody for drawing a connection on that point.

My journey into Bitcoin is somewhat documented from IRC chats in December 2010 and early 2011. And also by the fact that at the first Swiss Bitcoin meetup in early February 2011 I didn't really know a lot about Bitcoin yet, which the other attendees Mike Hearn, cdecker and bitdragon can probably confirm. MyBitcoin has been around far longer than I've been into Bitcoin, but of course it's hard to prove a negative that I didn't know about Bitcoin longer.

I'm only following the forums occasionally, so if anybody has any questions, Phinnaeus was kind enough to post my email address already , but here it is again: moon@justmoon.de

The main point of the article is that if the server sent you the JavaScript, you're already trusting the server, so you might as well do the crypto stuff server side and use SSL for transmission.

Browser-based crypto is by no means our end goal, but rather a stepping stone. Here are some of the things I am working on or predicting:

Downloadable bundles. There is no reason you can't take the HTML/JS from bitcoinjs-gui, package it up as an AIR or xulrunner app and have people download and install it. It would then have the same properties as regular Bitcoin with respect to software delivery.

Software security device. If you have more than a few bitcents you can install a piece of software that moves your keys and the crypto outside of the browser. If you initiate a transaction within Webcoin or another client, the locally installed software will pop up a window showing the details of the transaction pending your final confirmation.

Building a dedicated software security device will also pave the way for:

Hardware security device. For even larger amounts no measure of software security will be sufficient. A hardware device with a display and internal signing would definitely by a major step forward.

Split key signing. Half your key is on your device, the other half is at a wallet hosting service. The service could offer any kind of verification you want: Yubikey, SMS, phone call, whatever. You'd probably set a daily limit. Under the limit you don't need any special verification. Note that you could have both keys as physical backups, so you wouldn't be dependent on the hosting service if they decide to randomly disappear one day.

Also I want to point out that the only part of BitcoinJS that this criticism affects at all is Webcoin. I know some folks are working on various native clients that use our server APIs, but could be implemented in Java, Objective-C, C#, etc.

A lot of people complained about the video/audio quality for my NY Bitcoin Conference talk, so I thought I'd post... another talk in horrible audio quality.

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

This was given before the Bitcoin Conference and is basically a longer version of the talk that I gave in New York. There is a bit of everything, from very basic Q&A about Bitcoin itself to some pretty advanced tips about developing servers with Node.js. The audience were mostly web developers and people were asking questions at several points throughout the talk.

To be completely honest, given the audio and the length, it's probably not going to be for everybody. I'd only recommend this if you're a card-carrying Node.js fan.

Meetup war super, die Streetparade hat gar nicht gestört, sondern eher noch geholfen (einer der Teilnehmer des Meetups hat seine Frau solange dort abgegeben ). War glaube ich das größte bisher mit 7 Leuten. Das nächste Meetup ist Ende September in Genf (genaues Datum wird noch bekannt gegeben), das nächste in Zürich dann im Oktober.

I believe "Just business." is the libertarian position.

lol, my reasoning exactly.

Well, after the talk was when the main surge in media interest for Bitcoin happened, so I was pretty busy answering emails and attending some other events. I also lost 7000 coins at that time. And that caused me to focus on BitcoinJS. Long story short - the video (36 GBs worth of HDV) is still sitting on my computer waiting to be cut.

FWIW here are the slides: http://www.slideshare.net/weusecoins/what-is-bitcoin-may-2011

To be honest, this talk wasn't my favorite. It was my first talk about Bitcoin and I think I got better over time. Also it's pretty basic/introductory. So my suggestion would be to wait for the video of my August ISSS/Webtuesday talk to come out. I had a really good time during that one. Plus, they did a recording and promised to upload it, so I don't have to do anything. 

Well, if he didn't sleep or slept irregularly then the post counts in the dip shouldn't be zero.


It's possible I guess - that would put him in Europe/Africa. But my problem with that theory is that there are weekends, so it would mean that even on weekends, he never, ever posts in the morning.


Yeah, me too.

There are a lot of possibilities, but we can say that since there are times where he never posts and times where he posts a lot, that he has a surprisingly stable daily schedule (for a geek). The most likely explanation for such consistency to me seems to be that those dips are when he sleeps.

Anyway, I just did this for own amusement, so feel free to interpret the data any way you like.

A long time ago I did a quick survey of Satoshi's posts just for fun and found that he seemed to be posting with a US time zone.

Here is the graph (X axis are hours, Y axis is posts, times are GMT):



And the data itself:

[[0,32],[1,23],[2,15],[3,10],[4,9],[5,3],[6,3],[7,0],[8,0],[9,1],[10,0],[11,0],[12,3],[13,5],[14,14],[15,18],[16,46],[17,65],[18,65],[19,43],[20,42],[21,55],[22,46],[23,42]]

As you can see the night dip is between 6-11am GMT, so assuming this person sleeps at night, he should live in GMT-5 to GMT-7 somewhere which is the Americas.

Anyway, this was just a quick fun thing I did way back when. The reason I'm posting it now is that somebody dug up my IRC logs where I promised that I'd post it on the forums.

A few people have asked about the impact of the street parade on the meetup. It's actually kind of hard to predict - the pub is located just a few blocks from the route, so it might be more crowded because of the parade, or it might be less crowded, because everyone is out on the streets. In any event, it looks like we'll only be about 5-6 people so hopefully we'll be able to squeeze in somewhere.

If things get too crazy I suppose we could always fall back on S3052's plan and just go rave instead. 

No. Bitcoin currently requires an exclusive lock on the database.

Kurzer Verweis auf das englische Forum wo ich eben den nächsten Züricher Meetup angekündigt habe:

https://bitcointalk.org/index.php?topic=35224.0

Wer sein Kommen ankündigen will oder sonst einen Kommentar abgeben tut dies bitte im o.g. Thread! Danke!

It's time for another meetup! Just to make sure y'all are still alive!

When: Saturday, August 13th, 2011 at 4:30pm
Where: Oliver Twist pub in Zurich

Special Guest: Mike has got one of his Google colleagues flying in all the way from Mountain View, CA!

Today we hit block 140000 meaning more than a third of all Bitcoins have now been issued and some of them have already gained fame or infamy. But better solutions for storing and protecting wallets are coming out all the time and the Bitcoin ecosystem is evolving quickly. Let's talk about the latest trends and catch up on what this summer brought for Bitcoin!

I also want to use this chance to plug my BitcoinJS/Webcoin talk at Webtuesday this Tuesday, 9th August 2011 at 7:30pm. This is also in Zurich and it'll be in English. More info on webtuesday.ch.

That's what Webcoin is. (server-side node, client-side crypto/wallet)


Basically true, but there are remedies. Also, it's not as bad as having your data on the server. If the server turned evil, they could only steal from people as they logged in. Anybody could monitor them (by looking at changes in the code they send out) and blow the whistle before they can steal from a majority of their customers (most users don't log in all that often.)

Anybody with HTTPS webspace can also host the actual JS application themselves. Then they only have to trust their own server security. You could even make a self-contained package containing a simple webserver that just serves the app locally.

Obviously, that's still not a satisfactory solution for mainstream users. So in the future, we envision using an authenticator. This could be a software authenticator or a hardware authenticator. The authenticator would be where the actual cryptography takes place and the browser based application only is responsible for the managing the wallet data. It would send the final, serialized transaction to the authenticator for signing. The authenticator would have a separate window pop up (in the software case) or a display with yes/no buttons (in the hardware case). It would parse the actual transaction as serialized for signing and display exactly what the signature would allow (Bitcoin has things like blank checks, so it would be a bit of a challenge to allow maximum flexibility while still making sure the authenticator "understands" what he's signing.)

Both authenticators could offer the same standardized protocol, which could be supported by any kind of client.



Someone implemented this for their own webservice cryp.sr: https://github.com/cortesi/apphash

I don't like the approach too much. Browsers are extremely complex software, so I don't see how this type of hashing could possibly be secure. Anything that allows the injection of some JavaScript would completely break the security. And if you're going to have to install some extra piece of software anyway, you might as well go the authenticator route, which is much cleaner because it also protects against all kinds of accidental spending, UI failures and other bugs in the (validated) software.

Yep, you're correct. I'll update my posts to use SHA-256 with HMAC, which is used as a PRF in IPSec, TLS, DKSPP, etc.

Good point, I should have been more specific. So here is the chain variation in detail.

Let s_n be the second part of the private key which the merchant's webserver generates.

The private and public keys are therefore:

b_n = a + s_n
B_n = A + s_n*G

The first hash s₀ is generated by the wallet as follows:

s₀ = SHA256(a i C)

i ... A 64-bit integer (LE) that starts at 0 and is incremented if the same wallet is used for more than one chain.
C ... Some constant, e.g. "BITCOIN_CHAINHASHSEED_gZ5hA5S7237RoJ" - this is the same globally for everybody.

The merchant then takes s₀, i and A and inputs them as settings on his webserver. The server initializes the transaction serial number n as 0. It is now ready to accept orders.

A user wants to do an order and pay in Bitcoins. The merchant server now runs through the following steps:

1. Increment n.

2. Generate new s_n:

s_n = SHA256(s_n-1 n C)

n ... The current serial number as a 64-bit integer (LE).
C ... Another constant, e.g. "BITCOIN_CHAINHASH_2bIyLHNXlHe77u" - this is the same globally for everybody.

3. Derive the public key B_n:

B_n = A + s_n*G

4. Create, output and store the Bitcoin address corresponding to B_n.

5. Securely delete s_n-1.

Note that storing the address in step 4 depends heavily on the specific use case. Here are a few examples:

(A) The server stores the address until the payment arrives and then sends the details of the order via email to the merchant at which point it deletes its own stored information about the order.

(B) The server doesn't store the address in plain text, but instead encrypts it with a public key and stores it like that. Every day the orders are downloaded, decrypted and processed on an offline system.

(C) The server stores the address until the payment arrives, then enables the user's account to access the digital content he/she has purchased. After that the server encrypts the address and other information related to the transaction with a public key and stores it for archival.

Implementation-wise we would probably wrap the chainhash stuff in a library that takes A as a configuration value and s₀ and n as initialization values and just spits out new addresses on demand. It would also provide utility functions to write data to the metadata storage like setDescription(chainSerial, transactionSerial, description). This information could be submitted to the wallet metadata using asymmetric encryption and later be retrieved by the wallet software and displayed in the list of transactions - similar to Bitcoin's address book feature.


Hmm, I don't think that attack is possible - or I haven't understood it correctly. My chain consists of private information only. Having the public key and the serial number would not enable you to predict the next address. Curiously, even breaking ECC and finding out any number of b_n wouldn't give you access to s_n, because you'd still only have sums a + s_n with no way to solve for a.

More realistically, breaking into the server you could compromise the current s_n and the current serial number n, which would tell you how many transactions have taken place as well as predict any future addresses - both with respect to this specific chain. It would not allow you, however, to find out any of the previous addresses unless that information is still stored on the server in some other fashion.

Caveat: The chain serial i increases the dimensionality of the address space. If all metadata of the wallet is lost and we want to recover our money based on only the private master key a, we have to in theory try every n for every i. In practice, the user will likely have a small number of chains per wallet and/or know roughly how many he/she has. So the search would be limited to very small values for i. Given that a total loss of metadata is a worst case scenario and other types of backup are likely being used as well, a certain amount of computational work for the recovery procedure seems acceptable.

With Webcoin specifically we hope to eventually store the encrypted metadata in a DHT. At that point the deterministic wallet concept serves two goals: (1) Reducing the amount of data that needs to be stored (a serial number like i and n could be stored as a var_int, 1 to 9 bytes, compared to a private key (32 bytes) or even a public key (65 bytes)) and (2) Providing a "last resort" recovery mechanism if all else fails - namely by scanning for unspent outputs using the private master key.

Quick announcement: In collaboration with SearchBitcoin, the first Bitcoin search engine, we have just upgraded our Getting Started page.

Check it out! (under "What to do with my Bitcoins?")

We want to thank SearchBitcoin for the excellent support in making the integration happen and hope that it will help new users get a first impression of the incredible diversity of products available through Bitcoin merchants.

Merchants! Remember you can add your own store to the database! Or if you're in there and want out, you can request removal.

Webmasters! Pimp out your own Bitcoin-related site with the official SearchBitcoin Plugins.

And just like that.. Bitcoin keeps growing and getting better. 

http://www.weusecoins.com/ - @weusecoins
http://www.searchbitcoin.com/ - @searchbitcoin

Actually, my post specifically mentions this use case:



You don't need a seed to generate addresses securely. Knowledge of A is enough to generate addresses and you don't need to have the master private key at all.

The only problem is that if the hacker has A, he knows all your addresses, so while he can't spend your money, he can see all your blockchain activity. If you extend your seed concept a bit you could use a changing seed, so that an attack would only compromise the current seed.

Going one step further, I've recently been thinking about using a hashing chain. I.e. the hashes no longer depend on A, but instead depend on the previous hash plus the serial number. Then you make the server forget each hash as soon as it's no longer needed. The first hash would be derived beforehand from the master private key in some fashion and is then part of the deployment package to the webserver. That way you can still generate all private and public keys from the master key (full determinism), but a hacker gaining access to the merchant's webserver would only be able to spy on future transactions, not past ones.

The one you're signing, TxNew.



This is scriptPubKey, that's what you replace the input that is being signed with.



See my original post for the hashType == 1 case. It sounds like you're trying to sign transactions you create yourself, so you probably don't have to worry about other hashTypes.



You serialize the copy you created in the first step.



Yes, you repeat the procedure for each input.



I recommend again the function SignatureHash(). Read it, sleep on it, read it again, you'll get it.



Locktime should be 0 unless you want to do some fancy stuff.



Sequence should be the maximum value: 0xffffffff (which is the same as -1)



Not necessary. But if you can't restrain yourself: 1DEjwkdqcpteKsxXTxtMfgrpS6LjqW7k4K