prusnak commented at 11:04 pm on November 16, 2021: contributor

Heavily inspired by #23077 + #23324 + #23175 which add CJDNS support

Yggdrasil overview

Yggdrasil is an implementation of a new name-independent routing scheme and functions as an end-to-end encrypted IPv6 network. It shares very similar goals to CJDNS. It uses an address range of 0200::/8 (as opposed to fc00::/8 used by CJDNS).

Motivation

Despite Yggdrasil is being considered an alpha quality software, it seems to be much more maintained than CJDNS.

CJDNS contributions chart:

Yggdrasil contributions chart:

It is also much easier to get it Yggdrasil working on variety of systems and architectures (macOS, Windows, Android, ARM64, MIPS) because it is written in pure Go, while it is hard to get CJDNS working on anything else than x86_64 Linux.

Yggdrasil resources

homepage: https://yggdrasil-network.github.io
more about Yggdrasil history: https://yggdrasil-network.github.io/2019/01/09/history.html
FAQ: https://yggdrasil-network.github.io/faq.html
source code: https://github.com/yggdrasil-network/yggdrasil-go
releases: https://github.com/yggdrasil-network/yggdrasil-go/releases

prusnak commented at 11:08 pm on November 16, 2021: contributor

@vasild @jonatack Would you like to experiment with Yggdrasil too?

prusnak force-pushed on Nov 16, 2021

sipa commented at 11:37 pm on November 16, 2021: member

I set up an Yggdrasil router as well: [200:b9b6:8c66:f88d:7043:e30b:d803:c3e2]:8333 (it’s not running this branch, but I don’t think that matters).

DrahtBot added the label GUI on Nov 17, 2021

DrahtBot added the label P2P on Nov 17, 2021

DrahtBot added the label Scripts and tools on Nov 17, 2021

DrahtBot added the label Utils/log/libs on Nov 17, 2021

DrahtBot commented at 4:31 am on November 17, 2021: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#25678 (p2p: skip querying dns seeds if -onlynet disables IPv4 and IPv6 by mzumsande)
#25172 (refactor: use std:: prefix for std lib funcs by fanquake)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

unknown changes_requested

unknown commented at 7:05 am on November 17, 2021: none

UPDATE: No opinions on this PR: #23531 (comment)

Despite Yggdrasil is being considered an alpha quality software, it seems to be much more maintained than CJDNS

~~NACK~~

Reasons:

Alpha project should not be used for mainnet. For experiments maybe implementing only for testnet makes sense.
ipv4, ipv6, Tor, i2p and cjdns already exist. Adding more networks will add complexity based on combinations and possibility of bugs.
Few other reasons mentioned here: #23077 (comment)
GNUnet will be a better alternative if/when one more network makes sense

laanwj commented at 11:24 am on November 17, 2021: member

Mind that this is a P2P BIP-level change, I think you’ll want to write a (short) ancillary BIP to BIP155 to propose this new assigned number.

in src/bitcoin-cli.cpp:52 in 0a33d6c691 outdated

48@@ -49,7 +49,7 @@ static constexpr int DEFAULT_WAIT_CLIENT_TIMEOUT = 0;
49 static const bool DEFAULT_NAMED=false;
50 static const int CONTINUE_EXECUTION=-1;
51 static constexpr int8_t UNKNOWN_NETWORK{-1};
52-static constexpr std::array NETWORKS{"ipv4", "ipv6", "onion", "i2p", "cjdns"};
53+static constexpr std::array NETWORKS{"ipv4", "ipv6", "onion", "i2p", "cjdns", "yggdrasil"};

jonatack commented at 4:34 pm on November 17, 2021:

5ede1d13 The network column widths printed by -netinfo are currently 8 characters. Haven’t tested, but with “yggdrasil”, I would guess they either would need to be increased to at least 10 characters (each, or just for this column) or a shorter name of max 7 chars could be used.

jonatack commented at 5:33 pm on November 17, 2021:

(maybe just “ygg”?)

jsarenik commented at 8:48 am on November 29, 2021:

What about just ygg here?

prusnak commented at 11:10 am on November 29, 2021:

“yggdrasil” renamed to “ygg” in da2803cf1c20d5b63a6be6ecc3f703ea84b59649

prusnak commented at 11:11 am on November 29, 2021:

“yggdrasil” renamed to “ygg” in da2803cf1c20d5b63a6be6ecc3f703ea84b59649

in test/functional/feature_proxy.py:112 in 0a33d6c691 outdated

108@@ -106,7 +109,7 @@ def setup_nodes(self):
109             ['-listen', f'-proxy={self.conf2.addr[0]}:{self.conf2.addr[1]}','-proxyrandomize=1'],
110             [],
111             ['-listen', f'-proxy={self.conf1.addr[0]}:{self.conf1.addr[1]}','-proxyrandomize=1',
112-                '-cjdnsreachable']
113+                '-cjdnsreachable', '-yggdrasilreachable']

jonatack commented at 5:20 pm on November 17, 2021:

0a33d6c only had a quick look, so to be confirmed, but it looks like you need to do something like this for the functional test to pass

 0 class ProxyTest(BitcoinTestFramework):
 1     def set_test_params(self):
 2-        self.num_nodes = 5
 3+        self.num_nodes = 6
 4         self.setup_clean_chain = True
 5 
 6     def setup_nodes(self):
 7@@ -109,7 +109,9 @@ class ProxyTest(BitcoinTestFramework):
 8             ['-listen', f'-proxy={self.conf2.addr[0]}:{self.conf2.addr[1]}','-proxyrandomize=1'],
 9             [],
10             ['-listen', f'-proxy={self.conf1.addr[0]}:{self.conf1.addr[1]}','-proxyrandomize=1',
11-                '-cjdnsreachable', '-yggdrasilreachable']
12+                '-cjdnsreachable'],
13+            ['-listen', f'-proxy={self.conf1.addr[0]}:{self.conf1.addr[1]}','-proxyrandomize=1',
14+                '-yggdrasilreachable'],
15         ]

prusnak commented at 0:12 am on November 18, 2021:

Addressed in 5fcbec5b76bb2bfa9c62abf3a2ffae9f540ae8b2

jonatack commented at 5:30 pm on November 17, 2021: contributor

Haven’t looked into or tested yggdrasil yet. Concept ACK on additional networks available to users if that strengthens the robustness of the peer-to-peer network. Debug build is clean for me. Some initial light feedback.

prusnak force-pushed on Nov 18, 2021

vasild commented at 2:13 pm on November 18, 2021: contributor

The addresses used by Yggdrasil are considered routable by Bitcoin Core. That is - just like any other normal IPv6 address, publicly routable on the global internet. They will be gossiped. This is in contrast to CJDNS which uses unroutable addresses from RFC 4193 and thus need special handling in Bitcoin Core.

~~I have to think more and review carefully this PR, but it may be that it is not necessary and Yggdrasil “just works” with current master.~~ Edit: it works, but can work even better with some minimal changes, see comments below.

It uses an address range of 0200::/8

According to https://yggdrasil-network.github.io/faq.html#will-yggdrasil-conflict-with-my-network-routing it uses 0200::/7 (starts with 02 or 03).

it is hard to get CJDNS working on anything else than x86_64 Linux

Hmm, CJDNS works for me on FreeBSD/x86_64 and on my OpenWRT router - Linux/mips (there is also an yggdrasil package for OpenWRT).

prusnak commented at 3:17 pm on November 18, 2021: contributor

I have to think more and review carefully this PR, but it may be that it is not necessary and Yggdrasil “just works” with current master.

That would great news actually!

sipa commented at 3:33 pm on November 18, 2021: member

If we add support for this, I do think we want to at least include logic to treat Yggdrasil’s addresses separately for the purpose of group mapping (e.g. like Tor, treat all of Yggdrasil as 1 or a few network groups, rather than using the normal IPv6 logic). We could do that with or without treating it as a separate network:

With a separate network, as this PR currently does, it’s a somewhat cleaner separation, we get somewhat better failures (non-Yggdrasil-connected nodes would not even bother trying to connect, rather than trying and failing), and if we ever get a network extension to negotiate supported networks, also somewhat better gossip (by preferential relay among compatible nodes). The downside is that it requires a BIP or BIP addendum to reserve a BIP155 network id.
Without a separate network, it’s a smaller change, and we’d implement the group mapping directly on the 0200::/8 range in IPv6, essentially hardcoding the knowledge that that range belongs to Yggdrasil.

I have a slight preference for the first approach.

vasild commented at 3:52 pm on November 18, 2021: contributor

… treat Yggdrasil’s addresses separately for the purpose of group mapping …

Right!

I have a slight preference for the first approach.

Me too.

jb55 commented at 5:27 pm on November 18, 2021: contributor

Interesting… Concept ACK

prusnak force-pushed on Nov 18, 2021

jamesob commented at 10:36 pm on November 18, 2021: member

Concept ACK, will review

prusnak commented at 10:57 pm on November 18, 2021: contributor

I think you’ll want to write a (short) ancillary BIP to BIP155 to propose this new assigned number.

PR to bips repo in https://github.com/bitcoin/bips/pull/1238

vasild commented at 10:57 am on November 19, 2021: contributor

Concept ACK

Without this PR, master is able to connect to yggdrasil addresses and will gossip them (good). With minimal changes (this PR), we can get (thanks, @sipa):

Proper reporting, like in getpeerinfo RPC (to print yggdrasil instead of ipv6)
Proper network grouping - don’t do nonsensical netmasks on those addresses
Don’t try to connect to such addresses if -someconfigoption is not set to indicate yggdrasil connectivity is available
Selective gossip

sipa commented at 4:31 pm on November 19, 2021: member

@prayank23 Moving the discussion from https://github.com/bitcoin/bips/pull/1238#issuecomment-974190303 here, because I think it’s more a question about Bitcoin Core’s implemention.

I’m not convinced we should add this either, because of the low maturity of the project. But I think the discussion is a bit more nuanced than just looking at that.

The name of this PR is a bit misleading, for starters. This isn’t adding support for yggdrasil to Bitcoin Core in the sense of having the project depend on it, or add direct integration (as was the case for tor and i2p, where significant amount of special code were needed to let Bitcoin Core interact with the specific routing software for those networks). What it does add is a small amount of code to make Bitcoin Core’s network stack aware of the fact that a particular subrange of the IPv6 space corresponds to Yggdrasil, and should be treated slightly differently. Interacting with the Yggdrasil network is done independently, by the user installing an Yggdrasil router, which integrates in the OS, and transparently routes yggdrasil-compliant IP addresses over the Yggdrasil network - and this happens (and can be used) whether or not Bitcoin Core has specific support for it.

The advantages are:

Better behavior in case anyone starts rumouring such addresses on the network, regardless of whether the node’s operator considers them using Yggdrasil to be a good idea or not.
Better behavior for anyone actually using Yggdrasil. I personally think that more distinct ways to connect nodes in general is a good thing, as it contributes to partition resistance of the network.

The disadvantages are:

Extra code to maintain, obviously.
Connectivity issues in case there are problems/upgrades with yggdrasil, for those using it.

I think both of the disadvantages are actually tiny. The amount of code being added here is similar to what is needed for cjdns; just making the network stack aware of the existence of this separate range. Connectivity issues could be problem in case someone is exclusively connecting through yggdrasil, but I don’t think anyone is arguing for that (or should; just like you shouldn’t exclusively use automatic tor or i2p connections). If yggdrasil goes down (either due to a network-wide failure, or incompatible upgrades, or individual routers crashing)… bitcoin core will make new connections; interrupted connections are nothing special. Given that Bitcoin Core is in no way directly talking to the yggdrasil router, I’m not worried about it causing bugs/crashes in Bitcoin Core itself.

ghost commented at 6:17 pm on November 19, 2021: none

@sipa That makes sense. Thanks for explaining everything in detail.

I retract my NACK and have no opinion on this pull request. Will follow the progress, research more about yggdrasil and do tests though.

ShadowJonathan commented at 11:28 am on November 21, 2021: none

Hey everyone, I would not recommend adding Yggdrasil support, not on the basis of principle, but on the basis of the nature of the project itself, let me explain.

Yggdrasil is largely an experimental academic protocol/software, aimed to research routing at scale, the intention (of its author @Arceliar) is to - eventually - wrap it up, place a v1 on it, and write a paper, but there is sofar no intention to keep up support after that.

In the mean time, there is also no guarantees of minor version incompatibility, so this could be quite unstable to use.

Instead, i would like to direct everyone’s attention to a spin-off project, pinecone, made with the same current routing methods, but intended to be supported for a long time. Pinecone also doesn’t work via ipv6 addresses, but full public key hashes, and is intended to be embeddable.

However, as Bitcoin is a large project on the internet with many eyes on it, i would heavily recommend getting into dialogue with Pinecone’s developers before proceeding with adding support.

TL;DR: Yggdrasil is experimental and academic, while a project derivative of it, Pinecone, is aiming to be actively developed in the future.

There are some caveats to my recommendation, the first one is the idea that yggdrasil wont be developed anymore after the paper has been written and published, that’s an assumption, if anyone else (or bitcoin) could maybe like to pick up development after it’s hit v1, then obviously this could be a good addition, but it depends on what it’s authors think of the future, so i recommend conversing about that before adding this.

Most of my knowledge here comes from talking with the actual Yggdrasil devs, if anyone would like to ask for themselves, they can do so via the matrix room. (also listed on the site)

prusnak commented at 11:34 am on November 21, 2021: contributor

wrap it up, place a v1 on it, and write a paper, but there is sofar no intention to keep up support after that.

Can you please comment on that? @neilalexander @arceliar

ShadowJonathan commented at 11:36 am on November 21, 2021: none

@prusnak please also read my disclaimer at the bottom, it’s the intention i got from the authors while talking to them (especially @Arceliar), my point being that yggdrasil is more an academic project than a continuous software one. @neilalexander works on yggdrasil on the latter basis, but has split off efforts into Pinecone, primarily inspired by Yggdrasil.

jsarenik commented at 11:40 am on November 21, 2021: none

Looks good to me. Skimmed through the patch, everything seems trivial there. Running yggdrasil (often shortened to ygg which I would prefer in the column names instead of widening them) since early 2017.

0$ echo $COLUMNS
180

Arceliar commented at 6:58 pm on November 21, 2021: none

wrap it up, place a v1 on it, and write a paper, but there is sofar no intention to keep up support after that.

Can you please comment on that? @neilalexander @Arceliar

Just to clarify, v1 only means that I’m satisfied the R&D work is “done” and things are ready to be documented and published. That doesn’t mean the project will be abandoned, just that it’s no longer a platform for ongoing research (or at least, not on compact routing).

ShadowJonathan commented at 7:58 pm on November 21, 2021: none

Alright, i’ve somewhat skimmed the changes made here, and I do think they’re pretty resistant to yggdrasil’s version changes, but i’d like to re-iterate that major protocol changes can happen between versions, and that addresses may not always be guaranteed to be addressable from the local node, until v1

neilalexander commented at 8:03 pm on November 21, 2021: none

Can you please comment on that? @neilalexander @Arceliar

Given that all the PR seems to do is to add the understanding that 0200::/7 is unofficially Yggdrasil address space for the purposes of peer connectivity and configurability, I don’t really think there’s an issue here. Even if we reach a supposed v1, it also doesn’t mean that the current network will go away overnight.

Yggdrasil protocol iterations also don’t necessarily mean address space changes either — we changed address space once, from fd00::/8 to 0200::/7, back in June 2018 to avoid conflicting with other projects and private address space. We have never needed to change it since, even though multiple protocol breaks have happened in that time, and have no plans to change it for the foreseeable either.

As long as the only dependency here is on the address space and not any other aspect of the protocol then I would think this is safe enough to do.

ShadowJonathan commented at 8:05 pm on November 21, 2021: none

As long as the only dependency here is on the address space and not any other aspect of the protocol then I would think this is safe enough to do.

Agreed, admittedly my concern mainly was if and when yggdrasil would be imported as a dependency into existing binaries, but that doesn’t seem to be the case here.

in src/bitcoin-cli.cpp:560 in 011d0af808 outdated

556@@ -557,7 +557,7 @@ class NetinfoRequestHandler : public BaseRequestHandler
557                 const std::string& network_name{network["name"].get_str()};
558                 const int8_t network_id{NetworkStringToId(network_name)};
559                 if (network_id == UNKNOWN_NETWORK) continue;
560-                result += strprintf("%8s", network_name); // column header
561+                result += strprintf("%10s", network_name); // column header

jsarenik commented at 8:49 am on November 29, 2021:

This wouldn’t be needed if ygg is used in the columnt header.

in src/bitcoin-cli.cpp:571 in 011d0af808 outdated

567@@ -568,7 +568,7 @@ class NetinfoRequestHandler : public BaseRequestHandler
568         for (size_t i = 0; i < rows.size(); ++i) {
569             result += strprintf("\n%-5s", rows[i]); // row header
570             for (int8_t n : reachable_networks) {
571-                result += strprintf("%8i", m_counts.at(i).at(n)); // network peers count
572+                result += strprintf("%10i", m_counts.at(i).at(n)); // network peers count

jsarenik commented at 8:50 am on November 29, 2021:

Also not needed when the header is shortened to ygg instead of yggdrasil.

in src/bitcoin-cli.cpp:628 in 011d0af808 outdated

624@@ -625,7 +625,7 @@ class NetinfoRequestHandler : public BaseRequestHandler
625         "           \"manual\" - peer we manually added using RPC addnode or the -addnode/-connect config options\n"
626         "           \"feeler\" - short-lived connection for testing addresses\n"
627         "           \"addr\"   - address fetch; short-lived connection for requesting addresses\n"
628-        "  net      Network the peer connected through (\"ipv4\", \"ipv6\", \"onion\", \"i2p\", or \"cjdns\")\n"
629+        "  net      Network the peer connected through (\"ipv4\", \"ipv6\", \"onion\", \"i2p\", \"cjdns\" or \"yggdrasil\")\n"

jsarenik commented at 8:54 am on November 29, 2021:

What about ‘ygg’ also here? Others are at most 5 characters long (onion). yggdrasil is 9. More than double the median length of 4.

prusnak commented at 11:11 am on November 29, 2021:

“yggdrasil” renamed to “ygg” in da2803cf1c20d5b63a6be6ecc3f703ea84b59649

in src/net.cpp:245 in 011d0af808 outdated

241+ *
242  * @param[in] service Address to potentially convert.
243  * @return a copy of `service` either unmodified or changed to CJDNS.
244  */
245-CService MaybeFlipIPv6toCJDNS(const CService& service)
246+CService MaybeFlipIPv6toCJDNSorYggdrasil(const CService& service)

jsarenik commented at 8:57 am on November 29, 2021:

what about MaybeFlipIPv6toAltNet ? otherwise it would invite to add all the other alternative network layer names in this function name eventually…

prusnak commented at 11:11 am on November 29, 2021:

done in 0b3dd4140e34ca2a87b813bb810958d70b5160d8

jsarenik commented at 9:01 am on November 29, 2021: none

Just some unimportant nit ideas. Looks good to me as it is.

prusnak force-pushed on Nov 29, 2021

jsarenik approved

jsarenik commented at 8:18 pm on November 30, 2021: none

Thank you @prusnak for the changes!

jsarenik commented at 8:45 pm on November 30, 2021: none

Tested ACK a85cd9187d33bd9a2859aabe28c656825da0e539

0$ ./src/bitcoind -version
1Bitcoin Core version v22.99.0-a85cd9187d33
2$ ./src/bitcoind -help | grep -B1 ygg
3       Make outgoing connections only through network <net> (ipv4, ipv6, onion,
4       i2p, cjdns, ygg). Incoming connections are not affected by this
5--
6
7  -yggdrasilreachable

make check passed. Will soon start it with a few more patches on top to prove it works in the wild.

jsarenik commented at 10:04 pm on November 30, 2021: none

 0$ bitcoin-cli -signet -netinfo
 1Bitcoin Core client v22.99.0-878d8e1c0661 signet - server 70016/Satoshi:22.99.0/
 2
 3         ipv4   onion     ygg   total   block
 4in          0      25       2      27
 5out         6       4       0      10       2
 6total       6      29       2      37
 7
 8Local addresses
 978.98.6.214                                                        port  38333    score      4
10s7fcvn5rblem7tiquhhr7acjdhu7wsawcph7ck44uxyd6sismumemcyd.onion     port  38333    score      4
11200:5ecb:6b8a:d837:30e:8a01:c858:612b                              port  38333    score      1
12300:5ecb:6b8a:d837::1                                              port  38333    score      1
13300:5ecb:6b8a:d837::2                                              port  38333    score      1
14300:5ecb:6b8a:d837::3                                              port  38333    score      3

I have the same settings for mainnet and testnet, and inbound connections get in, but I do not see the addresses in -netinfo like on signet. Will check another day.

in src/netaddress.cpp:439 in a85cd9187d outdated

434@@ -422,6 +435,11 @@ bool CNetAddr::IsI2P() const { return m_net == NET_I2P; }
435  */
436 bool CNetAddr::IsCJDNS() const { return m_net == NET_CJDNS; }
437 
438+/**
439+ * Check whether this object represents a Yggdrasil address.

jsarenik commented at 10:49 am on December 1, 2021:

should be an Yggdrasil address

prusnak commented at 8:49 pm on December 1, 2021:

Done in aa5c9779bdd1c816899c0704ee1d965a57d6f036

in src/netaddress.cpp:477 in a85cd9187d outdated

478@@ -461,6 +479,11 @@ bool CNetAddr::IsValid() const
479         return false;
480     }
481 
482+    // Yggdrasil addresses always start with 0x02 or 0x03
483+    if (IsYggdrasil() && ((m_addr[0] & 0xfe) != 0x02)) {

jsarenik commented at 10:50 am on December 1, 2021:

or 0x03? It is written in the comment, but not in the condition.

jsarenik commented at 3:58 pm on December 1, 2021:

Probably a false-positive. Everything works well. I was just looking for something, some detail which would fix it for me, but found it to be discover=1 in the end.

vasild commented at 4:06 pm on December 1, 2021:

Both 0x02 & 0xfe and 0x03 & 0xfe are equal to 0x02.

prusnak commented at 8:46 pm on December 1, 2021:

Right. ((m_addr[0] & 0xfe) != 0x02)) is the same as ((m_addr[0] != 0x02) && (m_addr[0] != 0x03))

jsarenik changes_requested

jsarenik commented at 10:57 am on December 1, 2021: none

I will have a look again. So far I found this.

jsarenik commented at 2:31 pm on December 1, 2021: none

After using time-machine (v0.20.2) I think all my current confusion comes from the bitcoin-cli -netinfo which did not exist back then. But there is definitely a bitcoin-cli -netinfo issue here, though it is not related to this PR at all.

jsarenik commented at 3:56 pm on December 1, 2021: none

UPDATE: Everything works well for me now. I had to set discover=1 because I use externalip=<current_IPv4> and it disables discover by default. Interestingly the behavior differs with ‘signet’ network. But that’s not related now. Full ACK for this PR.

DrahtBot added the label Needs rebase on Jan 5, 2022

prusnak force-pushed on Jan 5, 2022

DrahtBot removed the label Needs rebase on Jan 5, 2022

prusnak force-pushed on Jan 5, 2022

jsarenik commented at 3:50 pm on January 6, 2022: none

Tested ACK 234731ae7

Running on https://ln.anyone.eu.org (before last rebase I was rebasing it myself to master branch with one little unrelated patch on top) for more than a month now. Works as expected. Thank you!

EDIT: Running at [300:5ecb:6b8a:d837::3]:8333

DrahtBot added the label Needs rebase on Feb 4, 2022

prusnak force-pushed on Feb 4, 2022

DrahtBot removed the label Needs rebase on Feb 4, 2022

in src/qt/locale/bitcoin_en.xlf:2630 in c09f75d01f outdated

3063@@ -3064,7 +3064,7 @@ If you are receiving this error you should request the merchant provide a BIP21
3064         <context-group purpose="location"><context context-type="linenumber">1067</context></context-group>

laanwj commented at 2:49 pm on February 21, 2022:

Please don’t update the translation files in a PR, we leave this until specific times to minimize merge collisions.

prusnak commented at 3:02 pm on February 21, 2022:

Fixed and force-pushed => 08fc8cb913487766c33c611746d78726aa642cec

prusnak force-pushed on Feb 21, 2022

DrahtBot added the label Needs rebase on Mar 24, 2022

laanwj removed the label Scripts and tools on Apr 14, 2022

laanwj removed the label Utils/log/libs on Apr 14, 2022

prusnak force-pushed on Apr 15, 2022

DrahtBot removed the label Needs rebase on Apr 15, 2022

DrahtBot added the label Needs rebase on Apr 22, 2022

prusnak force-pushed on Apr 22, 2022

DrahtBot removed the label Needs rebase on Apr 22, 2022

DrahtBot added the label Needs rebase on Jun 28, 2022

net: add Yggdrasil support d5a7bbc08e

contrib: recognize Yggdrasil seeds 53b02be0b7

qt: add Yggdrasil support 003780e9bf

test: add functional tests for Yggdrasil b5b5bffe44

net: use 0200::/7 for Yggdrasil 8d69dc33e5

net: use "ygg" instead of "yggdrasil" to make columns less wide e6d472114b

doc: replace "a Yggdrasil" with "an Yggdrasil" 3050627f51

prusnak force-pushed on Aug 21, 2022

DrahtBot removed the label Needs rebase on Aug 21, 2022

DrahtBot added the label Needs rebase on Sep 7, 2022

DrahtBot commented at 6:46 pm on September 7, 2022: contributor

🐙 This pull request conflicts with the target branch and needs rebase.

Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a “draft”.

majestrate commented at 1:45 pm on September 27, 2022: none

i’ve had a full node reachable via yggdrasil for about a year ([201:4c36:45a0:4b59:d0d0:9d6a:311d:fca7]:8333) and I didn’t know there was a PR for adding Yggdrasil awareness so i’ll chuck in my 2 cents on this topic. There are quite a few overlay networks and the number of them seems likely to only increase in the future. Perhaps consolidating all of these kinds into a distinct network type for overlay networks would be a more future-proof approach. e.g. a network type just for overlay networks advertising a mapping with key of “insert-arbitrary-overlay-network-name-here” to ip-ranges-used/gtld-used, so peers can pick and choose which intersection they’d want to utilize. I think this would reduce the number of PRs for “hey add support for my special network layer please” everyone in bitcoin core would need to review and filter, which would likely be a win for everyone involved (especially bitcoin core reviewers).

prusnak commented at 1:52 pm on September 27, 2022: contributor

I agree with the above comment.

Also I am closing this PR, but anyone feel free to take it as a base to for another PR which adds overlay networks in more generic way.

prusnak closed this on Sep 27, 2022

sipa commented at 2:07 pm on September 27, 2022: member

The blocking aspect here was a BIP or BIP update to allocate a BIP155 network number, to make sure there is no conflict with other networks trying to use the same number; apart from that I’d expect it to not be particularly hard to review here.

I’m not sure about a single network id for all overlay networks. That’s already not the case for CJDNS, and wasn’t the case for IPv4 and TorV2 before (which were specially-mapped subranges of IPv6 pre-BIP155). Having separate network ids for every network also means nodes can have visibility into what they’re able to connect to. Having a variety of overlay networks means all overlay-enabled nodes will be relied upon to relay all overlay IP addresses, but depending on the selection of actual networks supported by them, most such connections would fail. Network ids are cheap (there are 256), I don’t think we need to worry about allocating them conservatively.

prusnak commented at 3:08 pm on September 27, 2022: contributor

Network ids are cheap (there are 256),

While networks ids are cheap, getting them allocated is quite hard: see https://github.com/bitcoin/bips/pull/1238

majestrate commented at 3:10 pm on September 27, 2022: none

While networks ids are cheap, getting them allocated is quite hard: see bitcoin/bips#1238

that is indeed the issue at hand. hence why suggesting a new network id as a catchall for “overlay network” with a peer address containing a mapping of “overlay-name” to “reachable-range/reachable-gtld”

jonatack commented at 5:32 pm on November 15, 2022: contributor

it is hard to get CJDNS working on anything else than x86_64 Linux

Hmm, CJDNS works for me on FreeBSD/x86_64 and on my OpenWRT router - Linux/mips (there is also an yggdrasil package for OpenWRT).

I also found CJDNS to be easy to install on macOS (M1 Ventura in my testing) with brew install cjdns.

prusnak commented at 5:41 pm on November 15, 2022: contributor

I also found CJDNS to be easy to install on macOS (M1 Ventura in my testing) with brew install cjdns.

cjdns has horrible build system - you need Python 3.9 (not 3.10 or newer), Rust and NodeJS just to compile something which is mostly a C99 code 🤮 It’s notoriously hard to get it working on new platforms. Huge congrats to the person who got it working on M1. I spent at least 20 hours and failed.

bitcoin locked this on Nov 15, 2023

Add Yggdrasil support #23531

Yggdrasil overview

Motivation

Yggdrasil resources

Conflicts