Super node

[BioMike]

I've seen in some topics people mentioning super nodes. Just curious... how do you get a super node? Is it just heaps of bandwidth and cpu power, or does the program need to be compiled in some special way (compile flag)? I've also been unable to find something like that in the documentation. And is someone actually running a super node?

[1714105138]

1714105138

[1714105138]

1714105138

[1714105138]

1714105138

[FreeMoney]

I'm not sure, but I think it's a future thing and/or just means lots of connections and connected CPUs for faster hashing.

[BioMike]

Well I saw it mentioned in the network split topic and from what I think it is, it is not for faster hashing, but to increase reliability of the network.

My current client shows 17 connections, but I've had times that I had more. So can I assume that this is the current size of the network? And if not, why aren't there more connections made (like I had before)? (I forwarded the port to this system, so it is not the router that is in my way.)

[tcatm]

The client only connects to some of the other nodes. There's no need for more, because it's a mesh network. More connections would be a waste of ressources as your gateway has to track all of them. Bandwidth would also increase as supernodes would send a lot of unicasts. In a mesh it's more like a broadcast as information is relayed and distributed from node to node.

It doesn't affect your hashrate at all.

[BioMike]

Ok, thanks for the explanation.

[Tilka]

"Supernodes" with lots of connections would be useful in scenarios where a buyer gives the seller control over some money and the seller needs to quickly send the transaction to a lot of nodes to make it sure the buyer has a very dim chance to double-spend the money before a block containing it is generated.

[tcatm]

Tilka: That's already the case with the mesh concept. Instead of one "supernode" sending the transaction to every other node you have many nodes sending the transaction to many other nodes which is much faster.

[omegadraconis]

I was the one who suggested the term super-nodes, knightmb was the one came up with the idea of removing the connection limit and tested it. The primary idea I suggested for them was to a have a group of super nodes that would still participate in the mesh network but, would allow for 1000+ connections and maintain a connect to the other super nodes. My hope was that if we distributed them around and kept them connected it would help prevent splits. Most other p2p style systems that use them (skype does, Tor exit nodes are kinda like super nodes), use them to allow clients from behind a firewall to connect out to the rest of the network. My guess, because I don't know if we have a way to tell or not, is that the mesh network is pretty well distributed.

The only way to get a super-node is to build it yourself from source. The connection "limit" (it's not a hard limit) is found in the net.cpp source file. knightmb tried it and got up to around 7100+ connections. He said it didn't really do much in the way of hurting his cpu but, bandwidth went up a large amount as did ram usage. Heres the quote:

I can already tell you, it has almost no impact on the CPU, it will shave off some khash/s, but the big difference is bandwidth and memory.

When running the program by itself (8 connection limit), you'll use between 16 and 28 MB of RAM for the program, 300MB a month for bandwidth (24/7 operation basically)

When you run *nearly* unlimited connections, the memory usage jumps up to about 128MB of RAM, bandwidth usage also jumps way up as well to where you are using 100MB in a day instead of a month.

Truthfully though, for a "super node" as you've now coined it  it's not really that hard spec wise for any server to handle, my old celeron server could easily handle this kind of load if it was shaved down to just a few thousand connections.

If you do want to run a super-node I recommend that you have a fast connection, a decent router (probably something better then your off the self linksys), and either a static ip or dual wan.

[aceat64]

If I was to quadruple knightmb's bandwidth numbers that's about 40 kbps, which is actually pretty low for a server. I'll convert one of my nodes over to a "super-node" and try it out.

[BioMike]

Indeed, these numbers are lower than I expected (except for the amount of connections, 7100+ seems pretty high).

[knightmb]

Indeed, these numbers are lower than I expected (except for the amount of connections, 7100+ seems pretty high).

It takes a loooong time to get up to that many connections (days) because it depends on how many other peers the other clients are looking for an open connection for.

[RHorning]

Just wondering out loud, but would a super node have a higher likelihood of "collecting" more transaction fees?  More connections == more nodes that might have "work" to do in terms of processing transactions.

I certainly see this as a "public service" that can help to flatten the network and in general reduce latency for everybody, so I don't mind that there might be some financial benefit for doing something like this.  Clearly those with a higher bandwidth are committing some substantial resources by doing this, so it isn't without cost.

[FreeMoney]

I've never had a transaction not go in the next block, so doesn't that mean everyone is hearing of all transactions?

 

[omegadraconis]

Just wondering out loud, but would a super node have a higher likelihood of "collecting" more transaction fees?  More connections == more nodes that might have "work" to do in terms of processing transactions.

I certainly see this as a "public service" that can help to flatten the network and in general reduce latency for everybody, so I don't mind that there might be some financial benefit for doing something like this.  Clearly those with a higher bandwidth are committing some substantial resources by doing this, so it isn't without cost.

Bitcoins is setup so that you get no fee's for any transactions, unless the transaction is less then 0.01BTC which was added to prevent spamming of small transactions. If a super-node is going to cost you more $ in bandwidth then don't run a super-node.

As far as I understand it everyone should hear all transactions eventually but, not instantly. If it was instant everyone would confirm the transactions right away. The transactions all take time a little time to flow through the mesh network. Running a super-node might make that a little faster because you are announcing the transaction to more clients a one time.

[knightmb]

Bitcoins is setup so that you get no fee's for any transactions, unless the transaction is less then 0.01BTC which was added to prevent spamming of small transactions. If a super-node is going to cost you more $ in bandwidth then don't run a super-node.

As far as I understand it everyone should hear all transactions eventually but, not instantly. If it was instant everyone would confirm the transactions right away. The transactions all take time a little time to flow through the mesh network. Running a super-node might make that a little faster because you are announcing the transaction to more clients a one time.

As far as I can tell, the supernode is just another node like any other, but has more connections to other nodes (instead of trying to keep around 8 or so). The only thing that offers is redundancy and faster coin spending. It won't speed up confirmations.

In the first case, redundancy; just means all the nodes it's connected to will have at least one node that remains connected all the time. As people open and close their bitcoin client, your client is constantly losing and making new connections to other nodes. Being connected to a super node means it's just one less connection for your client to find if it has less than 8.

Second case; it also works as a shortcut across the swarm if your client and the client that you are sending coin to, happen to share. So if you are 12 node points away from the person you are sending coin to, there will be a little delay before the transaction broadcast goes through. If both are connected to the super node, then it's less metric distance for the transaction to travel. So it might or might not allow faster transaction time, there are many factors to consider for that part (ping, real world distance, etc.)

I think an unconfirmed third point is it helps the network maintain honesty among the nodes in regard to keeping every other node highly connected. Super-nodes are just really clients willing to connect as many nodes that will accept, network together. So it's willing to do a lot of work for the other nodes in a more active role than a passive role.

They certainly aren't necessary for BitCoin to work, but they do provide a benefit and every little bit helps.

[RHorning]

Bitcoins is setup so that you get no fee's for any transactions, unless the transaction is less then 0.01BTC which was added to prevent spamming of small transactions. If a super-node is going to cost you more $ in bandwidth then don't run a super-node.

I hope that is wrong, as it discourages micropayments and provides a roadblock to deflationary currencies.  So many have been bragging about the nine decimal point expansion to be able to accommodate a huge deflation where you could perhaps eventually buy an automobile for 0.0001 bitcoins.

From what I understand, the role of transaction fees is in the consolidation of multiple blocks of coins and processing more than a relatively small packet when sending or receiving coins.  This is showing up when people are spamming with thousands of tiny payments as it is creating a whole bunch of blocks that need to be processed, but you aren't penalized when you are sending a small amount with just a couple of transactions.  It is the act of combining a large number of small transactions that adds up, and is a function of your wallet in terms of where those coins come from that are combined when a transaction happens.

Mind you, something similar happens in a bank with other currencies, where sometimes a fee is assessed when you are running a huge pile of coins through a coin counter or heaven forbid ask a teller to count the coins by hand.  Back when I was a kid delivering newspapers, I did that more than a few times with roughly 20-30 pounds of coins in each session.  Normally equipment to do that is for people running vending machines or a video arcade where large numbers of coins come into use during the operation of the business.

Right now most people have huge coin blocks (usually the 50 BTC that are originally generated) and sending a part of that block to somebody else.  You aren't seeing the consolidation transactions right now because few people are in need of the services that combine multiple small pieces into one larger transaction.

I'm not familiar with the fine points of the process, but it is neighboring nodes that do the combining and transmit that combined "coin" to the rest of the network.  Some people have already received some coins through that process.

[omegadraconis]

From the thread here: http://bitcointalk.org/index.php?topic=287.0

main.h:        // To limit dust spam, require a 0.01 fee if any output is less than 0.01

The general idea seems to be that once a BTC is worth more they can change this value.

lachesis points out that:

I think a 0.01 BTC minimum send is fine for now. At the current exchange rate, that's 8/1000 of a penny USD, or 80 millionths of a dollar. Any micropayment smaller than that would not be made one at a time....

I'm not aware of any other transactions fees but, I am not the expert by any means...

[Insti]

RHorning I think you need to do some more reading up on transaction fees.
http://www.bitcoin.org/wiki/doku.php?id=transaction_fee is a good place to start.

Topic: Flood attack 0.00000001 BC is another thread worth reading.

[RHorning]

RHorning I think you need to do some more reading up on transaction fees.
http://www.bitcoin.org/wiki/doku.php?id=transaction_fee is a good place to start.

Topic: Flood attack 0.00000001 BC is another thread worth reading.

If that is the case, I would argue that it should be stripped from the specification for all of the reasons suggested in the threads about deflation.  It doesn't seem logical except strictly to stop a flood attack, and with the increase in value for Bitcoins I certainly can see the potential for when this would be a rather significant fee.  At what point should this be moved to 0.001 bitcoins or something smaller?

It just seems like a very arbitrary value that was put into as a "magic number" that made sense only because at the time it was put into the code that it seemed like such a small value that nobody would reasonably be wanting to logically be sending money in denominations smaller than that amount.  At least be logically consistent here when it is said that Bitcoins are "infinitely scalable" to any size of economy, and that at the same time it isn't.

A flood of transactions all from the same node, perhaps, ought to be charged transactions frees, or perhaps the whole system ought to be rethought.  There are other solutions to this problem, and this seems like a temporary stop-gap solution that wasn't thought through all that well.

[aceat64]

RHorning I think you need to do some more reading up on transaction fees.
http://www.bitcoin.org/wiki/doku.php?id=transaction_fee is a good place to start.

Topic: Flood attack 0.00000001 BC is another thread worth reading.

If that is the case, I would argue that it should be stripped from the specification for all of the reasons suggested in the threads about deflation.  It doesn't seem logical except strictly to stop a flood attack, and with the increase in value for Bitcoins I certainly can see the potential for when this would be a rather significant fee.  At what point should this be moved to 0.001 bitcoins or something smaller?

It just seems like a very arbitrary value that was put into as a "magic number" that made sense only because at the time it was put into the code that it seemed like such a small value that nobody would reasonably be wanting to logically be sending money in denominations smaller than that amount.  At least be logically consistent here when it is said that Bitcoins are "infinitely scalable" to any size of economy, and that at the same time it isn't.

A flood of transactions all from the same node, perhaps, ought to be charged transactions frees, or perhaps the whole system ought to be rethought.  There are other solutions to this problem, and this seems like a temporary stop-gap solution that wasn't thought through all that well.

It really is fine for now, if it becomes an issue future clients will have a lower fee (if any). If you choose not to pay the fee the only thing that happens is that nodes who charge that much will not include your transaction in their blocks. Really, only one node needs to have that fee removed and sub-0.01 transaction will go through, although you'd have to wait until that system generates a block. So those super-small transactions would sit at 0/unconfirmed for a while, but once it got into a block every block after that would count toward it's confirmations.