Building on the Block Chain, Adding Data to Transactions (How-To)

[SilentCicer0]

Hey Everyone,

I'm new to the form. I have around 7-8 years programming experience (python, PHP, Java, the general languages).

I want to add some data to transactions, basically some names and dates.

My apologies in advance if this is a repeat question.

Is there any guides, posts or wiki's in place for this specific task?

I may be wrong, but I think this post would help other developers start the process of tacking on data to transactions.


Would love to start building on the block chain.


Cheers,
SC.

[SilentCicer0]

Found a Guide. Well if anyone has other ideas, notes post here.

http://bitcoin.stackexchange.com/questions/31972/how-to-add-additional-information-to-transaction

[shorena]

The elephant in the room is: why?
Why do you want to be the person that makes everyone running a full node store your data?

People are allready complaining about the size of the blockchain. The max_blocksize limit is reached fairly often recently, leaving TX unconfirmed that pay a fee and have reasonable high priority. What is so special about the data you want to store there that it cant be stored elsewhere?

[SpanishSoldier]

The elephant in the room is: why? - Because Bitcoin Blockchain is the best distributed DB on earth.
Why do you want to be the person that makes everyone running a full node store your data? - I understand the Pain. But everyone wants to Gain.

People are allready complaining about the size of the blockchain. The max_blocksize limit is reached fairly often recently, leaving TX unconfirmed that pay a fee and have reasonable high priority. What is so special about the data you want to store there that it cant be stored elsewhere?

[SilentCicer0]

shorena & SpanishSoldier:

After doing a bit of reading, I understand now that what I want to do is probably not suitable for the conventional Bitcoin blockchain (because of the strong debate between storing throwaway/prunable arbitrary transactions on the blockchain and keeping the blockchain lean).

However, I am experimenting with a self-made copy-coin with the intended purpose of storing data on a blockchain. The coin by it's very nature would be a coin where data can be held within a blockchain, where users could decrypt and asses whether they want to keep or eliminate the additional data transactions coming in. Something I know is already possible on existing Bitcoin infrastructure.

I know it's a little nutty, but I'm just experimenting. And I wont be experimenting with OP_RETURN transactions on the Bitcoin blockchain--that I know for sure.

I think SpanishSoldier has a point, the blockchain is the greatest dist-DB on earth, and so I ask, why not leverage it?

**And by store I mean through prunable outputs not stored as UTXO, but only stored by those who need or want that data. I don't see much wrong with this and I think the 0.9 implementation really does a good job at addressing this idea.

 
Cheers,
Nick.


Sources:
https://bitcoinfoundation.org/2013/10/core-development-update-5/ **80 bits of prunable data.
https://en.bitcoin.it/wiki/Script
http://bitcoin.stackexchange.com/questions/31972/how-to-add-additional-information-to-transaction
http://www.bitcoinx.com/84-alternate-uses-blockchain/ ** I think to do any of these things we need some arbitrary data storage.

[SpanishSoldier]

shorena & SpanishSoldier:

After doing a bit of reading, I understand now that what I want to do is probably not suitable for the conventional Bitcoin blockchain (because of the strong debate between storing throwaway/prunable arbitrary transactions on the blockchain and keeping the blockchain lean).

However, I am experimenting with a self-made copy-coin with the intended purpose of storing data on a blockchain. The coin by it's very nature would be a coin where data can be held within a blockchain, where users could decrypt and asses whether they want to keep or eliminate the additional data transactions coming in. Something I know is already possible on existing Bitcoin infrastructure.

I know it's a little nutty, but I'm just experimenting. And I wont be experimenting with OP_RETURN transactions on the Bitcoin blockchain--that I know for sure.

I think SpanishSoldier has a point, the blockchain is the greatest dist-DB on earth, and so I ask, why not leverage it?

**And by store I mean through prunable outputs not stored as UTXO, but only stored by those who need or want that data. I don't see much wrong with this and I think the 0.9 implementation really does a good job at addressing this idea.

 
Cheers,
Nick.


Sources:
https://bitcoinfoundation.org/2013/10/core-development-update-5/ **80 bits of prunable data.
https://en.bitcoin.it/wiki/Script
http://bitcoin.stackexchange.com/questions/31972/how-to-add-additional-information-to-transaction
http://www.bitcoinx.com/84-alternate-uses-blockchain/ ** I think to do any of these things we need some arbitrary data storage.

What u want to achieve has already been implemented by Ethereum and they have made more than a million just by selling the packaged idea and not giving anything in reality.

[stevenh512]

However, I am experimenting with a self-made copy-coin with the intended purpose of storing data on a blockchain.

Sounds like Namecoin to me.

What u want to achieve has already been implemented by Ethereum and they have made more than a million just by selling the packaged idea and not giving anything in reality.

(emphasis mine)
Then you can't actually say they've implemented it, at this point they've only promised it.

OP's needs can be served by already existing technology, though. I'm sure Namecoin or NXT would work since they were both designed with the idea of storing arbitrary data on a blockchain. Depending on OP's needs, it might also be possible to use the Bitcoin blockchain with OP_RETURN transactions, that would still contribute to the ever-increasing blockchain size but unlike most other methods of storing data on the blockchain it has the advantage of not contributing to UTXO bloat.

[SilentCicer0]

I'm thinking however of modifying the client to selectively store incoming OP_RETURN data (selective pruning). However, this seems, every second that passes by, more and more like an impossible task given the state of the Bitcoin blockchain and the structural integrity of conventional Bitcoin blockchain.

Selective blockchain storage seems to be against some critical principles of the blockchain itself. Ethereum is just so cool when it comes to using a different blochchain model to establish a blockchain which can be trimed, let go, reorganized or forgotten.

None the less, I'm still experimenting in the controlled coin space to establish a client which reacts to incoming OP_RETURN data off a blockchain. Namecoin does a great job at storing this sort of data, I may even use it as a base. Not sure yet though.


Cheers, thanks for the comment.

[junglecat]

Found a Guide. Well if anyone has other ideas, notes post here.

http://bitcoin.stackexchange.com/questions/31972/how-to-add-additional-information-to-transaction

The data would eventually get pruned (because it has zero spends) and no longer exist. You'd have to create "another" coin to achieve what you want unless you use a side-chain which may have the same problem.