On blockchain.info it's possible to look at a random transaction and see where it came from and where it was spent. You can click back and forth until you find an unspent transaction at the end of the chain (or coinbase at the beginning). Unfortunately, the JSON call doesn't seem to return the same source/sink info as the web page (or am I wrong?)

I'm looking for a simple interface for doing this on BitcoinJ. At the moment, all I can think of is to scan future blocks for sequential transactions as inputs, but that doesn't seem very efficient, in time or storage space required. Perhaps there is a way using just the block headers this could be done?

I'm wondering if it's possible to create a transaction that the receiver can only send back to one specific place.

So for instance a supermarket cart would receive a coin, and the coin would always go back to the customer who put it in, after they return the cart to the queue. Currently this is done by a chain type system where one cart locks the next.

Hi All,

I saw there's been some movement on the area of multiple coloured coins. What I'm wondering is whether there's any movement towards creating automatically enforced contracts. So, for instance:

(Let's call one of the colours BTC, the ordinary coin)

1) Colour X is a type of coin. Colour Y is a kind of coin. Parties with wallets A and B agree a trade. The system credits one and debits the other for the agreed amounts, but only contingent on each other. (That way nobody gets screwed on the trade.) Note this isn't an exchange as such, because it isn't a mechanism for determining price, just one for enforcing agreed prices.

2) Colour W represents shares in a company. It's shares are moved around using the above exchange system, ie people swap their W for BTCs. But W has the special property that once a year, every wallet receives some amount of BTC as a dividend, pro rata according to how many Ws they have. W can be linked to some wallet containing BTC, which everyone can check using the blockchain.

3) Built in futures: Colour F represents some exchange on a given date. On that date, all the miners will credit all long F wallets with some BTC taken from the short accounts.

4) Credit and Default: Being able to be short requires credit. Using the above pieces, you could create a debt system. For instance, one wallet could be guarantor for another. You could enforce rules about taking assets out of wallets that are in the red, and rules about how to divide up defaulted wallets. In short, you could recreate the corporate system of liabilities, cheaply, enforced by code rather than judges.

Of course there are details to be fleshed out, just wondering if anyone has made inroads in talking about this.

Hi, I'm new to the forum, though I've done quite a lot of research on BTC.

I was wondering if anyone had suggested putting BTC denominated securities directly in the ledger? It seems at the moment transactions are simply moving BTC from one wallet to another. With the network, you could enforce contracts such as futures settlements natively, rather than through external services such as icbit.se. Of course the community would need to come to an agreement as to how this would happen, what to do about defaults and such.