Thanks to people who support 1-2 MB blocks - great idea u fools...

[adamstgBit]

the Holliday paradox, its a thing now.

[1714623515]

1714623515

[1714623515]

1714623515

[1714623515]

1714623515

[1714623515]

1714623515

[brg444]

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.

[adamstgBit]

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.....

http://gavintech.blogspot.ca/2015/09/how-efficient-is-bitcoins-gossip.html

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.

https://en.wikipedia.org/wiki/Gossip_protocol

Due to the replication there is an implicit redundancy of the delivered information.

"sorry I was wrong"

[brg444]

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.....

http://gavintech.blogspot.ca/2015/09/how-efficient-is-bitcoins-gossip.html

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.

https://en.wikipedia.org/wiki/Gossip_protocol

Due to the replication there is an implicit redundancy of the delivered information.

"sorry I was wrong"

OMG you still don't get it 

[adamstgBit]

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.....

http://gavintech.blogspot.ca/2015/09/how-efficient-is-bitcoins-gossip.html

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.

https://en.wikipedia.org/wiki/Gossip_protocol

Due to the replication there is an implicit redundancy of the delivered information.

"sorry I was wrong"

OMG you still don't get it 

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.

[brg444]

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

[brg444]

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?

[adamstgBit]

Holliday's paradox.

new thread? 

[adamstgBit]

http://gavintech.blogspot.ca/2015/09/how-efficient-is-bitcoins-gossip.html?showComment=1441906719340 is a few days old with a comment made on this this morning.

calling me an idiot for suggesting there maybe some inefficiencies in this aspect of bitcoin, and then point to an article recently posted exploring this possibility, hard qualifies as proof that i have no idea what i'm talking about.  

[brg444]

http://gavintech.blogspot.ca/2015/09/how-efficient-is-bitcoins-gossip.html?showComment=1441906719340 is a few days old with a comment made on this this morning.

calling me an idiot for suggesting there maybe some inefficiencies in this aspect of bitcoin, and then point to an article recently posted exploring this possibility, hard qualifies as proof that i have no idea what i'm talking about.  

Must be heavy lifting these goal posts 

[adamstgBit]

perfect avatar for you sir.

[brg444]

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.

[adamstgBit]

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.

 

I ran the reference implementation inside a virtual machine on the main network, and measured overall bandwidth usage (using 'iftop'). Preliminary results (I need to run longer tests, and make sure the numbers are repeatable -- contact me if you'd like to help):

Node with 1 outgoing connection:
11.1MB in 3567 seconds

Average block size over the last couple of days is close to 0.7MB, so in the hour I was running that test I'd expect about 4MB of transactions and blocks, or 8MB total. There's 50% unexplained overhead on top of the 100% overhead we get from transmitting transaction data twice.

Node with 8 outgoing connections:
28.8MB in 6392 seconds

That's not terrible, but not great-- eight times the number of connections meant about 50% more bandwidth use. If a simple flooding algorithm was being used ("get data, send it to all of my peers") the bandwidth usage would be seven times the 1-connection case. But a more efficient rumor-spreading protocol could drop that per-peer overhead down very close to zero.

[adamstgBit]

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.

[brg444]

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.

[QUEDOS]

The blockchains cartography is fine and is obviously the most critical element to BTC's security and overall success.

The Holiday paradox might have a lot to do with the way the network propagates messages.

[adamstgBit]

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.

well that's noble of him, but i still think it's not ideal to get into situations like this by default.

now we have Holliday not wanting an increase in block size because he thinks bandwidth cost are already to high. and  they are to high for him, the system is abusing his node simply because it behaves properly.

ideally nodes will all bear the load together and ideally the  gossip network will do what its supposed too:

Each peer will communicate 503 bytes of data to get a 500 byte message to everybody in the network.

would be nice to actually get these kind of results in paritice.

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.

at this point Holliday would be OK with a much bigger block size.

another thing to explore is improving block propagation.

my crazy theory says that if it's all optimized to the max a home computer with a typical connection will be able to run on the network up to 2-5 thousands TPS

I could go as far as saying that we do not want nodes with more than a few peers like Holiday's 60+ peer node, because if he turns evil he could confuse a lot of nodes.

[brg444]

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.

[brg444]

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.

[iCEBREAKER]

Congratulations, you win today's Internet.