I have a few questions about the specifics of Bitcoins peer-to-peer construction. Maybe the forum can enlighten me as to how the network goes about communicating between network nodes.

I'll do a play-by-play for questions as to make it clear what I am asking.


1. Sending New Transactions:
- When a new transaction is sent from my node to my nodes peers, what do my peers do with it?
- Do they send that new transaction to their peers as well?
- Or do they simply hold that new transaction as unprocessed?
- How does this new data spread through the network?

2. Downloading the Blockchain:
- When my client (node) requests pieces of the blockchain (from my node's peers), how does this play out?

3. Mining and New Blocks:
- For mining, from my understanding, miners gather all unprocessed transactions to form their latest block submission (is this wrong?).
- Are these transactions just floating around the network, not in a block yet, where miners can (via their node) pick these TX's up and use those TX's to form their next block submission?

4. Do Nodes Request More Peers from other Peers?
- So do nodes ask other peers for their peer list, to expand their own peer list?
- In other words, is it self expanding, or do I have to manually add more peers?

5. Is my Node Being Sent New Transactions (that are not processed)?
- So is my node being sent the thousands of new transactions that have not been processed yet (i.e. put into a block)?
- Or is there something else happening here?

6. Right Now, What Data is Being Sent to My Running Node?
- So what data right now is being sent to my node (I'm running the standard Bitcoin WIN Client/Node), I know there is new blockchain data, but what else?

7. Is there Any Know P2P Structures that Bitcoin is modeled after?
- What P2P structure is Bitcoin modeled after, is it like a gossip style model or something else entirely?


I know there is a tone of questions here, but if anyone can answer any, that would sure help me better understand the P2P layout of the Bitcoin protocol.


Cheers,
Nick.

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.

Where in the Bitcoin wallet code is the 40byte restriction for OP_RETURN transactions enforced?

So far, I've found material in the code on lines:
328 **src/script/script.h
, 678 **src/main.cpp
, 57 **src/script/standard.cpp

Is the 40byte restriction enforced in the code, or is there something I'm missing here?


... Answered my own question again... I think I found it here:
https://github.com/bitcoin/bitcoin/pull/3737/files


For anyone else who wants to read about OP_RETURN, this post was pretty sweet:
http://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like


Cheers,
SC.


References:
https://github.com/bitcoin/bitcoin/search?utf8=%E2%9C%93&q=OP_RETURN
https://en.bitcoin.it/wiki/Script
http://coinsecrets.org/
http://bitcoin.stackexchange.com/questions/23024/op-return-data-transaction

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.

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

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.