Changing XT ver string to be the same as Core

[Mike Hearn]

The DDoS attacks launched from Russia are apparently now reaching the multi-gigabit/sec size. There is no way ordinary p2p nodes in any network can handle that: whoever is doing this is clearly going to erase XT from the internet in any way they can, and they will very likely succeed.

They could of course do exactly the same thing to Bitcoin Core nodes, but apparently they think they're "saving" Bitcoin by doing this, so I guess they won't.

I suggest therefore that the next release stop identifying itself as Bitcoin XT and (this will break Lighthouse) stop serving the getutxo message. This will make it indistinguishable at the wire level from Core.

We can keep track of how many XT nodes are out there by making it do a simple HTTPS request to a website hosted on infrastructure that can handle big DDoS attacks. The XT website is hosted on CloudFront but it is only doing static serving. That may be sufficient, with logs analysis, but I'd rather spend time on something else.

Thoughts? Does anyone have any good suggestions for where to run the version collector?

Of course this doesn't help mining pools. They would need to find ways to sink the DoS attacks themselves.

If there are any Russian speakers out there, trying to talk to this guy might help (and/or the local police - I'm told that they sometimes act if there are attacks against Russians themselves). I think Slush's pool got an extortion letter so they may have contact details.

[Tom Harding]

Any information published by a centralized service will not be very valuable.

Also consider that the ddos attacks hurt themselves.  Without them, only a failure of miner interest could explain a drop in bip101 block production.  As things stand, the ddos caused the drop.

--
You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Arnoud Kouwenhoven]

Mike,

Right now, changing the name to anything other than Bitcoin XT while leaving the services broadcast identical, seems to work. My node has not been attacked since I renamed it to something other than Satoshi and Bitcoin XT. The attacker most likely has a simple string pattern match on the client name field of the version message. For now.

Arnoud

[Mike Hearn]

Any information published by a centralized service will not be very valuable.

All existing stats graphs are published by centralised services. I think this is a red herring.

Right now the DoS attacks against nodes don't achieve much because BIP 101 is really triggered by miners, but obviously for the transition to be successful every node must be upgraded to BIP 101 eventually. So if that can't happen due the extortion attempt, BIP 101 cannot be deployed.

[Gavin Andresen]

On Thu, Sep 3, 2015 at 11:09 AM, Mike Hearn <he...@vinumeris.com> wrote:

Thoughts? Does anyone have any good suggestions for where to run the version collector?

No suggestion on where to run a version collector.

But the version collection code should also be "is an upgrade available" code, that just uses the existing tell-the-user-something-important codepath.

... which should eventually evolve into "download, check for valid signatures, and automatically upgrade" code (yet another feature that I think it is pretty clear people want that can't make it past the Core idea review process).

--

--
Gavin Andresen

[Jameson Lopp]

I don't think these attacks are bad enough to warrant such a fundamental change. I've been hit a number of times by them at my home but they haven't been able to sustain the attack. If a distributed set of nodes can't stay up against a single attacker, we have bigger problems to worry about and I don't think we should resort to hiding.

--

[Jonathan Mafi]

Hey,

I understand majority of the technical jargon but cant really help out. Was gonna say, keep going guys!! Sucks people are resorting to this.

I dont suppose from a pr perspective it would help to get this info out (info regarding the attacks i mean) if standard internet news feeds would take it that is. Might help put bitcoin xt in a more positive light...you know the "victim" here of these awful attacks bla bla bla lol. Just trying to think like the masses here :P

Jonathan Mafi Dip in Advanced 3d Animation
Director and Digital Media Artist at Spacifx Ltd

m:+64 22 6872914
w1: www.jmafi.com

w2: jmafivfx.blogspot.com

w3: www.spacifx.com

Please consider the environment when deciding whether to print this e-mail

CAUTION: This e-mail message and accompanying data may contain information that is confidential and subject to privilege. If you are not the intended recipient, you are notified that any use, dissemination, distribution or copying of this message or data is prohibited. If you have received this e-mail in error, please notify me immediately by return e-mail and delete all material you have incorrectly received. Thank you.

[Mike Hearn]

Jameson, I thought the same until today as the attacks seemed fairly small. But now we're seeing comments like these ones:

https://www.reddit.com/r/bitcoinxt/comments/3jg2rt/the_ddoses_are_still_real/cup43q7

https://www.reddit.com/r/bitcoinxt/comments/3jg2rt/the_ddoses_are_still_real/cup7hyo

https://www.reddit.com/r/bitcoinxt/comments/3jg2rt/the_ddoses_are_still_real/cup9nbl

My nodes got hit with 25 GBit/sec. The university firewall handled it like a pro, but I was forced to shut off my nodes. Due to the security implications (I guess DDoS attacks are a security risk now?) I'll have to fight to get them back up again.

25 GBit/sec is not survivable. The internet is just fundamentally broken in this respect - not enough ISPs have rolled out ingress filtering and there are too many UDP based protocols out there to really fix things at the application layer.

Bitcoin is in the unfortunate position that it's a volunteer system that runs on the open internet, unlike networks like SWIFT which require leased lines  (it's one reason why a SWIFT connection is so expensive and one reason for the high overheads of banks).

Sadly, I think these attacks can end in only three ways:

1. Everyone who runs XT is beaten off the internet and usage drops to zero, ending the project.

2. The attacker is found and jailed by the Russian police, ending the attacker.

3. XT becomes indistinguishable from Core, thus forcing them to stop (their motivation is they want to kill BIP 101)

Number (3) has the obvious problem that BIP 101 blocks must identify themselves in order to coordinate the rollout, and currently any mining pool that supports BIP 101 is identified, attacked and forced to shut down. We'll see if Slush comes back with enough DoS protection to handle this in the coming days.

The other issue is that if sustained, it means XT cannot change anything about the wire protocol, even in cases where it's obviously the right thing to do. 

Long term that means we'd have to follow Core if they kill off support for SPV wallets. It may also mean the double spend relaying would have to go if the attacker wrote a program to probe nodes and spot the relayed double spends.

Obviously if XT cannot change the protocol in any way, then it ceases to have much reason for existing as extending the protocol is the reason it was created.

[Mike Hearn]

Right now what we need most PR wise is people who speak Russian going into forums where the attacker might be getting news and tackling any propaganda or misinformation that's out there. BIP 101 is a fine and reasonable piece of work, it makes no logical sense to attack pools voting for it. 

The only reason I can think of for these attacks is that the attacker thinks "if an alternative to Core gains traction, Bitcoin will go wrong and lose its value". And so he is trying to kill XT to force everyone to do what Core wants. We've seen similar logic from one or two of the Chinese pools (stability in leadership is more important than growing the block chain).

I don't speak Russian or Chinese so there's nothing I can do to tackle these kinds of impressions.

[NxtChg]

>Sadly, I think these attacks can end in only three ways:

Can a fourth option help: create a lot of (fake?) nodes as a honeypot for the ddoser?

Increasing node count (preferably real) would also help us to send a stronger message about XT.

As Jameson said, if we can't sustain a ddos attack, we have a much bigger problem...


This guys offers nodes for 5 bucks: http://nodeup.xk.io

I don't know if he is honest or not, doesn't look like a scam, but in any case this can be duplicated.

There was also a guy on reddit who described how to create fake nodes.


At the cost of about $5,000 we could significantly boost nodes count, both real and fake.

5K is a burden for a single person, but nothing for the 8 companies. It's about time they start contributing.

[Tom Harding]

On 9/3/2015 8:44 AM, Mike Hearn wrote:
> Sadly, I think these attacks can end in only three ways:
>
> 1. Everyone who runs XT is beaten off the internet and usage drops to
> zero, ending the project.
>
> 2. The attacker is found and jailed by the Russian police, ending the
> attacker.
>
> 3. XT becomes indistinguishable from Core, thus forcing them to stop
> (their motivation is they want to kill BIP 101)
>
>

4. Of necessity, XT nodes become more resistant to ddos than core,
gaining another advantage. This is already happening.

[Mike Hearn]

4. Of necessity, XT nodes become more resistant to ddos than core, gaining another advantage.  This is already happening.

The only way to do this is find network providers/datacenter operators who don't care about very large DDoS attacks, and move all the nodes there.

Unfortunately I don't know of any way to find out if a colo provider is able and willing to handle that, except by getting attacked and seeing what happens.

Still, you're right, it's a strategy that can work. There'd be little point releasing Mac/Windows downloads though. I don't think residential networks normally care, as the per-customer margins are too low to be worthwhile.

[Ivan Brightly]

Auto-upgrade which is off by default and can be user enabled would be fine. I think it's a big can of worms to try to go down the Google Chrome / Windows 10 forced auto upgrade path. It makes someone with commit rights much more of a target among other things.

--

[Mike Hearn]

Auto-upgrade is a separate topic. Doing it well would mean something like a Lighthouse multi-sig/threshold update system, which is awkward to do, especially as Linux users like to use apt repositories which don't support that.

Some of the Lighthouse work could be reused, but I don't think this is a high priority. In practice most people do upgrade over time, and non-instant rollouts aren't so terrible. 

[Tom Harding]

On 9/3/2015 8:18 AM, Mike Hearn wrote:

Any information published by a centralized service will not be very valuable.

All existing stats graphs are published by centralised services. I think this is a red herring.

The difference is that anyone can observe the variables and create a service to publish them, or verify the numbers published by others.  With "phone home" only "home knows".

[Tom Harding]

On 9/3/2015 8:18 AM, Mike Hearn wrote:

Any information published by a centralized service will not be very valuable.

All existing stats graphs are published by centralised services. I think this is a red herring.

[Sebastian Plesch]

Please check this thread: https://www.reddit.com/r/bitcoinxt/comments/3jhcka/potential_fix_for_ddos_attack_on_nodes/
It seems like not having a reverse DNS entry saves you from being attacked (at least my node with a faulty reverse DNS has not been attacked).

Anyways, I don't think changing the version string is a good idea.. there will always be a way for the attacker to find the nodes. I think what would help more is to publicize this attack and generally communicate more about why XT exists and what it tries to accomplish.

[Tom Zander]

On Thursday 03 Sep 2015 17:50:27 Mike Hearn wrote:
> Right now what we need most PR wise is people who speak Russian going into
> forums where the attacker might be getting news and tackling any propaganda
> or misinformation that's out there. BIP 101 is a fine and reasonable piece
> of work, it makes no logical sense to attack pools voting for it.
>
> The only reason I can think of for these attacks is that the attacker
> thinks "if an alternative to Core gains traction, Bitcoin will go wrong and
> lose its value". And so he is trying to kill XT to force everyone to do
> what Core wants. We've seen similar logic from one or two of the Chinese
> pools (stability in leadership is more important than growing the block
> chain).
>
> I don't speak Russian or Chinese so there's nothing I can do to tackle
> these kinds of impressions.

Pick various blogs or white papers and hire a translator to translate them
into Chinese and/or Russian.

Finding good documentation on this topic is likely the biggest problem. The XT
website is not filled enough, IMO.

--
Tom Zander

[Tom Zander]

On Thursday 03 Sep 2015 17:09:28 Mike Hearn wrote:
> I suggest therefore that the next release stop identifying itself as

> Bitcoin XT [].

> This will make it indistinguishable at the wire level from Core.

Feels cowardly, but sane.

> We can keep track of how many XT nodes are out there by making it do a
> simple HTTPS request to a website hosted on infrastructure that can handle
> big DDoS attacks.

This sounds bad. The reason this sounds bad is because I predict that PR wise
this will be an even worse disaster than the tor blocking.
A phone-home feature will make lots of people giddy with evilness.

And, yes, I'm aware that that argument would be silly.


What about the suggestion I made the other day on IRC?
When someone connects to the XT node and identifies themselves with the evil
application name, then lie about who you are. Only *then* say you are a
satoshi client.
Or, alternatively, always say you are a satoshi client unless the one
connecting is the bitnodes.io service.

You catch my drift?
--
Tom Zander

[NxtChg]

>The XT website is not filled enough, IMO.

There was some effort on reddit to start our own wiki, but it kinda lost momentum. This should be done eventually.


The suggestion about lying to the evil tool won't work, obviously, they will modify it to be indistinguishable.

Telling the truth only to white-listed services sounds better, at least at first glance :)

[Andreas Schildbach]

I don't think spoofing the version string of core will do anything good.
Most likely the attacker just uses the output of Cartographer to find IP
addresses to attack anyway, rather than crawling for nodes himself.

And speaking of Cartographer, it's trivial to mod it to ignore the
version string and go by real capability instead -- if I saw right the
necessary code is already in there and in use!

So the switch would buy us 1 hour of time, at most. At the expense of a
lot of confusion and loss of our public recognition.

> --
> You received this message because you are subscribed to the Google
> Groups "bitcoin-xt" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoin-xt+...@googlegroups.com

> <mailto:bitcoin-xt+...@googlegroups.com>.

[Mike Hearn]

As I said in my email:

I suggest therefore that the next release stop identifying itself as Bitcoin XT and (this will break Lighthouse) stop serving the getutxo message. This will make it indistinguishable at the wire level from Core.

So you would not be able to find XT nodes via Cartographer because they would stop serving the upgraded protocol.

[Andreas Schildbach]

Read my sentence about modding Cartographer.

[Mike Hearn]

I think there is some confusion.

My proposal is that XT would no longer have any features that aren't in Core. So there would be no way to detect the differences because there would be no differences (beyond BIP101 support, but that cannot be detected with protocol messages if not mining).

--
You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.

[Washington Sanchez]

Everyone in the Bitcoin ecosystem should be alarmed by this. It seems the network is much more sensitive to DDoS attacks than we'd care to admit.

[Paul Goldstein]

On Thursday, September 3, 2015 at 8:11:08 PM UTC-4, Washington Sanchez wrote:

Everyone in the Bitcoin ecosystem should be alarmed by this. It seems the network is much more sensitive to DDoS attacks than we'd care to admit.

Agreed, I'm surprised at the lack of response from everyone else. Meanwhile though my node looks healthy (but I can't really be sure). Any sure fire test?

Anyway, Someone should just tell Peter T. to knock it off already. 

 

[Michael Ruddy]

I agree that these attacks are important; not because they are technically novel, but because they strike at what some have called the Achilles heel of cryptocurrencies -- network fragility and lack of true broadcast.

We're just lucky that it's limited to XT right now. Long run it's probably good for anti-fragility though.

They also attack the premise that full node operation should/will remain within the realm of hobbyist users.

As far as mitigation, it's likely possible, however with the increased cost and complexity of using a TCP proxy service that provides adequate DDoS protection in front of a full node (and routing all of the node's incoming and outgoing traffic through that).

Kind of somewhat similar to what CloudFlare does for HTTP/S origin servers (CloudFlare isn't a generic TCP proxy so we can't use it directly for the Bitcoin protocol).

Looks like there might be a few such services available in the tens of US dollars per month range. I haven't used any of them to know for certain.

Basically, using one of these services is one way to reduce your vulnerability to the policies, whims, or other treachery of ISP's an/or other upstream network providers that you might not find suitable.

To use such a proxy service successfully, nodes would need to not spill the non-proxied IP address for sure (so I guess they'd probably need to be configured with the proxy address/es). This might be an area where XT could add a patch, if necessary.

If full nodes had a way to fallback to communicating Bitcoin P2P encapsulated in HTTP (maybe via an external translating proxy?), then services like CloudFlare could possibly be used in some cases. Before that, among other things, some thought would have to go into what possible effects on consensus caching CDNs might have. This is just a half-baked idea that I'm adding as I'm typing.

On the version collector, I'm not sure I am in favor of it, but if you want an idea for how to get the metrics, if I were to setup a quick and dirty thing, I might setup a domain in a free CloudFlare account and then look at the analytics that they provide for the request counts and request counts grouped by IP address (unique visitors) that went through their proxies. It would be very low cost, low maintenance, easy to setup, and should not get DoS'd off the net. 24-hour, week, and month data aggregates are available for free accounts/sites. It's all in a web GUI. Not sure if that meets requirements that you might have in mind.

Also, don't forget to change the P2P protocol version number back if you go ahead with the identification change (I didn't see it mentioned in the thread yet).

[Washington Sanchez]

Anyway, Someone should just tell Peter T. to knock it off already. 

Seriously. 

[Tom Zander]

On Thursday 03 Sep 2015 17:37:49 Paul Goldstein wrote:
> Anyway, Someone should just tell Peter T. to knock it off already.

I would hope we don't stoop ourselves down to the level of accusing specific
persons without substantial proof.

I can think of a lot of reasons a lot of different actors might want to attack
XT. Most of them based on misinformation, but some are more sinister and
certainly not done by actors like you mentioned.
--
Tom Zander

[Tom Zander]

On Thursday 03 Sep 2015 19:23:00 Michael Ruddy wrote:
> I agree that these attacks are important; not because they are technically
> novel, but because they strike at what some have called the Achilles heel
> of cryptocurrencies -- network fragility and lack of true broadcast.

Personally, I think it shows an entirely different problem. A problem in the
Internet world as a whole (which extends to Bitcoin) where progress is
stalling. Rollout of IPv6 is a good example of that.

To understand why I say this, the attack we see is a well known vulnerability
that has been 'fixed' quite some time ago. The problem is that all the different
deployments of the old faulty DNS software are still running and are still
doing their main job properly so nobody really feels a need to upgrade them.

Bitcoin actually does have something smart to avoid this, a node that is too
old gets messages in the logs some months before a network upgrade. A node
will stop being useful at a point if it doesn't get updated.

Problem really is that when you want to have a distributed system that can
self-repair like this, you need a central trusted party that can be trusted to
actually be the trigger of a message stating a certain version is buggy and
nodes older should voluntary shutdown. I don't want to have the master key for
that feature ;)
--
Tom Zander

[Tom Zander]

On Thursday 03 Sep 2015 17:09:28 Mike Hearn wrote:

> We can keep track of how many XT nodes are out there by making it do a
> simple HTTPS request to a website hosted on infrastructure that can handle
> big DDoS attacks.

Just had this thought,

what about individuals can "pledge" to support BIP101 on a website using a
simple form and a human approving said pledges to show up on a website.

It really isn't any worse than the alternatives. And it falls nicely in line
with the economic majority pledging their support.
--
Tom Zander

[Chris Wheeler]

I don't think we should over-react to these DoS attempts. While they have taken a few nodes offline I think the majority of XT nodes are still online and not affected (my nodes haven't been, as far as I can tell). 

Without knowing the exact motivations of the attacker it's hard to know what they will do next. Changing the version string and removing functionality is letting them win on some levels. If people are being attached when running XT they can switch to the bigblocks-only branch if they want to support BIP101.

I understand the reasons for not 'officially' releasing builds of the bigblocks-only branch, but if you're going to change the version string back to emulate Core and remove some of the XT features, you're well on your way to doing that anyway...

So, to summarise, my suggestion would be:

1) Keep XT exactly as it is, showing the attacker they don't have any influence.

2) Officially release Core+BIP101 - and suggest this to anyone who has problems with DoS attacks.

- Chris

[NxtChg]

>Unfortunately I don't know of any way to find out if a colo provider is able and
>willing to handle that, except by getting attacked and seeing what happens.

OVH is notoriously hard for ddosers and they include their anti-ddos basic protection even with cheapest VPS nodes.


On a side note, let me say again that if Bitcoin wants to move out of the cryptonerd basement
and become more mainstream, more professional, more mature, then Bitcoin companies need to start
investing into public infrastructure - no government will step in to build roads.

It's ridiculous that a serious company would rely on a bunch of volunteering amateurs as a backend of their operation.

Imagine Amazon delivery policy like this:

"if some guy shows up at our warehouse, because he feels like doing some public good, we will deliver
your order (assuming the guy actually gets to you too)."


This idea needs to be conveyed to them by somebody with direct contact.

And there should be something like Foundation 2.0 (don't ask how to make it work, I have no idea :)

It will be in charge of infrastructure development. And not only nodes, but public sites, forum, wiki, promotion ads, stuff like that.

[Codehalo]

Reset string to core and something involving OP_RETURN?

[arthurp...@gmail.com]

I'll start the wiki

[NxtChg]

>I'll start the wiki

I am setting one up right now. Got tired of waiting :)

[Andreas Schildbach]

Ok indeed I didn't understand your proposal correctly.

But then where is the difference to that bigblocks branch?

> <mailto:bitcoin-xt%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "bitcoin-xt" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoin-xt+...@googlegroups.com

> <mailto:bitcoin-xt+...@googlegroups.com>.

[Mike Hearn]

XT includes more patches now than just bigblocks+getutxos+double spend relaying.

Anyway: 

https://github.com/bitcoinxt/bitcoinxt/pull/57

It's an optional, off by default -stealth-mode flag with no stats reporting (for now).

[Colin H.]

I think changing the version string to be indistinguishable from Core is the right move.

Also, as evidence seems to indicate it is someone/group from Russia attacking, and you, Mike, (out of good nature) presume that they may simply be misunderstanding the target (Bitcoin XT) they are attacking. But money or personal gain is often the motive for such a large-scale and relentless attack, and I wouldn't be surprised if directly or indirectly the attack is funded by something like Blockstream, or a similar group. I am making it clear I have zero evidence to back that accusation up, but the general premise is logical. Someone this dedicated has a real purpose, and I doubt it's a simple misunderstanding of what they're attacking. And I bet they gain something by doing it.

So, bring on the camouflaged version strings and fight fire with a bit of fire.

XTnodes.com will have to be without the node count, unless there's a way I can pull that data from wherever the source ends up being located.

[Ivan Brightly]

Executing DDoS attacks comes at a cost since botnets are not free - using them in an attack often annoys the users and ISPs which reduces infected nodes as they are cleaned and/or taken offline. There's always the fall back to changing the string; why not wait it out for a few weeks and see if the attacker either gains an understanding that BIP101 isn't an attack or runs out of resources?

--

You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.

[Colin Hutchings]

Hopefully that is the case, but if it can happen once, it can happen again, and I'd much prefer being ready rather than simply *hoping* it doesn't occur again.

You received this message because you are subscribed to a topic in the Google Groups "bitcoin-xt" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoin-xt/IWg3JHvOWJo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoin-xt+...@googlegroups.com.

[NxtChg]

>Executing DDoS attacks comes at a cost since botnets are not free...

I thought a bit more about the idea proposed here earlier about accepting connections only from a subset of users with something like hash(IP).

It can still be done if we forward requests to connect to other nodes, recursively.

It would work like this:

* User A from IP wants to connect to us.
* We calculate hash(IP) and decide we can't accepts it.
* But we forward his request to one of the nodes we are connected to, which is closest to that hash. Similar to DHT.
* They do the same.
* Eventually a node that accepts such IP will be found and it will reply to that IP with ACK.

Alternatively, we could send such requests to all nodes we are connected to, but then we would need to protect IP in transit, similar to Tor.

The attacker cannot discover all the nodes unless he can listen on hundreds of random IPs.

This would not only help with ddos, it would also help in case of government crackdown or hackers looking to exploit nodes with wallets.

Bootstrapping and node counting becomes harder, though. It needs more thinking.

[Arnoud Kouwenhoven]

Good to see you giving my suggestion some serious thought.

You would need to do hash (IPremote, IPlocal) at the very least, or otherwise everyone will block the same IP, so hash (IPremote, IPlocal) ensures everyone accepts connections from a different segment and everyone gets served. However, with hash (IPremote, IPlocal) your accepted IP range would be the same forever. Hence my suggestion to use a dynamic port with hash (IPremote, IPlocal, PORTlocal). All 3 variables in the hash function are already known in the peer lists.

Can someone explain the benefit of using fixed port numbers in p2p? I can't think of any reason other than 'we just always do that'. I don't think a fixed port adds any benefit to a p2p system where peers discover the other peers automatically, it would discover the port along with the IP. For anything where there is no pre-discovery (ie http, https, dns, smtp, etc etc) you would have to use a fixed port - otherwise connecting would be difficult. But for p2p nodes I really do not see any benefit (maybe someone can tell me) as there are never any manual connections being built. In the case of p2p, I only see disadvantages (port blocking, hackers having a field day, etc).

(Side thought - if we are going to make such a change to the protocol, we maybe should also add encryption on those ports. Transition could be to keep both an unencrypted and an encrypted port open and for clients to prefer an encrypted connection. That would reduce MITM attacks. Add to that, that the client that is connected to does not identify itself before the remote host sends a correct identification message, along with random ports, would very much improve privacy and security in my opinion - but maybe I am adding too much functionality now!)

Node counting would become harder, but not by much. If you count 500 nodes that you can connect to, and know you can only see 10% of the network, you could guestimate that there are 5000 nodes in total. If you must have a list of full nodes for genuine purposes (I don't consider someones curiosity a genuine purpose) then that would be a problem - as the whole point is to prevent such lists being made easily. What is a genuine business case for centralized lists in a decentralized system?

As for bootstapping - I am not sure if that is really a problem. If I know 10% of the nodes I can publish them via DNS just like I do now. Someone who needs to bootstrap, would simply have to ignore all addresses that he cannot connect to. Obviously it would make sense to have the DNS server do something a lot smarter (only return the addresses that he knows about, that you can connect to) which would require changing the DNS server code. Although I think Mike Hearn has an idea how to improve the bootstrapping by using something other than DNS - but I don't recall any details.

[NxtChg]

>You would need to do hash (IPremote, IPlocal) at the very least...

The details are not very important. I was thinking doing hash(IP_remote) and matching it to something like hash(IP_local). Same thing.

>Node counting would become harder, but not by much.

I meant node counting like XT vs Core, but you can estimate here too. Or some other service that wants to analyse network topology or some other metric.

>If I know 10% of the nodes I can publish them via DNS just like I do now.

This means giving the list of all IP's to a centralized service. But it could work with a few trusted servers, yes.

Although if any one of them decides to sell / help ddosers you will have no way of knowing who did it.

The network should still support node discovery without such servers, so some form of forwarding will be needed and it will be relatively complicated.