BTW, it currently costs $60 a month to run a full node on a dedicated Microsoft Azure VM. This includes virtual hardware (includes 1 dedicated CPU core) and bandwidth, which is around 600GB a month (mostly outgoing). It is not quite "free" anymore.
By the way, has any of you guys considered running a full node in the cloud, as Soros Shorts suggested above? Would that solve the problem for at least 8MB blocks? Just wondering... Running a full node "in the cloud" defeats the whole purpose of running a node which is to be independent. |
|
|
|
Bitcoin is first and foremost about censorship resistance and decentralization. The rest is bells and whistles.
Everyone needs to understand that. Time to put this back in my sig. Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency - Jon Matonis 2015if you can trade off a small amount of decentralization for a large gain in efficiency... it's not so clear cut. You're trying to install trusted centralized nodes in the system, gtfo  Bitcoin will scale beyond its blockchain. Stop trying to figure out ways to break it. a centralized source of download bitcoin   |
|
|
|
Bitcoin is first and foremost about censorship resistance and decentralization. The rest is bells and whistles.
Everyone needs to understand that. Time to put this back in my sig. Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency - Jon Matonis 2015if you can trade off a small amount of decentralization for a large gain in efficiency... it's not so clear cut. You're trying to install trusted centralized nodes in the system, gtfo Bitcoin will scale beyond its blockchain. Stop trying to figure out ways to break it. |
|
|
|
The issue you only now realize is the lack of well connected peers throughout the network.
The solution is more full nodes.
Surely you also now understand raising the block size is not ideal nor desired as it stands.
as it stands, no i am forced to conclude raising block limit any higher then a few MB's will start to cost to much in terms of bandwidth for home users to stay online. with optimizations, i believe 500MB block limit will be the absolute limit for most home users.
i think gavin banking on tech improving enough to allow for GB blocks in a matter of years is very optimistic. maybe he doesn't care too much that full nodes no longer run on home networks....  Optimizations like everyone running SPV I suppose.... Again, you can "optimize" overhead and inefficiencies, but you still have to communicate the whole block of data. There's no way you get around that. no no no simple shit like : 1) making sure the gossip network actually does make every peer on average use 503Bytes to get everyone to hear about a 500Byte msg. 2) communicate new blocks by listing all the TX ID's in that block instead of in full. 3) has SOME trusted centralized nodes dedicated to allowing new nodes to sync fast ( probably don't even need to trust them using some fancy PGP or something)
4) and yes some SPV, and maybe different types of nodes, simi-full node, full node, super node, minner node.
wtv it takes. Yes, your intention are clear. Diverge from the trustless decentralized model of Bitcoin to accomodate more spam. Hopefully you sell your coins so we can be done with people like you and move away from such toxic attitudes. If it ain't broke don't fix it. |
|
|
|
The issue you only now realize is the lack of well connected peers throughout the network.
The solution is more full nodes.
Surely you also now understand raising the block size is not ideal nor desired as it stands.
as it stands, no i am forced to conclude raising block limit any higher then a few MB's will start to cost to much in terms of bandwidth for home users to stay online. with optimizations, i believe 500MB block limit will be the absolute limit for most home users.
i think gavin banking on tech improving enough to allow for GB blocks in a matter of years is very optimistic. maybe he doesn't care too much that full nodes no longer run on home networks.... Optimizations like everyone running SPV I suppose.... Again, you can "optimize" overhead and inefficiencies, but you still have to communicate the whole block of data. There's no way you get around that. |
|
|
|
so in the end if we have 1MB blocks floating around we'd expect each peer to use ~1.1MB of bandwidth every 10mins for TX propagation.
No, a node needs at least 8 peers to serve its purpose well. If it doesn't the messages risk not being propagated fast enough throughout the whole network. Do you understand the word "overhead"? The gossip broadcasting still has to occur between peers and it is valuable for them be well connected. Stop being under the impression that you are somehow onto novel ideas, you really think too much of yourself. It is possible to have very low average connectivity and still have a topology that has a small diameter. An extreme example would be a star topology with one node having N -1 connections to the remaining N - 1 nodes, each of which had a single connection. There would be an average connectivity of about two and transmission would be fast (2 hops). The most efficient topology (based on propagation time) will be a function of the bandwidth of individual connections and individual nodes. Using random connections will not be optimal if there is a wide disparity in node performance and network bandwidth. There are other possible optimizations that will minimize the effect of multiple hop transmissions, particularly of large blocks. None of these ideas are new, having been well understood in the area of computer networking for decades. The unique difficulty where bitcoin is concerned is the absence of any central network management and the need to operate under denial of service attacks. I'm well aware of that but for Bitcoin to remain robust there is a certain minimum to achieve. |
|
|
|
|
The issue you only now realize is the lack of well connected peers throughout the network.
The solution is more full nodes.
Surely you also now understand raising the block size is not ideal nor desired as it stands.
|
|
|
|
so in the end if we have 1MB blocks floating around we'd expect each peer to use ~1.1MB of bandwidth every 10mins for TX propagation.
No, a node needs at least 8 peers to serve its purpose well. If it doesn't the messages risk not being propagated fast enough throughout the whole network. Do you understand the word "overhead"? The gossip broadcasting still has to occur between peers and it is valuable for them be well connected. Stop being under the impression that you are somehow onto novel ideas, you really think too much of yourself. |
|
|
|
after reading the not so conclusive *part1* report on this:
it seems there is some coding gain to be had here, at least it's worth a look, but there's no doubt Holliday's paradox has probably more to do with nodes constantly using him to sync up there blockchain
which begs the question, shouldn't most nodes always be up and never need to catch up there blockchain?
maybe alot of nodes do as my friend dose, which is come online once in awhile simply to catch up and then go offline, this behaivor is detrimental to the network, and needs to be somehow dealt with and or mitigated.
I don't think this has much to do with what you describe. The reason why Holliday's node bandwidth use is important is because of how well connected it is. It simply follows that he hears about a transaction before other less connected nodes and therefore has more people leeching off his transaction data. He doesn't have to bear this weight but he apparently chooses to do so for the service of the Bitcoin ecosystem. |
|
|
|
perfect avatar for you sir.
 Executive summary: gossip networks can scale up nicely with the number of peers in the network; in theory, each of the n peers in the network will receive all b bits in the messages, plus communication overhead that scales nicely. For example, a gossip network with 10,000 peers that is sending 500-byte messages, the theoretical upper bound on communication overhead for each message is lg lg 1000 * lg 500*8 or 18.4 bits... less than three bytes. Scale up to a million peers and the overhead is 21.8 bits... still less than three bytes. For dummies: Bitcoin's broadcast protocol is quite efficient for the purpose it achieves. |
|
|
|
Must be heavy lifting these goal posts  |
|
|
|
|
There is nothing inefficient about Bitcoin's gossip broadcast protocol given the purpose it is trying to achieve.
There might be coding gains to be made but the network topology is fine and in fact critical to Bitcoin's security and overall success.
What is it 4 years now you've been doint this Bitcoin stuff and yet you had not figured this out?
Too busy playing in the speculation forum?
|
|
|
|
what you don't get is i'm trying to figure out what is causing the Holliday paradox, and suggesting it might have to do with the way the network propagates msg.
Maybe this will help: Standard relaying
When someone sends a transaction, they send an inv message containing it to all of their peers.
Their peers will request the full transaction with getdata.
If they consider the transaction valid after receiving it, they will also broadcast the transaction to all of their peers with an inv, and so on.
Peers ask for or relay transactions only if they don't already have them.
A peer will never rebroadcast a transaction that it already knows about, though transactions will eventually be forgotten if they don't get into a block after a while. inv - "I have these blocks/transactions: ..." Normally sent only when a new block or transaction is being relayed. This is only a list, not the actual data.
getdata - Request a single block or transaction by hash.
https://en.bitcoin.it/wiki/Network |
|
|
|
omfg you're some special kind of asshole. i'm saying the network's topology is inefficient and as a result when nodes relay TXs a node can get sent the same TX multiple times.
...
That's not how it works  Alot of bitching back and forth brg444 being rude as always..... OMG you still don't get it  |
|
|
|
if Holliday's node uploads content of a transaction to its peers it is because they DON'T know yet about the transaction. Clear enough?
what isnt clear is why we are asking Holliday to use so much bandwidth, and why the task isn't evenly spread out What is clear Adam is you have no credibility discussing these issues. It doesn't matter if you bang on tables and shout in every threads your opinion is as valuable as a 3rd grader telling rocket scientists how to build a spaceship because they saw it in the movies. People might avoid being rude because you're a nice little kiddo but your ideas will not be considered. |
|
|
|
and i'm saying the network's topology is inefficient and as a result when nodes relay TXs a node can get sent the same TX multiple times.
ex. 6 nodes get 1 tx to propagate, all 6 nodes send the tx to all 6 nodes, each node gets the same tx 6 times.
That's not how it works says you. which isn't reassuring. i'm under the impression the topology is laid out in a pretty random manner and peers blindly forward the TX to all the peers they are connected to. when Holliday gets a TX to forward, he's forwarding that TX to all 60 peers, which is why he's having bandwidth issues. No. Peers don't "blindly forward the TX to all the peers they are connected to". That's not how it works repeating that doesn't make it more reassuring. The purpose of my exercise is to get you to find the proper information so as to educate yourself. Start here: http://lmgtfy.com/?q=bitcoin+gossip+networkBTW I expect some kind of "sorry I was wrong" post next. nodes are semi-randomly connected to each other, and information (transactions, blocks, IP or onion addresses of peers, and, very rarely, alert messages) is flooded across the network. You noobs really need to get fed every answer heh. Here: A node learns about a new transaction, either from a peer or of it's own creation.
It announces to every one of it's peers (8+ typically) with an inventory message that it has learned about a transaction or block with a particular ID.
If the connected peer doesn't already know about the announced transaction, it sends a getdata request back asking for the contents of the transaction. If it already knows about the transaction, no getdata is made in response. To put into context: if Holliday's node uploads content of a transaction to its peers it is because they DON'T know yet about the transaction. Clear enough? |
|
|
|
and i'm saying the network's topology is inefficient and as a result when nodes relay TXs a node can get sent the same TX multiple times.
ex. 6 nodes get 1 tx to propagate, all 6 nodes send the tx to all 6 nodes, each node gets the same tx 6 times.
That's not how it works says you. which isn't reassuring. i'm under the impression the topology is laid out in a pretty random manner and peers blindly forward the TX to all the peers they are connected to. when Holliday gets a TX to forward, he's forwarding that TX to all 60 peers, which is why he's having bandwidth issues. No. Peers don't "blindly forward the TX to all the peers they are connected to". That's not how it works repeating that doesn't make it more reassuring. The purpose of my exercise is to get you to find the proper information so as to educate yourself. Start here: http://lmgtfy.com/?q=bitcoin+gossip+networkBTW I expect some kind of "sorry I was wrong" post next. |
|
|
|
and i'm saying the network's topology is inefficient and as a result when nodes relay TXs a node can get sent the same TX multiple times.
ex. 6 nodes get 1 tx to propagate, all 6 nodes send the tx to all 6 nodes, each node gets the same tx 6 times.
That's not how it works says you. which isn't reassuring. i'm under the impression the topology is laid out in a pretty random manner and peers blindly forward the TX to all the peers they are connected to. when Holliday gets a TX to forward, he's forwarding that TX to all 60 peers, which is why he's having bandwidth issues. No. Peers don't "blindly forward the TX to all the peers they are connected to". That's not how it works |
|
|
|
and i'm saying the network's topology is inefficient and as a result when nodes relay TXs a node can get sent the same TX multiple times.
ex. 6 nodes get 1 tx to propagate, all 6 nodes send the tx to all 6 nodes, each node gets the same tx 6 times.
That's not how it works |
|
|
|
tl:dr BTC velocity is high, other assets are likely better long term storage
 Where do you get this idea? |
|
|
|
|
Show Posts
