Is there something about the bitcoin implementation that would prevent this kind of usage?
Yes, but it isn't immediately obvious why.
Technically it could be done without changing any of the shared data structures (the blocks list of transactions). But you would have to assure that the client that generates the transactions doesn't inadvertently "taint" your coins.
So for background, the "transaction history" called the block list, is really a shared directed graph of all valid transactions.
The transactions themselves (nodes), group one or more in-points, and two out-points (edges).
The out-points are *quantities* of bitcoins, assigned to particular bitcoin address. The first out-point is the amount transfered, and the second out-point is any leftover from the sum of the in-points.
A transaction's one or more in-points are simply links back to previous out-points in the transaction list.
Individual bitcoins are not represented as objects, neither are bitcoin addresses. The amount of bitcoins assigned to a given bitcoin address, is simply the summation of the unused out-point values assigned to that address.
(Someone correct me if I've screwed this up!)
So for example, say three people send bitcoins to one of your "bytemaster" bitcoin addresses, in the amounts of 4, 5 & 6 BTC.
(4 BTC, "alice")<-- in-1 [Transaction 1] out-1a --> (4 BTC, "bytemaster")
[ ] out-1b --> (0 BTC, "alice")
(9 BTC, "bob" )<-- in-2 [Transaction 2] out-2a --> (5 BTC, "bytemaster")
[ ] out-2b --> (4 BTC, "bob")
(2 BTC, "chuck")<-- in-3a [ ]
(3 BTC, "chuck")<-- in-3b [Transaction 3] out-3a --> (6 BTC, "bytemaster")
(5 BTC, "chuck")<-- in-3c [ ] out-3b --> (4 BTC, "chuck")
The first transaction comes from alice in the about of 4 BTC. Notice it has 1 in-point and no left over change. This is the simplest type of transaction. I'll call it a "pass-through". One input value and one output value.
The second transaction comes from bob in the amount of 5 BTC. However, bob had previously received 9 BTC from someone else and he only wants to give you 5 BTC of that. So he sends the remaining 4 BTC back to himself. Notice the input quantity must equal the output quantity. I'll call this type of transaction a "fork". Because it has one input value and two output values.
The third transaction comes from chuck in the amount of 6 BTC. However, he has previously only received small amounts of bitcoins, so he doesn't have enough value in any previous out-point to transfer to you. So his transaction gathers value from several previous out-points. I'll call this type of transaction a "merge", because of its multiple inputs.
What you want to do is to create some "gold bitcoins" that you can identify as different from regular old bitcoins but others wouldn't. This is logically possible to do with bitcoin as is. The simplest case would be a series of pass-through transactions.
(5 BTC, "gold" )<-- in-4 [Transaction 4] out-4a --> (5 BTC, "bytemaster")<-- in-5 [Transaction 5] out-5a --> (5 BTC, "vendor")<-- in-6 [Transaction 6] out-6a --> (5 BTC, "gold-redeemer")
In this case, the "gold-redeemer" could easily see that the value originated as "gold"
However, if someone was to send some regular bitcoins to the same address at you or a future owner uses for the gold, it is possible that the "gold bitcoins" can become "tained" by the regular coins in a merge transaction.
As far as I know, in the current bitcoin client, you do not have fine grained control over this. For example your client might merge the coins from alice in with the gold coins. This makes it impossible to decide where the gold is down the line.
(4 BTC, "alice")<-- in-1 [Transaction 1] out-1a --> (4 BTC, "bytemaster")<-- in-5a [Transaction 5] out-5a --> (5 BTC, "vendor") <-- in-6 [Transaction 6] out-6a --> (5 BTC, "gold-redeemer")
(5 BTC, "gold" )<-- in-4 [Transaction 4] out-4a --> (5 BTC, "bytemaster")<-- in-5b [ ] out-5b --> (4 BTC, "bytemaster") <-- in-7 [Transaction 7] out-7a --> (4 BTC, "gold-redeemer")
In this case "gold-redeemer" has received 9 coins but can tell that only 5 "gold coins" were issued. It is ambiguous who to return the gold value to.
So for your needs, pass-through and fork transactions would be OK. You could merge coins if they were all "gold coins" but if you or someone else inadvertently merges in regular coins, all that gold becomes tainted.