I plan to add a GL package to the (about to be launched) CIYAM Open project that will be able to get data directly via bitcoind - please check out the announcement for this project (hopefully tomorrow) and if people are keen enough for this to happen quickly then I can create a task to build it which can then be funded (note that I have used GNU Cash for years and also spent many years working on Fixed Asset Management software in the past).

Oops - I see your point now - you sold them under the current value - I guess you might have to wait and hope for a downturn.

I do understand that you are frustrated (and have not actually used Mt. Gox myself) - am just suggesting that it might be an easier route to "buy BTC" with your Mt. Gox $ and then move it out as BTC rather than as "fiat" (but please see if others have been successful doing this before trying as I am offering advice without having done so myself).

Are you able to withdraw the BTC from Mt. Gox or is it just withdrawing "fiat" that is the problem?

I like this low level approach - the upcoming CIYAM open source project's first application is a higher level one that allows donators to contribute BTC to a project, project area or specific project task (with the more general donations being moved by their respective owners down to specific tasks).

Devs can then "bid" to get the exclusive rights to perform a task by a given date and time (so devs aren't in a "race" against each other as happens with "bounties" which IMO generally lead to lower quality code being submitted). If a successful pull request for the task is submitted by the dev by the agreed delivery date and time then the funds will be sent to their address. If unsuccessful then bidding is opened again. A record of past "achievements" is kept in order to help the task "owners" decide which bids they will accept (i.e. preference to be given for those devs with the proven skills and track record for completion).

This system also then ties in with an escrow system that allows people to donate to specific tasks provided they are completed by the date and time that was accepted by the task owner for delivery (if no successful pull request merge occurs by the accepted date and time then funds are returned to the donators).

This system is going to go live very soon (PM me for the URL for a demo if interested).

Actually am working on something similar (in terms of escrow) for my own project - if it turns out to be useful then will be sure to let others know (not promoting any particular service at this stage though).

Am not sure how much I would trust any online wallet but I will say that the support from WalletBit is quite good (there you go Kris - something positive from me at last).

I wouldn't be promoting Coinapult for this - there is no user support for that service (I only got my 1 BTC back becuase Yankee was nice enough to do so).

I don't think (from my own research) that anyone has gone as far with this idea as I have (apart from perhaps Charles Symonyi's "Intentional Software" platform ) but I will welcome criticism when I launch the project (the entire website will have 0% manually written source).

I'm not sure exactly about the context but DAG normally refers to a "Directed Acyclic Graph" (think of an OS folder structure).

One point that I'd like to make is that the programming paradigm very much affects the reliability of the code itself.

Functional programming (possible in C++ but perhaps best done in a language designed for it such as Haskell) changes things a lot in that by using extremely well tested and covered "functions" the unit test requirements are greatly simplified (e.g. you are not having to check 1000's of versions of a "for" loop there is only the known "for loop" functions).

In my own upcoming open source project (hopefully to be launched before the end of the year) I have taken this concept a further step by combining both "functional" and "aspect oriented" programming with MDA ("model driven architecture") into a source code generating platform (so that manual source code is actually never written at all).

Just out of curiosity is a "time stamp" being included in the block header?

I can verify that this is indeed correct and am satisfied that paying with BTC via WalletBit using sites is fee free for the payer if they want to use their own wallet.

Very interesting - I do hope some more ideas about this could be hashed out as I think it would actually be a much better solution than using "proof of x" (where x is anything other than "work") to stop such attacks.

BTW - nice paper.

Understood - actually I've been wondering in regard to the "rewrite the whole history since the last checkpoint attack" that wouldn't the easiest solution to be to simply prevent blocks that are trying to replace older blocks being accepted if they are simply too old (or does the protocol already do that?).

Glad it worked - if you check their main page (http://bitping.net) there is a donation address (am not affiliated in any way with the service but I do like "minimal" API's like theirs and think they should be rewarded).

Does a "checkpoint" not make it impossible to do a block re-org for all blocks before and including itself?

Maybe this will URL will be of help:

http://bitping.net/exchange_rates.php?rates=USDBTC&format=rate_only&disclaimer=accepted

Not sure if you guys are still updating the OP but I did donate another 5 BTC on December the 5th (sent a PM to Rassah with tx id).

Good to see more happening with this!

If you still can run the Bitcoin client that you had been using then the easiest way would be to simply send your balance (perhaps divided up into chunks) to addresses you have created in the new wallet (with the newer Bitcoin client).

Be sure to make the first such transfer a small amount just to check that it works properly.