However I was wondering, would it be possible to implement a limit on how many transactions 1 node/connection can make to the network? Or would there be no way to do this, and my coin would be broken due to thousands of transactions per second coming from 'miner' nodes? -Maybe there is a computational issue with this idea anyway, would one node be even able to send out that many transactions anyway?
no, because nodes relay other nodes' transactions. there's no way to differentiate whether a transaction was generated by the node itself, or another node that the node is relaying for. not to mention the issue with dynamic IPs.
I've had a little look at the bitcoin wiki and it states currently it can handle 7tps, what happens to other transactions, big queue? Would the queue getting huge cause no problem or can it cause problems? Would a change to the codebase be able to fix this? (Add a limit to nodes max tps) like I said above, is this possible?
the lowest priority transactions (lowest fees) will sit as unconfirmed and eventually will be forgotten.
Hmmm, thanks for clarification and ah yeah I see what you mean with point one.
Quick related question, let's say I change my idea to only give <1% of addresses 1 coin to start with (Implementing this we'll pretend is already done!). Would that solve my issue with thousands of transactions? -As now instead the 'miners' would spam 1 coin from addresses they generate, but only a fraction will have that 1. So only a fraction of transactions will be valid, less tps for the network correct?
Does a huge amount of invalid transactions weigh down a network? How does bitcoin stop someone sending millions of requests for sending coins they dont have, or is it (DDoS) a none issue?
Thanks once again, and sorry if i'm being unclear.
EDIT: @cr1776 yeah I know i'm underestimating that part, I wanna think about logistics later, -solve underlying issues first!