Topic: Using bit coins as negotiable, verifiable, warehouse receipts (Read 9664 times)

Actually I don't think it *requires* making a breaking change. It simply requires making everyone who trades in your "gold coins" a little more rigorous about their behavior. Either that or making the client a little more explicit about when it creates merging transactions.

An example of rigorous would be, the person who bought "gold coins" would have them transfered into a virgin bitcoin address. In your wallet, you could have you client tag that address as "non-merging". Everyone who received them would also do the same thing. In that case, when they are redeemed they would be "untainted".

Should someone inadvertently taint the gold with other coins, they would have to continue trading/redeeming all the tainted coins in one block. In effect, you have to lose the traditional value of the tainting coins to preserve the "gold value" of the tainted ones.



I initially thought the same thing. I also noticed that you'd probably want to take into consideration non-fungible vs non-fungible and divisible vs indivisible commodities.

So essentially to achieve what I want may require a breaking change.  That change would be a few things.

1) each transaction specifies the type of asset being transferred.  Currently BTC is assumed.
2) issuance of new types of bitcoin may only come from the same address.  Essentially each BTC address may issue its own fungible "shares" which the
    the transaction system would then track.  The type would be a BTC address and only that address has license to "print".  It may be desirable to enforce
    that any user created "shares" be a percentage of a whole and thus ensure the receiver that their "share" may not be diluted by the "printing" of additional claims.

3) each transaction may carry meta data as defined by the issuer of the "shares". 

Essentially I want to abstract the unit of transaction because I think that distributed transaction verification is *the killer feature* of bit coin.

I am a software engineer and would like to contribute to this cause, but need to get oriented to the design and best practices.  Anyone have any ideas how
to achieve this?

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.


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.


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.


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.

Another thought comes to mind, anonymous transfer of messages.  If you can send someone a bitcoin or a bit note why not enable anonymous p2p communication via your bitcoin addresses?   Perhaps I am barking up the wrong tree here.  One of the problems with e-mail is that even though you can encrypt the message, the source/destination are still public knowledge and you must register an e-mail address with a known server. 

So imagine if every transaction included a "message field" that could contain arbitrary data.   Transaction fees (in bitcoin) would automatically manage resources by rewarding the node that delivered the message to the destination. 

I suspect that this may expose a weakness in bitcoin if there is no effective means of purging "old data".

I suspect that using bitcoins as a means to allocate P2P network resources would create demand!  And users providing those resources would then provide the supply!  As more people wish to use the p2p network the demand for bitcoins would go up which would cause their monetary value to increase and thus the number of people setting up p2p nodes!

Loom seems to be very close; however, it is a closed / centralized system as demonstrated by the fact that it requires an "invitation" to join.  Transfers require using their "server" and depend upon temporarily using a secret random number to "store" your asset.   

Some requirements of a desired system:
distributed
a single address may issues 100% of all available 'notes'.
transfers of notes are tracked using the bitcoin system

Bit coins are "mined" and randomly distributed and then all transfers are tracked. 
Bit notes (IOUs) are "issued" at will and then all transfers are tracked.   Only the issuer and anyone they tell would know the "meaning" of the IOU or digital asset.

The system could work today by simply "forking" the bitcoin code base and starting a new block list; however, it is impractical to create a new p2p network for each "type" of transaction. 

Now I can issue "shares" of stock in my "secret company" and allow owners to transfer shares "at will" without using an exchange, but me being the "issuer" could always redeem the IOU without fear of my OUs being counterfeited.     

So the question becomes, what incentive does anyone have to put transfers of my secret company stock into a bitcoin block?   I think the answer lies in attaching a bitcoin "bribe" with the transfer such that which ever node includes the transfer in the block gets the bitcoin. 

Now you have created a strong demand for bitcoins as tool to enable notes to be posted into a block.

That's interesting! Thanks for the reference.

Check out Loom.

It seems that the principle of bitcoin is to track transactions and that it is possible for anyone to review the "transaction history".  If that is the case, then is there any reason why bit coins couldn't double as digital warehouse receipts? 

Suppose you deposit 100 oz of gold with me and in exchange I give you 100 bit coins with a "repurchase agreement" in place where I will buy back the "same" 100 bit coins for 100 oz of gold.  The fact that the coins "left" a designated account and have not yet returned to that account means that they are "backed by gold".  With some standard and published "addresses" and some "even/odd" counting it should be possible to independently verify whether a coin is backed by gold and *who* is doing the backing without checking in with a the warehouse. 

Is there something about the bitcoin implementation that would prevent this kind of usage?

I posted this in another topic and was told that the coins were truly fungible and thus there was no reliable way to achieve such a result with the current implementation.  I suspect that some individuals more familiar with the design / implementation and constraints could identify if it would be *possible* to design a system similar to bit coin that would achieve this result. 

If this were achieved then bit coins could transition from a digital "asset" that only has value due to "rarity" and its decentralized nature into a far more generic and useful tool by enabling the decentralized exchange of any kind of good including stocks, bonds, gold, dollars, etc.   

I suppose if you created a unique "network" for each type of "coin" and then enabled clients to "track" multiple types of bitcoins it could work.  The key would be to find a way to leverage the transaction verification system for more than one "type" of coin and then to allow people to issue their own "types of coins".