Topic: Please Don't Shovel Unrelated Crap Into Bitcoin! (Read 4915 times)

I agree that the question, as worded is kind of confusing.  I answered "Depends," here's why:

1) as mentioned previously, it's expensive and computationally intensive to maintain a blockchain.  Therefore ending up with two blockchains that are doing very similar tasks seems like a waste of resources IMO.

2) with regard to namespaces in the blockchain (bitdns or something being only one of them) I think this is a very important feature that must be included.  It would allow human readable and memorable names for underlying addresses.

3) I think that building applications that require the bitcoin blockchain as a dependency is fine.  Building bitcoin such that it requires these specific applications as a dependency is not.

The question is confusing, not the best wording ever.

How do your feel about....?

Yes, Depends, No

I am guessing No means I feel I am against it.

I don't think a proof-of-work chain is useful for distributed storage. There are much easier ways to implement distributed storage.

The proof-of-work chain is a great way to do distributed allocation though, which is why it's useful for rationing limited digital codes (bitcoins, domain names, etc).

Yes. Merely not implementing feature requests in the core is a good start; although new tools to do the same in better ways (pooled mining springs to mind) should be allowed to prove their worth.

I would like to hear more about removing the scripting.


Nooo!  We want all the miners on our one chain, to maximise our security.

I think we can have our cake and eat it.

We are currently having a discussion on how to make the BitCoin protocol extensible here https://bitcointalksearch.org/topic/m.27723 .

I personally don't have anything against extensions to the protocol, and services built on top of it, but it has to be clear that they are extensions that may not be implemented by all nodes in the network. The goal I think should be to keep the core protocol small and easy to implement, and then give people the ability to add their functionality on top.

However I think distributed storage would be a stretch, and it would certainly slow down the network as a whole.

One idea I can actually see happening is a decentralized DNS replacement as discussed here https://bitcointalksearch.org/topic/bitdns-and-generalizing-bitcoin-1790

How do you feel about allowing cars to use roads that were originally designed for horses? That causes congestion, death, and massive expense, but most people still feel it's worth it.

What are the unintended consequences? Any convolution of the protocol runs the risk of compromising the whole system. It's not worth it.

Sure some ideas are interesting, but people need to stop having nerd-gassims over it and stick with the game plan.

I think it would be prudent to do as much as possible to prevent integrating other systems into bitcoin. Bitcoin should be kept as simple as possible. If you want to do some freaky shit, just start another blockchain.

(I voted "depends") It depends on the method Bitcoin is using to transfer and propagate information across the network and into storage. If the method used merely verifies information as true -- "X owns 66 BTC" "W transferred 200 BTC into your account" "example.com resolves to a.b.c.d and is owned by Y" it doesn't matter the data, why wouldn't you want it in the network? I describe such a strategy in https://bitcointalksearch.org/topic/hash-based-chainless-transactions-theory-2035.

Bitcoin will depend on being able to verify transactions quickly, this will mean not relying on a large local database to verify a transaction. I will say Bitcoin needs to be able to carry metadata across transactions, as long as it is not stored in the network and it's still cryptographically verifiable. Maybe it needs a small protocol change so people can prove their identities using the network, or doing interactive transactions instead of just broadcasting transactions, such a small change would be acceptable. Storing arbritary data inside the block chain, however, would not be a good idea, there's no reason you couldn't develop a parallel network that stores the data (and again, maybe uses minimal hooks into Bitcoin to do so).

Erm, quick tech-check: the "message" one can add to a transaction, is that stored in the scripting area?

If it is, and you need to get rid of it, maybe there's a way to use the bitcoin addresses as a nonce to secure the external service?  Publishing sign( nonce concat hash( latest_database ) ) should be almost as good...  it's might be easier to pin the external service in time by silencing the publication of the signature?

(I voted no.)


That is my understanding.  I think Bitcoin can do this already, with no bloat in code or protocol, no scripting and minimal data in the blockchain.  I wrote about it over on https://www.bitcoin.org/smf/index.php?topic=1938.msg26342#msg26342 but maybe not very clearly (please ask if interested).

Bitcoin provides timestamping.  If you make a transaction which includes (e.g.) a sha-256 of some data then it becomes part of the timestamped chain.

Other systems must maintain their own sets of data (monotonic chain or otherwise) with their own P2P system and rely on Bitcoin only to timestamp it, and prove a simultaneous spend of >= 0 BTC.  The reason to use Bitcoin this way is to avoid fragmenting the proof-of-work effort, which benefits only the cheaters.



My suggestion would put a small amount of data into a small transaction.  The txns to do this will include fees to get into the chain regularly and promptly - maybe the transaction consists only of fee?  Heavily used systems might want a timestamp every 10 min, so that makes one txn per external service per Bitcoin block.  Aggregating these into one txn per block looks like a service the market might provide.

This is not taking charity from the original Bitcoin, but buying a service from the miners.  The only extra requirement is 32 bytes of message on the transaction; I think this is necessary for purchasing from an online retailer anyway.

The root problem with adding this stuff to the block is the size of the transaction, but if a separate p2p database were developed, references could still be added via the scripting system to definitively timestamp the exterior references without adding a great deal of data to the blockchain itself.  This would likely result in a slightly higher standard transaction rate due to the increased size of the transactions.  This is similar to timestamping a private recordbook by taking it to a notary public to notarize your signature behind several pages of handwritten words without whitespace.  This is exactly what a lot of union reps will do using a hardbound record book for meeting notes with the company reps.  Following the meeting, the union rep will take the hardbound record book down to a notary (not associated with any union) to be notarized so that the company reps can't claim that the records were falsely scribed after the fact.  They can still claim that they never said it, but to claim that the union rep's book is a forgery puts them in direct conflict with the legal affidavit of a professional who has a reputation to defend.

A similar system could be used to timestamp photos, video or any other "IP" content, no matter where that content is stored, by including a hyperreference to one or more sites that hold the orginal content, along with a secure hash of the content.  I imagine that use of the higher functions that the scripting would permit would require a transaction fee anyway.  Some transactions will always be free, but like Satoshi has said, that's charity.  If you need the scripting functions, you are going to be paying something for the priviliage anyway.

Bitcoin could be modifed to exclude this kind of data however.

There is an unmet need which is why this topic is even being discussed.  My concern is more when other sorts of garbage starts to get piled in like MP3 files, Wikileaks documents, and drug trade instructions.  If we were being paranoid about being associated with Wikileaks previously, having the material in Bitcoin is going to only make this a much larger target.


Let's cut this down to the core of what is wanted here:  The desire is to create some sort of distributed public database with some kind of cryptographic controls to both timestamp, certify that the information has not been tampered or modifed unless through proscribed rules and protocol, and that effort to store the data be associated with Bitcoins so far as charging for either access to that database or more importantly to put information into that database.

The perception and growing consensus is that the only way to accomplish this task is to shove it all into transaction blocks.  If you can find another solution to this problem, I'm totally open to a solution.  The best alternative is a separate block chain and hence independent currency which as creighto and others have suggested is not likely to succeed.  Saying that the whole notion here is stupid isn't going to get this issue to go away and it may get worse as well.

Perhap Git will work in this fashion where perhaps putting a Bitcoin interface into that to transmit "fees" for adding content.  Perhaps some other system could be derived.  Much of this is also trying to explore just what advantage the block chain has here and if it even might have another application and use.  There is a thought perhaps that it might be useful.

Protocol governance anyone ? XD

The Bitcoin program should always be about transferring bitcoins only, but I don't see a problem with using the already-existing transaction scripting system to use the Bitcoin block chain for other things. No change is required to the Bitcoin code to allow these uses.

It's not symbiotic.  Domain names are irrelevant to the vast majority of the currency using human population on this planet, as well as the vast majority of the subset that has Internet access.  It's a niche market, and doing it would become a burden to Bitcoin.  Small as that burden may be, it will be a disadvantage that would allow a competitive cryptocurrency to overtake it.  Feel free to take the source and modifiy it and do this thing on a separate blockchain, but don't be surprised by it's marginal success.

I think certain kinds of unrelated crap are a good fit, and I count Domain Names in that category. It's symbiotic - something that could strengthen Bitcoin too by diversifying generation. Domain name registrations are very compact transactions.

But I only want to see Domain Names in the Bitcoin block chain if bitcoiners want it there. Technically there's no problem starting up a separate block chain for domain names.

Keep It Simple, Stupid !

I'd vote, but my particular position isn't considered in the poll options...

It's a personal view, but I'm sure some will share it, although it might be hard to express in a small amount of words, still I'd like to try and express it here:

NO. FUCKING. WAY.

But I'm not obsessed with my views and they tend to change over time, so feel free to change WAY to other less offensive synonyms.

A lot of us are investing considerable time, money and energy into Bitcoin related services. There's talk on these forums of embedding DNS, files, ... food  

Bitcoin should focus on money. By including all these extras in here, you will scare off others. Focus on one thing and do it well. I don't want the code-base to become bloated/be debased with all these extras that may not work and just use up our energy.

We have something that works. Lets try to protect the parade.

However, having said that: if there is some way to generalise Bitcoin so that anyone can setup services with no preference, then that can only be a good thing that'll strengthen the network. I'm against though including specific things in the main codebase.