I don't think you need scripts to do something like that.

Just send a bitcoin to yourself, and then declare that transaction is the "root transaction for My Valuable Asset."

You'd need a custom client that only accepted or spent transactions that could be entirely traced back to that Root Transaction (not hard, all transactions can be tracked back).  And shows fractions of that coin as units of your custom currency.  And you'd probably want to make some other changes so your users didn't accidently (or purposely) mix Your Valuable Asset coin with regular bitcoins (like a custom wallet and different scheme for generating payment addresses).

Yep, you're right.  The good fork is longer than the bad one now; the last ORPHAN BLOCK my TEST bitcoind got was about 20 hours ago.

svnTEST branch is up on github.

I also uploaded just the production-bitcoin-to-TEST-network-bitcoin patches to github, at: http://gist.github.com/502460
... so:
... should patch production network source code to TEST network.  And:
... will go the other way.

That IS part of the new -port / -rpcport code (I use boost::interprocess::file_lock to make sure bitcoins running on different ports don't try to use the same wallet/blkindex/etc files).

I'll create an svnTEST branch that omits those changes, and will always be just a TEST-network version of the latest svn trunk.

Cool!  Hope you don't mind, I added it to my github network as a 'feature' branch.

Can you be more specific about where your build fails?  Is it in the new code to support the -port / -rpcport options (which I should have put on a different git branch) ?

It's pretty common to turn maps into objects, so you can use syntax like:
  foo.tx_id
... instead of foo['tx_id'].  Especially if you're doing something like passing the data into a templating system (which may ONLY understand the object.field syntax).

And foo.class just doesn't work out nicely.

I just updated my git "svn" branch with r116-119, and also merged it against 'master'.

The git network diagram showing what I done did is kinda pretty.

The good news is the TEST network is doing its job-- the problem patched by the 0.3.6 release (invalid transactions accepted as valid) was implemented and demonstrated on the TEST network.

The bad news is that means the TEST network block chain split yesterday.  If you are, or were, running a release prior to 0.3.6 on the TEST network, you've got bad blocks in your blkindex.dat and blk0001.dat files.

So, you need to:
1. Shut down bitcoin or bitcoind
2. Remove the blkindex.dat and blk0001.dat (in ~/.bitcoinTEST or ~/Library/Application Support/BitcoinTEST or %APPDATA%\BitcoinTEST) files.
3. Be sure you're upgraded to 0.3.6
4. Run bitcoin/bitcoind, and you'll download the "good" block chain.

Any blocks you generated after the bad blocks are invalid, so if you were busily generating blocks on the TEST network in the last couple of days... sorry, that play money is gone.

Transactions that you made may or may not make it to the new block chain, depending on whether or not they originated from invalid coins (any coins generated after the bad blocks are invalid).

Speaking of the network...
... is there any really robust, generic, low-latency, open source p2p network "middleware" out there?

I think using protocol buffers as the serialization format is a good idea, but I don't think just switching to protocol buffers "buys" enough to be worth the effort (at least not now, when transaction volume is low).

I'd like to see some experimenting with running bitcoin on top of a different networking layer (and use protocol buffers, too).  Is there a p2p network that is designed to be extremely highly reliable and difficult to infiltrate or attack with malicious nodes?

Couple of quick suggestions:

Using the key name "class" will cause problems for, at least, JavaScript, and probably other languages where "class" is a reserved word.  "type" or "variety" or some other synonym will cause fewer problems later.

Or, maybe better, get rid of that field and just report credits as positive numbers and debits as negative.  And add a separate "generated" field (boolean true or false).

Since each entry refers to a transaction, I'd suggest adding a "tx_id" SHA256 hex-encoded transaction id.  Then listtransactions would play nicely with the refundtransaction JSON-RPC extension (and maybe a future gettransactiondetails that let you get transaction parents, which block the transaction was in, and so on).

Code to get that would look something like:

That second ./bitcoind getinfo has to be:
... otherwise it will use the default config file and datadir.

He/she/they want an easier way for The Crowd to control The Policy-- right now, if you know enough C++ to modify and compile your own version of Bitcoin and can convince enough other people to use your version, then you can change Policy.

Allowing everybody to tweak Policy and having some sort of mechanism that figures out what "everybody" wants to do is an interesting idea.  I have no idea how you could actually make it work, and it would open up a whole other can of potential security problems (what if somebody controls a bunch of IP addresses and decides to "vote" for a policy that benefits them?  or can you tie the policy changes to proof-of-work somehow?  How do you aggregate what "everybody" thinks in a non-spoofable way? etc etc etc)...

Are you still downloading the block chain?  If you don't already have all 70,000+ blocks in the block chain, then you transaction won't show up as confirmed until you catch up.

I built a TEST-network bitcoind with the SVN r115 changes merged in, and yes, after that one change it's been happily generating coins all afternoon.
I don't use the stock makefile.osx, though-- I setup the dependency directory structure a little differently (for no really good reason).

If you include a double-spent transaction in a block you generate, then that block will be rejected and you don't get your 50BTC reward.

I get:
... compiling cryptopp/sha.cpp (latest SVN source) on my Mac (gcc version 4.2.1).

I fixed it by adding -DCRYPTOPP_DISABLE_ASM  to my makefile; perhaps somebody with more experience compiling C++ on a Mac can figure out a better fix.

Does it work if you specify the full path?  e.g. -datadir=/home/psyvenrix/datadir2  ?

Before the last two difficulty adjustments it took my (4-year-old) mac laptop two weeks to generate any bitcoin.

So after the adjustments, I estimate it could take it 1-2 months to generate any.

I've been working on adding -port= / -rpcport=  command line / config file options to bitcoin.  The idea is to let you run multiple copies of bitcoind on one machine; I need this because I'm planning on having at least two Bitcoin-related web services (the Bitcoin Faucet and a service to be named later), I want them to have completely separate wallets, but I don't want to rent multiple servers to host them.

Usage looks like this:

Satoshi pointed out that allowing bitcoin/bitcoind to run on a non-standard port could be dangerous, because if misconfigured two bitcoins might both open and write to the same database.  To prevent that, the <datadir>/db.log file is used as a lock so only one bitcoin can access the same datadir at a time (uses boost::interprocess::file_lock, which is purported to be cross-platform and well-behaved, even if bitcoin crashes).

Issues that came up as I was doing this:

I left a call to wxSingleInstanceChecker in the Windows GUI code, so no multiple-gui-bitcoins-listening-on-different-ports on Windows.  I don't do Windows...

I didn't bother making the error handling graceful if you point two bitcoins at the same datadir (you get a runtime exception "Cannot lock db.log, is bitcoin already running?").

Patches are at http://pastebin.com/2e4hfXSS; I've only tested on Linux so far, anybody willing to try this on Windows?