Stefan Thomas [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-04 🗒️ Summary of this message: The creation of ...

📅 Original date posted:2011-08-04
🗒️ Summary of this message: The creation of nodes/clusters accepting 10000+ incoming connections while making few outgoing connections could be an argument for double spend protection. The shortage of listeners may be due to the network consisting largely of end-users with residential type networks. In the long term, trends favor more clients allowing incoming connections. Policies to temp ban malicious nodes can be implemented.
📝 Original message:On 8/5/2011 12:18 AM, Gregory Maxwell wrote:
> Except for the fact that such a party is a DOS attack on the network
> which is already short on functioning listeners.

To the transaction radar it doesn't much matter whether its connections
are outgoing or incoming (assuming it can keep its nodes' IPs secret and
it has reasonable uptime). So you could say that this is an argument
*for* this kind of double spend protection if it means the creation of
nodes/clusters accepting 10000+ incoming connections while making few
outgoing connections. My point is, the amount of connections a node has
has nothing to do with its effect on the in/out balance.

Some words on the shortage of listeners itself:

Could this be because the network right now consists largely of end
users with residential type networks? With BitTorrent a lot of users go
through the trouble of opening up ports in their router manually in
order to get more peers and better download speeds - this is not (yet?)
a widespread practice with Bitcoin. (I know Bitcoin has UPnP support,
but I haven't found any numbers on how widely the IGD protocol is
actually deployed. Wikipedia says that "some NAT routers" support it and
that it's not an IETF standard. All routers I've actually seen in real
life had it disabled by default.)

In the long term all the trends favor more clients allowing incoming
connections: End users will tend to move towards lighter clients and the
ones that stick with full nodes will tend to configure them better -
meaning opening ports etc. - as documentation improves.

As for downright malicious nodes: It should be possible to come up with
some sensible policies to temp ban nodes that don't relay any useful
messages or try to flood you. This is an ongoing optimization problem in
any peer-to-peer network and I expect us to make progress with this over
time.


On 8/5/2011 12:16 AM, Matt Corallo wrote:
> This is exactly what I've been suggesting this whole time.

I had only seen you mention a "miner backbone" which is sort of a more
long-term vision, whereas Transaction Radar exists today. I didn't read
everything though, so if you mentioned this idea specifically, please
just consider my post as further support for your position.