ugh, yes! Obviously this is a "not so common  " approach for me 
And I mean I even read, that OP_RETURN was changed to an 80 Byte limit, but I don't know where we are right now...

The bitcoin node has a set of pre-defined names in its initial installation. It would try to connect to one of these systems, and get further systems to connect to from there.
During initial sync you might not see many connections. When initial sync is done, you can see the system getting connected to 15-20 other systems, or even more. So a node does not "ensure", it is connected to all other nodes. Thats not how the system works.

And one more hint: several ports have to be opened on your router, so that incoming connections are allowed. If you haven't configured the router correctly, the system will not connect to more than 8 other systems.

it is difficult to know, what shall be programmed, if nothing is specified. I have created for my own usage a similiar, very basic tool for my OpenBSD (and probably other unixoide) system.
Questions I would have in mind:
- what device (iOS, Android, a normal PC, a web page ...)
- if PC, what operating system (MacOS, Linux, Windows, ...)
- what programming language do you use, or are there any preferences?
- a list of addresses (line by line), which has the corresponding value behind
- only bitcoins, or a set of several crypto currencies
- a graphical display, in a nice manner, or just a "text list"
- possibility to change the values, so a what-if scenario can be worked out
...

Maybe you can draw a sketch and some words around the ideas. I am sure this already exists, cause this type of request would not be the first n the crypto world :-)

I'd tend to say no, if you do it correctly.

Assume you created a first bitcoin address, and use it to receive funds from a person on a bitcoin event. Assuming you didn't show him your real ID, and no cameras and so on, then nobody knows, that this address is linked to your person. If you now spend these coins to buy a book in a warehouse, they will send it to your home address - and then at least "they" know the link. And police departments can ask the bookstore... This is an indirect link to your person.

Address reuse is the first bad thing you can do, which helps others to de-anonymize. As the blockchain keeps all transactions, you could be identified, if an address is found in the blockchain as part of a transaction, and KYI/KYC or s.th. similar to the bookstore example was followed. Large companies and for sure police departments try to run through this activity.

Re-using addresses not only helps to de-anonymize your ID, it can also have effects on other user's IDs privacy.
The bitcoin core wallet is never reusing addresses, and transactions have always new addresses for the change.
If you want to stay even more anonymous, you may want to look into mixer services.

DONT'T REUSE ADDRESSES, its bad for privacy.

 

I don‘t get the mixture between hashes and index. Maybe I am missing something?

The previous transaction is found by giving it‘s hash, and the outpoint to spend from is given as a number starting from zero. So both are pointers into a previous tx, as opposed to providing the whole data structure of a previous tx, which saves a lot of space... and one could call this a reference?

On addresses it is clear, that we talk about data representation. The bitcoin address is derived from the public key via some conversions and mathematical functions, which are not (as per today‘s knowledge) reversibel.

So when it comes to data for the input, it can be considered a reference, whereas the bitcoin addresses don‘t appear in a tx, only it‘s pubkey or the hash of it. They are not references in this sense.

As per my comment on bitcoin.SE (https://bitcoin.stackexchange.com/questions/76982/bitcoin-testnet-transaction-getting-dropped-with-prefix-on-s#comment88834_76982), also the sources for checking the signature are here:
https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L97
Though not clear where the code -26 comes from...

For the bitcoin blockchain, the short answer is „no“

There are two common approaches to store data, one is with OP_RETURN, allowing for 40 bytes to store in a transaction, and then one can create a P2SH transaction, allowing for roughly 500 Bytes.
As you can see, the amounts of data are not too big, and each transaction has costs (fees), so it doesn‘t make sense.
I recommend to have a look at SIA or STORJ, to store large amount of data (files),or even at factum. The first two create hashes of a data set, that are stored. And Factum is to prove, that a set of documents exists. You find the details and n there webpages...
A similar discussion just happened here: https://bitcointalk.org/index.php?topic=4554177.0

yes 
because all the negative messages haven't realized in the last ten years. Easy as this.
Detailed answers to your statement can be found with a search in the forum.

Wrong usage of an application (PIN number) is not a bitcoin issue - you could do the same with any other software (or online banking).
Power consumption was discussed in epic length.
I think it will not surpass US energy consumption, cause US is still country with highest waste and outdated infrastructure.

Virtual Box is a software, that allows to emulate a PC within your PC. It is extremly useful for development, e.g. having Mac OSX and then get it Linux or OPenBSD installed inside Virtual Box.
Inside this operating system you can then play with many different tools or wallets, and best thing is you can have several virtual machines in parallel, so you can even setup your own little data center, to verify communication between systems.
So yes, very useful for bitcoin development.
More info on virtul box here: https://www.virtualbox.org/

Yes, I agree to this point of view. I was thinking in the sense of being „just a good citizen“, and using the blockchain only for monetary transactions. And everyone would do so (be a good citizen). And then someone finds out, that you can store data in the blockchain, it get‘s known to the broader community, and suddenly we can‘t transact monetary values any more, cause the system is flooded with data. This would be a denial of service (attack or spamming?). So better we know early about this, than too late. Hence important to shed light in every unknown area.
But never mind, Bitcoin is doing good for ten years now, and everything it proved to be resistant 

Because it is sexy to start with the two most complex topics in computer world: cryptography and blockchain technology. 
Artificial intelligence is just a combination of many (very fast) “what-if” connections. This is really lame.But with Crypto and blockchain: one could go to all the friends and say “look what I have done”, and maybe have all the girls in your lambo?

Going into s.th. like a “play” mode (or for learning purposes) must not reveal anything useful. Too many inventions were found by accident (or in play mode, because it is fun - look at Crypto kitties on Ethereum - what would be the answers, if someone asked at the beginning, if implementing a Darwin model for virtual kitties on a payment/smart contacts platform makes sense?)

Probably OP’s idea involves a deep learning curve, but as it is not about money, we can strike out two years of intense data security knowledge.

I disagree to the statement, that (bitcoin’s) blockchain is best use case for storing files. It is simply too expensive, to store data.
I think it’s not about abuse or reading more. This type of discussion is controversial. On the other hand side, if the opportunity exists, to use the blockchain in a different way, then possibilities should be explored. From a security point of view it doesn’t make sense to say “it is possible, but do not use it”.

The bitcoin blockchain has already data stored in it, and a typical way to do it is using OP_RETURN, with 40 and/or 80 bytes limit. So you would have to create many transactions, to split the file over the transactions.
An alternative approach is to create a P2SH tx, which allows for ~500 bytes. Then again, splitting the files and creating the many tx and paying the fees doesn’t make it a good opportunity. One can clearly see, that bitcoin blockchain is not designed to store data.
Hence the proposals to use a bridge to another system, or going directly to Factum, SIA or STORJ. Hopefully bridges will come into play one day.

I was trying to follow the math as well, but didn’t get it. Maybe due to my limited understanding of making a very easy bitcoin calculation so difficult in formulas 
I tried to reverse the idea, and think about attack vectors and the validation of the system (nodes validations and miner validations, where a single wrong tx makes also end up in an invalid block, destroying potential revenues). There is no view on this “from the bottom”, instead it postulates a model, and derives “limits of blockchain”. Without links to reality. So I believe it is a speculative paper to prove at a “scientific” level, that bitcoin cannot scale. And this smells like fiat banks or big blockers behind the paper...

As a non statistician or economist I have my own critique to this paper, and I get the feeling it is trying to ride the waves of bitcoin, but the system is not completely understood, or it is riding the waves of big blockers. It starts at the very beginning with a phrase like this:

The role of non mining (full) nodes is not covered here... without the relaying nodes an important part for the security of the bitcoin eco system is missing in the equations (remember last year, when miners wanted to have 2mb blocks, and UASF prevented this?)

Further down the text we are informed about a misnomer:
WoW! Hats off! Fantastic, for an economic paper on bitcoin we learn s.th.about the usage of the word « double ». What do these guys think they are?

Next quote:
Who would have guessed it? So the creation of the word « per block payment equilibrium » is no misnomer, and economical incentive to drive an attack must be way higher than the block rewards? Is this the essence of the paper?
Doesn’t this smell like big blocker arguments? This continues on page 8, where a 30% tax is derived. Funny.

Further on page 11 we find several attack scenarios, with varying assumptions. At the end follows a conclusion which states that decentralized trust is ingenious, but expensive. Followed by a derivation, that  a high level of trust requires high running costs of the blockchain relative to the amount for attacking the system. As if the scenarios haven’t been discussed up and down in the relevant forums.

The whole paper relies on some mathematical models, which are based on someone’s imagination, and achieve a certain level of complexity. Ok. But the assumptions haven’t been checked against any period of the ten years history of blockchain, e.g. why was blockchain not attacked? How is blockchained secured by technological progress through history? What is the incentive model for the attacker at specific periods in time? ... This could proof relevance and applicability of the text... as there is no such thing, it looks like an ivory tower model, that fails to link to reality. And the conclusions are well known facts - blockchain is expensive, and attacking it requires enormous amounts. And the economic limits, as found in the headline, are not calculated. Btw: is it on purpose that Lightning is not mentioned at all? Because it doesn’t fit in the 30% tax model?

I am missing relevance in this text.

Summary: there is no generic rule - one would need to understand the way, how the initial load of the blockchain works :-)
There are too many variables. One would have to setup a weighted matrix with all dependencies... hence you find only general info, like this:

With my bitcoin core node (a fully validating node), it fetches all transactions from it peers, and verifies the transactions for the correctness (see here: https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages).
This involves many, many lookups of previous transactions in the local blockchain, hence the dependency to the hard disk. I have had situations, where an SSD provided a times five speedup.
The calculations with a Quad-Core CPU is usually not a limiting factor, I had it running on a 4 years old Macintosh, and it never got limited. CPU calculations was always faster than data delivered from other peers.
On the bandwidth: I had a 10mbit/s connection, and did never run into congestion. Au contraire: I didn't have "enough" peers to send data continuously.
Then I did the opposite: I took a RasPI2+, attached it to a 2mbit line, and let it run 3 weeks, before he was nearly sync'd with the blockchain. And then it came into the time of full blocks (near the end 2017), and suddenly the RasPi would never completly sync. The CPU was probably too slow to verify the tx data, and the attached external disk (no SSD!) via USB could not cope with the amount of requests. I set up a monitor, and measured CPU, processes (load averages), disk I/O, network I/O... I could see that the disk I/O was not going down to zero a single time, and the load average never went under 1.0, it merely stayed between 3 and 4. So there were many processes in the working queue, that could not be worked on by the CPU, cause other tasks occupied it.

Summary: you have to have a setup, and measure all details.
I believe that core team does a similiar thing, and I recall they had a process setup, which (re-) loads the blockchain on a daily basis (to ensure correctness of the system). But I haven't seen any statistics.

Ok, just to understand further: your root is on one partition, containing e.g. /usr/local/bin, with the binaries of bitcoin, and there is a separate home Partition, which is mounted into root? Maybe show us fstab? And the full path to the bitcoin.conf file. And which user executes bitcoin-cli?
Btw: Ubuntu/Debian/SuSE/Redhat?
Who is running he bitcoin daemon? (Show how you started bitcoin...). Anything you could see in the log files? Is „ps aux“ showing bitcoind is running?
If testnet =1, then ports are correct (Default RPC connection port is 18332). However 8332 doesn‘t look like testnet, it would be mainnet. Maybe the executables don’t find the path to the correct conf file(s)...

In another thread OP is asking on cold storage. I think he wants to collect his coins on the live system, and when it goes over a certain threashold, move the funds to the cold storage. Similar as to what the exchanges would do with hot and cold wallets.
I had a similar setup with a mining provider. Every day or week I would receive funds from them. A part was used to buy beer  At a certain height, I pushed a part manually to my cold storage system.

Good, right approach. The cold wallet is only used to sign a transaction. You would not use the cold wallet to do things like „getbalnace“ or „sendtoaddress“.

The cold wallet will never connect to the internet, and will never download the blockchain. This means, you cannot check balances on the cold wallet.

The procedure to go would most likely look like this:
1. Create an address on the cold storage system
2. Bring this address into the second wallet, which is connected to the internet (the hot wallet, or the live system). As mentioned by Heisenberg_Hunter, make this a watch only address in the hot wallet. Then you can see at all times the balance on this address.
3. On the hot wallet you can now create a transaction, and save it as raw transaction on a USB stick or similar.
4. Bring the USB stick to your cold storage system, load the transaction into the wallet, and sign it.
5. After signature, store it again on USB stick, and bring it to the hot wallet system
6. send the transaction.

The procedures how to load addresses or save/export transactions vary from wallet to wallet.
Hint: you are already,playing with virtual machines, try to setup a test environment, and play e.g. with „regtest“, that will give you the opportunity to get familiar with the process, before losing anything on the live environment.

Andrew replied to it here:
https://bitcoin.stackexchange.com/questions/76121/how-is-the-leaf-node-weakness-in-merkle-trees-exploitable

Can you explain, what this means? Why is Turing completeness required to access data of previous transaction?
As achow pointed out, it is a limitation of the scripting language to access the internal data structures. And the Turing completeness is explicitly removed from bitcoin scripting, to also avoid security issues.