Topic: Generalizing the block chain (Read 860 times)

Ah, I think I now remember hearing these objections before regarding Namecoin. In my opinion the key would be to have a generic system, even more than worrying about the block chain baggage - you really don't want to start polluting the code base with for example NC specific code.

Incidentally this is what I probably like the most about Bitcoin - it exposed so much uncharted territory

Alright, thanks for the lead - I see that Mike has been quite active, I have a lot of reading to do :-).
Not including the data directly in the main block chain is exactly how I was thinking about it - I believe you simply need to include a hash of the external 'symbiotic' Merkle branch. It's still 'extra baggage' I suppose but it will be a tiny fraction of sizeof(vtx). I'd say the indirect benefit of having these very useful services only purchasable with Bitcoins combined with the extra mining revenue make this quite useful - what's the official take on this?

In fact thinking about it - it doesn't even have to be in CBlock, it could just be a regular transaction with some fancy scripting...

I will now crawl back in my hole and come back when I'm not quite so ignorant, hopefully with some code.

I don't fully understand it, but Mike Hearn has written a lot about how you can leverage the power of the chain without actually including your thing in it.

This has been discussed many times before. It's possible, but some people are very opposed to the idea of "stuffing the block chain with garbage".

Here's an old DNS proposal using Bitcoin's general timestamping properties:
http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal
(This could be greatly improved.)

Hi there!

I was wondering if anyone is working on the idea of generalizing the transactions that go into a block. Right now the only type of transaction supported is moving Bitcoins between addresses but as Namecoin demonstrated - there are certainly other uses for a block chain backed by so much processing power.

I think it is possible to extend the protocol to allow for other classes of block entries. They would be announced through the P2P network just as regular transactions and they would include a fee transaction to whoever mints a block containing it. To validate an entry, it should be possible to extend the existing script VM (e.g. support for key value store in the block chain) or create a new one to avoid introducing vulnerabilities to Bitcoin.

I imagine mining pools would list prices for the various types of services that they're willing to process into their blocks (or refuse to deal with some no matter what the price). The market would then find a value for the individual services in relation to the resources needed to process them. It would also provide extra compensation for the miners that could well exceed the Bitcoin transaction fees and coinbase reward).

Not only would that allow Namecoin like service with the security of nearly 15 thash/s but open the doors to further innovation.

Other than Namecoin, another concrete example is a trivial time stamping service. The validation script for the 'transaction' would simply return 'true' and would include a small data payload (say a sha-256 hash). Now if you come up with say a particularly clever piece of code - you can submit its hash in a time stamp transaction with a payment of 1btc. If you have to ever prove you had the idea first at some point in the future - the evidence is right there in the block chain (I'm sure there are less contrived uses for it, this just popped into my head first).

I think the biggest problem is to do with increased bandwidth and storage demands on the nodes. This could be mitigated with opt-outs for the lighter nodes, though even the nodes would benefit from servicing these symbiotic transactions indirectly by keeping all miners working on one chain and increasing Bitcoin's inherent value.

I'm curious what you guys think of this (and I apologize if this has been discussed before).