Spring has sprung in Beijing - a great time to visit Xiang Shan (http://www.kinabaloo.com/xiangshan_park_beijing.html) or do some Great Wall exploring.

As an incentive to be the very first BTC tourist in China - enjoy a Beijing Roast Duck meal on us at Quan Ju De (http://www.beijingattractions.org/Beijing-Famous-Restaurants/Quan-Ju-De.html)!

A few years ago I grabbed a document put out by the government in China that listed "official translations" for Chinese dishes (it was created in the run up to the Olympic games) and put all of the translations (after a lot of manual effort in order to make them more consistent and concise) into an application whose purpose was to use this information as a starting point for creating translations for specific restaurant menus.

Back then I was trying to create a small business that would provide English translations to local restaurants and did get a bit of interest but it wasn't really worth the effort without the work being far more simplified (testing of several typical local menus would only generate around 20-40% of hits within the DB of known dish names).

After a few months of effort I ended up with over 3,500 dishes (where quite a lot are basically the same dish named slightly differently in Chinese).

I think now a better idea might be to develop a smart phone app which would operate using OCR and the DB in order to show you a translation of any dish name that you scan (if it can't find an exact match then the dish name can usually be pulled apart to identify the cooking style, flavouring and major ingredients).

The DB itself could also be greatly increased by crowd sourcing (perhaps for small BTC payments per menu) making it then more viable for using it with the app I developed to do specific translations.

If anyone has any interest in (and even better has experience with) developing such a smart phone app please let me know.

I think this is a very real problem with the whole "vanity" address concept.  Unless the vanity address is extremely expensive to create due to the number of fixed leading characters it will be just as easy for anyone to create their own address with the same prefix (unless the service will never list another similar vanity address in which case you could still be scammed by the service).

In mandarin that is of course correct (easiest for English speakers to try and read "zhou" as if it was spelled "joe") although it that may not actually be the way he pronounces his own name if his mother tongue is not "standard" mandarin (as is the case for a very large number of southern Chinese although certainly if he were from Taiwan he would spell it Chou or if he was from Hong Kong he would spell it Chow).

I like this idea - and think that you *should* use email addresses both for simplicity and so that PGP could be tied into the system (for encrypting the receipt info).

The package that I have implemented for the open source project I will be launching later this year handles the issues of subscribing/unsubscribing very simply and already handles much of the required functionality (child boards, topic locking and moving).

I am working on the project every day and hope to be ready for launch in a couple of months (the delay being due to my having to now start documenting a project that has taken me over 10 years to build).

Whether or not a suitable platform for the actual forum I am quite certain it would be a very suitable platform for at least prototyping it.

I think if you want to be sure that the tx is permanently stored then the funds cannot be reclaimed (otherwise it could be pruned in the future), however, another approach you could perhaps consider is the following:

1) Use the file hash as a private key then generate a pubic key and send BTC to an empty wallet (that has had this address imported into it).

2) After getting the BTC immediately forward it to another address in the same wallet (if a tx fee is required you will have to lose this amount).

3) Publish the private key of the original tx (after enough confirmations have passed with the last step).

Assuming you don't spend the money you forwarded to yourself then I think that would keep a permanent record with the money eventually being able to be reclaimed (perhaps after a time when you no longer care about the proof).

Will be busy doing some "real" work next week but managed to spend a couple of days this week adding to my Forum package.

Here are a few more snapshots of what I've whipped up in the last couple of days (will be leaving it at this as far as posting snapshots goes in case they are too annoying):



This list is similar to the "unread posts" list (currently shows both read and unread but will be adding a checkbox to control this later). The "read" posts appear as light grey.



For a post to marked as "read" you need to click the "Mark As Read" button (will take you back to the list so not really such an inconvenience). In order to reduce (IMHO) unnecessary I/O my system does not work with a "view count" and so will not automatically mark topics as read.

The more interesting button here however is the "Subscribe" - no more silly posts needed to do that job here. Also an "Unsubscribe" button will appear for Topics you have posted in or subscribed to which lead us to the last snapshot:



This is equivalent to the "show new replies" list (currently shows read and unread but will also be adding a checkbox to control this).

You'll notice the "Introduce Yourself" topic does not appear here (as I used the "Unsubscribe" to get rid of it).

Once again all the server software is 100% C++ and is 100% generated.

Another possible approach that had been mentioned before is to make a "fake" bitcoin address that is appears to be valid but instead of being a real address it is actually a user provided hash (after the 1) and then a suffix (to ensure it is parsed as being valid).

You then burn a small amount of BTC by sending to this address (this amount will never be able to be claimed and so cannot be pruned) and then you would have for example the hash of a document permanently recorded in the blockchain.

I guess perhaps even better would be to include a URL in the tx (as a message) so that the tx indicates the original document location (or perhaps just its name or something else).

Unfortunately it's fairly easy to write software to send a Yes/No the instant the confirmation dialog appears (I built a tool for doing this in order to get around some shareware nags years ago).

I agree that the bid-ask spread is a very important factor but even currently for transfers where the timing is more flexible (say a week or even more) the (although admittedly not as much just recently) constantly moving price of BTC can make this much less of an issue (i.e. send the currency with the tighter spread when BTC is lower and wait to exchange to the other currency when BTC is higher).

Although using btcchina is somewhat risky (it may just disappear one day) the fact that they only charge % fees (and about the lowest of any exchange) would mean that you could divide up the transfer into smaller units (say 5-10 BTC perhaps) to reduce that risk (although the transfer would take a lot longer).

Nice set of links.

I really do understand the problems one can encounter programming in C++ (and much more so in C or doing C-ish stuff in C++) and have been programming in C++ since the mid 90's (started using C in the mid to late 80's).

My opinion is that if you do things the "right way" then the most "feared" problems really don't come up (such as buffer overruns, corrupted heaps, memory leaks, etc.) but I think now we are really just trading opinions and of course have gone a fair bit off topic.

The software system that I have built (and am still in the process of turning into an open source project) *generates* 100% of the "application" source code in any case so the usual sorts of problems associated with "coding mistakes" are pretty much irrelevant.

The "forum" package that I've been working on (although it's not a priority amongst many other tasks I'm currently busy with) is getting close to completion (as far the functionality excluding the PMs) so if anyone has any interest when completed I will provide information where they could take a look at it.

If you are using C++ in a way that you are always shooting your feet then you first ought to learn how to shoot.


Sorry if I'm coming across as patronizing it just seems to me that your comments don't show a great understanding of modern C++ as std::auto_ptr (what I can only guess you are referring to with the above quote) is on only one type of smart pointer (and if you look into boost there are various others - http://www.boost.org/doc/libs/1_49_0/libs/smart_ptr/smart_ptr.htm). The point is not to just prevent "dangling" pointers (which if you choose to use plain pointers anywhere in between you can't stop anyway) but to carefully control lifetime scope and to safely share pointers amongst owners, observers and (if required to) do so with thread safety.

Really guys - this whole "C++ is too dangerous to use" mantra sounds a little like the '90's Java hyperbole that came out from Sun (now try implementing the very useful RAII or as I prefer to call it "scoped object" pattern in that particular language and enjoy all that added mess of try/finally spaghetti you'll need to release your resource at the right time).

You can use C++ in the same way as your more "beginner friendly" languages and it will do the job - only faster. Even a lot of the old parsing ugliness (such as the old auto_ptr<map<string,string> > vs auto_ptr<map<string,string>> which you can now use) has been addressed.

No one is forcing you to use plain pointers or char arrays (I am guessing your bugbears). Pretty much all areas of real risk are API's (especially OS ones) and underneath all your shiny other languages must be the same API calls (which being C are going to have the same risks - just you are insulated one level from them unless of course your OS is written in a higher level language).

BTW I presume you guys did read that the bitcoin-qt *bug* was actually a missing compiler flag and not due to C++ coding.

So exactly how do you get a buffer overflow using std::string?

I'm not sure if anything like this is feasible or not but is there perhaps a way that some sort of voting by standard clients (rather than miners) could be used in order to decide about checkpoints (perhaps by unique IP addresses)?

And also that on the whole anything viewed as being something the "powers that be" might not like is not something that a lot of Chinese are going to get too involved with.

I understand there is often a variance in the price between exchanges, however, is it really possible to send $1 overseas via another method?

That being said if you really do want to do such micropayments is it going to hurt you so much to pay them $1.06 or even $1.10?

(P.S. or you could just say to them you are paying 6 RMB per hour rather than 1 USD and then they might be happy to end up with a little more)

you did notice this didn't you?

Hundreds of BTC per day is really not enough volume?