This doesn't look like an improvement. Infact easiest way to introduce bugs and unexpected behaviour in Bitcoin P2P network.

@prayank23 All this does is reserve the number, so we don't run into conflicts if later yet another network/means of connecting nodes is introduced that tries to use the same number. I think it's independent from the question whether it's recommended/desirable that people actually connect nodes using yggdrasil (that's up to individual software implementing support for it, and its users using it). Of course, if it'd be a terrible idea and nobody should use it at all, there wouldn't be a point in even including it. But given that Yggdrasil works already (albeit somewhat suboptimally), without any changes to Bitcoin Core (and presumably other software) at all if you have it running on your system, the latter is pretty much inevitable I think.

@laanwj @luke-jr @kallewoof Thoughts on adding this to this BIP vs. having a separate amendment BIP? My thinking is that if there was a lot of substance (e.g. encoding/context of Yggdrasil addresses) we'd want this in a separate BIP, but with BIP155 linking to it from its list of supported networks. Given that there is so little substance, I don't think much more than just mentioning the number/encoding in BIP155 directly is needed.

All this does is reserve the number, so we don't run into conflicts if later yet another network/means of connecting nodes is introduced that tries to use the same number.

Okay. Creating a BIP for yggdrasil was suggested in Core repository so I am assuming this will help in adding support for it. Since it's proposed as a Bitcoin Improvement Proposal and can be used by other full node implementations as well, I do not consider it improving anything.

Of course, if it'd be a terrible idea and nobody should use it at all, there wouldn't be a point in even including it.

Agree

But given that Yggdrasil works already (albeit somewhat suboptimally), without any changes to Bitcoin Core (and presumably other software) at all if you have it running on your system, the latter is pretty much inevitable I think.

Writing a BIP, implementing support for it with a PR in Core and maybe later sharing as an improvement which people could try is different from things that are possible today or users would try. I don't even see anyone experimenting with yggdrasil on mainnet right now apart from few devs.

I asked few questions in the yggdrasil chat today and will do more research. Below are the chat logs:

prayank:

1. This is still an alpha-stage project and there may be some breaking changes in the future. 

2. The routing logic now lives in a standalone library. You are encouraged not to use it, as it's still considered pre-alpha, but it's available for those who want to experiment

3. Yggdrasil is currently an alpha project, early in development but actively maintained. Our expectation is that a future “beta” quality release should know enough to be compatible in the face of wire format changes, and reasonably feature complete. A “stable” 1.0 release, if it ever happens, would probably be feature complete, with no expectation of future wire format changes, and free of known critical bugs.

These are some of the things I found on website and respository. I have few related questions:

1. Should Yggdrasil be used in production for any application?

2. Which other projects use it right now?

3. Which critical bugs are mentioned in the third point above?


PureRaider:

First, I don't really know how to answer this question. Yggdrasil is an experimental project, but you can try it out. Second there is [Mass Mesh](https://massmesh.org/) and some other meshnets like [Toronto Mesh](https://tomesh.net/) and a lot of Russians use Yggdrasil. Third there are not too many bugs. It has been really stable for me.

Opal:

alpha quality doesnt refer only to known bugs but also to design flaws that may be uncovered after a while

I have zero confidence in using a network in its early stages of development for Bitcoin. I would have used it for some P2P file sharing project or other experimental side projects but would not prefer to use it on mainnet for Bitcoin which isn't just a P2P network but also has a token associated with it and market cap above trillion dollars.

Seems like BIP 155 should really be Final status, and therefore no further changes made.

But maybe the list can be converted to an updatable registry of some sort first?

@laanwj Opinions here, since it's your BIP?

@prusnak: Is this still relevant? @laanwj: What do you think about this PR?

(BIP155 network IDs are implemented in Bitcoin Core, for instance, in the following enum)

    /**
     * BIP155 network ids recognized by this software.
     */
    enum BIP155Network : uint8_t {
        IPV4 = 1,
        IPV6 = 2,
        TORV2 = 3,
        TORV3 = 4,
        I2P = 5,
        CJDNS = 6,
    };

ACK, i'm fine with reserving an ID for this, and it seems pointless to require writing an additional BIP. just to reserve a number.
(this doesn't bind anyone to actually implement YGGDRASIL support in bitcoin core or other implementations, ofc)

Thank you, @laanwj!