Max number of transactions one node/connection can make to the network?

[JamesHunt]

Just a quick question regarding the bitcoin protocol,

I was contemplating making an altcoin for a school project, idea is initializing addresses with 1 coin balance to start, and people would 'mine' by generating addresses and sending those coins back to another address -their main address.

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?

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?

Any discussion would be greatly appreicated, thanks.

[1715370626]

1715370626

[1715370626]

1715370626

[1715370626]

1715370626

[grue]

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.

[cr1776]

Just a quick question regarding the bitcoin protocol,

I was contemplating making an altcoin for a school project, idea giving every possible address 1 coin to start, and people would 'mine' by generating addresses and sending those coins back to another address -their main address.

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?

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?

Any discussion would be greatly appreicated, thanks.

Just remember "every possible address" is a huge, practically incomprehensible, number. 

Good luck with the project.  ;-)

[JamesHunt]

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!

[grue]

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?

how exactly do you plan to distribute the coins to addresses? if they're issued by you, that would limit the transactions to the amount of coins in circulation. however, how do you plan to distribute the coins to the addresses? what's preventing people from generating millions of address to get extra coins?

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?

spamming invalid transactions will lead the other peer to disconnect and ban the misbehaving peer.

[JamesHunt]

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?

how exactly do you plan to distribute the coins to addresses? if they're issued by you, that would limit the transactions to the amount of coins in circulation. however, how do you plan to distribute the coins to the addresses? what's preventing people from generating millions of address to get extra coins?

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?

spamming invalid transactions will lead the other peer to disconnect and ban the misbehaving peer.

I assumed I could just make a clone but change the protocol slightly, so all addresses start with 1 instead of 0. However, obviously I can't do this to just a fraction of addresses -and I certainly can't do it manually! I'll have to think about that. -And yes, that was the flaw I was thinking with this coin, how to stop people generating in mass amounts!

Ban idea is good, however just realised won't solve my problem unfortunately. The 'miners' could easily just check the balance of the generated address first instead of push a potentially invalid transaction, might slow them down slightly -but half of 1000's tps is still to much. Thought I had a solution then, back to square one Getting abit out of my depth here but I assume the only solution would be to artifically slow down generating addresses, which would mean... alot of crypto work lol -Think i'll do another project!


EDIT: Wait, how does the network know who to ban? You said earlier there's no way to differentiate who sent the transaction (Sorry if i'm being naive)

[grue]

EDIT: Wait, how does the network know who to ban? You said earlier there's no way to differentiate who sent the transaction (Sorry if i'm being naive)

only valid transactions are relayed. thus a bad peer can only send bad transactions to its immediate peers.