IRC channel logs

2021-01-19.log

back to list of logs

<fossy>stikonas: what do we need from newer tinycc
<fossy>i don't feel very happy with just grabbing a random commit from mob
<stikonas>hmm, somehow it failed to compile some line in musl, (I think hidden attribute)
<fossy>if we can cherry-pick a commit i feel better with that than mob
<stikonas>or maybe something else, tcc error messages are a bit unhelpful
<stikonas>let me find the line
<stikonas>yeah, that would be better
<fossy>restructure nearly complete, doing last build (if nothing fails)
<stikonas>top of the mob doesn't even build...
<stikonas>with mes libc
<fossy>unsuprising
<stikonas>fossy:
<stikonas>In file included from src/aio/aio.c:9:
<stikonas>./src/internal/syscall.h:237: error: identifier expected
<fossy>?!
<fossy>is that the entire message
<stikonas>yes
<stikonas>well, Error 1 from make too
<fossy>ugh
<stikonas>hidden void __procfdname(char __buf[static 15+3*sizeof(int)], unsigned);
<stikonas>that's the line
<fossy>thx tinycc!
<stikonas>well, it's tiny
<fossy>i think unsigned may not be defined by mes libc
<stikonas>oh
<stikonas>but tcc should know unsigned
<stikonas>it's basic type, not part of C library
<fossy>oh no nvm
<fossy>yeah
<fossy>maybe it's hidden then.
<fossy>i dont think thats supported by tcc
<fossy>hm.. maybe it is
<fossy>suggestion would be to split it into multiple lines, and see which line the error happens on
<fossy>although what the hell is a [static 15+3*sizeof(int)]
<fossy>i have never seen static there
<stikonas>yeah, let me try to split
<stikonas>now it's complaining about 15+3*sizeof(int)
<stikonas>that line...
<stikonas>maybe just static is not enough for tcc
<stikonas>static int?
<stikonas>nope...
<stikonas>fossy: ok, it builds if we remove static
<fossy>stikonas: yeah it should be fine
<fossy>i have no idea what static there would o
<stikonas>fossy: ok, another error is this
<stikonas>./arch/i386/syscall_arch.h:40: error: incorrect prefix
<stikonas>it goes away with some define
<stikonas>but I'm not sure if it is safe
<stikonas>-DSYSCALL_NO_TLS
<fossy>we don't have any kind of TLS support
<fossy>stack, network or otherwise
<stikonas>well, yeah
<fossy>"safety" is not something i am overly concerned about given the number of CVEs and shit lying in these outdated softwareas
<stikonas>fossy: I was worried about TLS because later compiled binaries segfault there
<stikonas>in __init_tls
<fossy>oh...
<stikonas>no idea why...
<fossy>well if we disable it maybe it will work
<stikonas> https://paste.debian.net/1181683/
<stikonas>no, it didn't
<stikonas>I used -DSYSCALL_NO_TLS when testing
<stikonas>but ok, I need to retest with stable tcc
<stikonas>fossy: and I think I have too many .o files when making library archive
<fossy>stikonas: probably
<stikonas>did you hit the same problem with mescc?
<fossy>yep
<fossy>that's why unified sources
<stikonas>need to somehow solve it...
<fossy>unified sourced
<stikonas>but musl does not have out of box unified sources...
<stikonas>we need to do more work for that
<fossy>making them is pretty single
<fossy>simple
<fossy>for a libc they never conflict (almost never) so its just concating them
<stikonas>fossy: it might be worth trying to build heirloom-sh first too...
<stikonas>at least it doesn't need bison
<fossy>maybe, if it dosen't use widechars
<stikonas>it ships fakewchar folder
<stikonas>so maybe it works with it
<fossy>does yacc
<fossy>can't we use fakewchar for yacc
<stikonas>hmm, maybe we can...
<fossy>i think we probably cna
<fossy>musl would still maybe be useful
<stikonas>worth trying...
<fossy>but i don't think gcc 2 can link against musl
<stikonas>might be easier to build musl once we have shell...
<fossy>still will need glibc there
<fossy>(in all likelihood)
<stikonas>oh, but gcc does link against mes libc?
<fossy>yes, originally, with patches
<fossy>and then it is recompiled against glibc
<stikonas>hmm, ok...
<stikonas>yeah, of course
<fossy>so it goes binutils (mes libc ) -> gcc (mes libc) -> glibc (mes libc) -> gcc (glibc) -> binutils (glibc) -> glibc (glibc) IIIRC
<stikonas>yeah, that's more or less standard
<stikonas>you recompile everything against itself...
<stikonas>but we can look at gcc later
<stikonas>it's still quite far ahead
<stikonas>after gcc you are basically done
<stikonas>or at least everything is straightforward
<stikonas>musl might still be useful for building some utilities
<stikonas>even if we later build gcc against mes libc
<stikonas>ok, I'll take a look at heirloom yacc with fakewchart for now
<fossy>gforce_de1977: i don't understand your PR
<fossy>you say you're adding a CI mode but then you go on to say you want to test locally
<fossy>which one is it, CI, local, or both
<stikonas>fossy: ok, I managed to build yacc that doesn't segfault
<stikonas>that fakewchar is very basic, I still need most of the same defines I used before (except that I used sed)
<stikonas>make -f Makefile.mk CC=tcc CFLAGS+="-I fakewchar -I . -DMAXPATHLEN=100 -DEILSEQ=84 -DMB_LEN_MAX=100 -Dswprintf=sprintf -Dwcslen=strlen -Diswdigit=isdigit -Diswxdigit=isxdigit -Diswlower=islower -Diswupper=isupper -Diswspace=isspace -Dwcscmp=strcmp -Dtowlower=tolower -Diswalpha=isalpha -Diswalnum=isalnum -Dungetwc=ungetc -Dgetwc=getc -Dwcscpy=strcpy" -lgetopt
<stikonas>this mostly builds it
<stikonas>possibly with some minor patching to add header files
<stikonas>fossy: but I can't build lex from heirloom though
<stikonas>yacc from heirloom fails to build parser.y in lex
<stikonas>yacc parser.y
<stikonas>"parser.y", line 58: warning: redeclaration of precedence of C.
<stikonas>"parser.y", line 58: warning: redeclaration of precedence of S.
<stikonas>"parser.y", line 58: warning: redeclaration of precedence of N.
<stikonas>"parser.y", line 58: warning: redeclaration of precedence of N.
<stikonas>"parser.y", line 67: fatal: redeclaration of precedence of
<stikonas>hmm, maybe it was patched... let me see if nbs has anything
<stikonas>hmm, doesn't seem so
<stikonas>oh, maybe different revision
<xentrac>defining wchar_t as char is, I think, totally legit, unless you're trying to link with a library that uses a more useful definition. Certainly the glibc page I linked to the other day said it was
<xentrac>not sure if it's valid to do it with #define though :)
<stikonas>xentrac: it seems to work...
<stikonas>otherwise it wouldn't have compiled
<xentrac>I'd think you'd at least need a -Dwchar_t=char in there somewhere, but maybe a small .h file with a typedef and a small C file would be more reliable
<stikonas>and I guess would fail more dramatically
<xentrac>but hey, if it compiles, ship it!
<stikonas>yeah, maybe...
<stikonas>but the thing is that only yacc compiles...
<stikonas>not lex :(
<xentrac>what is it complaining about?
<xentrac>it'd be nice if there was an option in lex and yacc to just not compile wchar_t support
<stikonas>see error 10 minutes ago...
<xentrac>taht looks like an error from yacc
<stikonas>yes
<xentrac>not cc
<stikonas>oh, so that's the error...
<stikonas>sorry, by not compiling
<stikonas>I meant yacc fails to build lex'es parser.y->parser.c
<xentrac>so are you saying yacc compiles but doesn't run right? or are those actually errors from cc? because I didn't know "redeclaration of precedence" was a C compiler error
<stikonas>this is error from yacc
<xentrac>I mean wchar_t was a later addition to C; you'd think there would be some kind of configure option for that. even though of course the Bell Labs guys were totally negative on #ifdef generally
<xentrac>and this is heirloom-lex, yes?
<stikonas>make runs "yacc parser.y"
<stikonas>and this spits those 4 warnings and error
<xentrac>did it really say "redeclaration of precedence of (nothing)"?
<stikonas>yes ...
<xentrac>heh
<stikonas>well, it's actually space
<xentrac>well, this is a stupid thing to say, but it sounds like it's not executing correctly
<stikonas>instead of (nothing)
<xentrac>"precedence of "?
<stikonas>hmm, maybe still something is broken when I patch those wide chars
<stikonas>it's a bit more interesting if I run on GNU flex
<xentrac>well, see above about possibly more kosher approaches to patching them
<stikonas> https://paste.debian.net/1181687/
<stikonas>yeah, maybe...
<stikonas>but not today
<stikonas>still the fact that yacc is building and not immediately exiting is promising
<xentrac>hey, that's a different error
<stikonas>maybe with proper patching it will just work
<xentrac>conflicts: 2074 shift/reduce, 644 reduce/reduce
<xentrac>"parse.y", line 874: fatal: cannot find parser /yaccpar
<xentrac>that last line makes me wonder if it's looking for a file "yaccpar" in the root directory
<xentrac>if you strace it you will see for sure whether it's doing that
<xentrac>and if so the culprit is probably an unset environment variable telling it where to find yaccpar
<stikonas>strace -e open I guess...
<xentrac>if you like yeah
<xentrac>I just use strace -ff and let 'er rip
<xentrac>then vgrep or use Emacs ^R to examine the resuts
<xentrac>*l
<stikonas>yeah, it looks in root folder
<stikonas>open("/yaccpar", O_RDONLY) = -1
<xentrac>well, hardly surprising it doesn't find it
<stikonas>oh, that's failed strcat
<xentrac>failed strcat?
<stikonas>parser = strcat(cp, "/yaccpar");
<stikonas>cp is empty I guess
<xentrac>well, it's good that it doesn't have any cp
<xentrac>we might have to report it to the FBI otherweise
<xentrac>but what is that variable supposed to have in it?
<stikonas>optarg...
<stikonas>oh I see
<stikonas>yaccpars is in yacc source folder
<stikonas>ok, then I can produce y.tap.{c.h} for gnu flex
<stikonas>s/tap/tab/
<stikonas>although, I still need lexer...
<stikonas>anyway, it's half-working
<stikonas>after lex is done, it should just work
<xentrac>hooray! congratulations!
<stikonas>well, but lex is not done..
<xentrac>it will be!
<fossy>NICE
<malina>stikonas[m], erm I built lex and yacc for my musl toolchain just yesterday
<malina>I don't think it's any worse, as it even has macros for glibc. what is your isse?
<fossy>malina: we are using mes libc toolchain
<malina>OH, wait you are using the bootstrapped toolchain of yours?
<fossy>yes
<malina>AH yes, sorry. :)
<fossy>tinycc and mes libc
<xentrac>fuck off, malina
<malina>I thought you were just trying to compile it to see if it was 'compatible', my bad.
<malina>nice !
<malina>I can report, that the heirloom lex /yacc for the record doesn't seem awfully up to compatiblity with the modern gnu tools
<fossy>no
<fossy>we are only using it for bootstrapping, but you're correct
<malina>inside my 'test toolchain', I'm kinda trying to make it as non-conformant as bleeding possible _just_ to see what fails or works etc. with the heirloom yacc/lex compiling in general got .. let's just say.. veyr wonky
<malina>well I am just saying, be aware that it's NOT just bottom up, but top down you need to keep an eye on by the time you have gotten to whereyou are :)
<fossy>?? we are doing this bottom up
<malina>I know
<gforce_d11977>fossy: CI does not mean you are always testing on another machine, it just means that you test while you develope. so CI-mode = easy testing. At the moment i see no easy method to fire up qemu with your approach, there is not even a readme! you are complaining about complexity, but i'am adding merely a oneline to a 160 line-script...
<fossy>gforce_d11977: the readme is going to be pushed in the restructure, i have it ready and waiting. CI = continuous integration, normally referring to the integration in the software development pipeline. i think it would confuse many users. your PR is also not a oneline and there is a very easy method to fire up qemu
<fossy>method being 1. copy a kernel to the root of repo with name kernel 2. ./rootfs.sh
<fossy>i don't think that the ideas behind your PR are bad fwiw
<fossy>just the current implementation needs a small amount of work
<fossy>also, fwiw, the definition of CI is not test while you develop, "Continuous Integration is a development practice where developers integrate code into a shared repository frequently where each integration is verified by an automated build and automated tests."
<fossy>i.e. automated testing of a PR
<Hagfish>i don't know why there isn't a name for the software engineering practice of automatically running builds and tests locally as you make changes
<Hagfish>perhaps that should be called CB/CT (continuous building / continuous testing)
<Hagfish>anyway, here's a blog post about someone using "entr" to achieve that: https://jvns.ca/blog/2020/06/28/entr/
<Profpatsch>entr looks cool, I wrote my own inotify wrapper a while ago but I’m not using it much.
<Profpatsch>The restart logic of “kill the currently running server when code changes, but only after the rebuild is finished” was one reason for that
<stikonas[m]>Anyway, I just run rootfs.sh when I test, the whole test is fairly easy
<fossy>yeah...
<fossy>development is admittedly less easy
<fossy>but there's not much we can do about that
<stikonas[m]>Well, I do like gforce_11977’s chroot mode for development
<fossy>yeah but there's like no shell to jump into or anything unless you put one there
<stikonas[m]>Yeah, for now...
<stikonas[m]>Hopefully bash will be ready soon
<fossy>well, bash seems to mostly work now, its just he bison issue, which cant use bash, lol
<fossy>i need to do more extensive testing of bash tho
<fossy>i think you're running into a weird problem in your chroot setup
<stikonas[m]>We'll sort it out I hope...
<fossy>we will
<gforce_d11977>fossy: "automated testing" is ofcourse also within a local githook | at the moment users must compile their own kernel, which is a at least annoying
<fossy>gforce_d11977: yeah, that's local development, not integrating a devleopers changes in the tree
<fossy>but whatever RE: CI
<fossy>wiht the compiling of own kernel, i am aware, and this is a bydesign thing.
<fossy>i don't want to distribute a kernel with the repository until i have a proper seed kernel
<gforce_d11977>fossy: 'entr' is interesting, but does not solve the problem of building the qemu-input (e.g. kernel + initrd)
<fossy>gforce_d11977: initrd is built...
<fossy>that's literally what rootfs.sh's main purpose is
<stikonas[m]>And kernel is only needed for qemu, not chroot
<fossy>gforce_d11977: re: kernel, i don't ever want to default to using a built kernel, but i am happy to add some 'normal general purpose defaults'
<stikonas[m]>So you can do testing without it
<gforce_d11977>fossy: stikonas: my idea was to "include a hidden busybox" in our initrd, so we can at the end just jump into a real shell in calling '/bin/busybox sh'
<fossy>stikonas[m]: although later in the build process we may require particular kernels in which case chroot may not always work
<fossy>gforce_d11977: no
<fossy>gforce_d11977: i refuse to distribute binary seeds other than hex0, kaem, kernel (when it becomes avaliable)
<stikonas[m]>Yeah, but we'll have shell then
<fossy>when we do have bash working interactively, however, we can jump into a shell
<fossy>(which will be compiled within the live system)
<stikonas[m]>It's close enough that we don't need to do busybox
<fossy>gforce_d11977: i'll review your PR in more detail now with some more specific cahgnes
<stikonas[m]>Best to spend time in bash
<stikonas[m]>s/in/on
<fossy>stikonas[m]: do you think kritis-linux should be a submodule (see gforce_d11977's PR)
<gforce_d11977>fossy: stikonas: yes, bash/shell seems near 8-) but till now i used this trick in my own build to have an easy "look-around-and-see-what-broke-and-how-to-fix-that"
<fossy>gforce_d11977: same (ive been using busybox for debugging) , but i don't want that included in the repo
<stikonas[m]>Yeah, I've also used busybox but I agree with fossy, not in repo
<gforce_d11977>fossy: stikonas: absolutely, i'am on your side, no binaries in repo
<stikonas>fossy: hmm, we probably don't need submodule, since there are a lot of ways to build kernel...
<stikonas>but it might be nice to have a way to build minimal kernel (i.e. that minilinux.sh)
<stikonas>but submodule probably is not worth it for one off build
<stikonas>anyway, I might be wrong person to ask whether building kernel is hard since I'm on Gentoo...
<stikonas>fossy: by the way, how should we include heirloom-devtools?
<stikonas>we only need a tiny bit (yacc/lex)
<gforce_d11977>stikonas: fossy: submodule is IMHO overkill/not needed. building a kernel is a hassle, especially if it comes to other architectures (e.g. arm) and also if your are not used to it...
<stikonas>but for testing you can just use your distro kernel...
<stikonas>yeah, I would think submodule is a bit overkill for optional thing
<fossy>stikonas: do they distrobute a rtarball
<fossy>gforce_d11977: yeah, i don't mind to much whether it is a submodule
<fossy>hm...
<fossy>gforce_d11977: actually, you know what, clone it into sysa/tmp
<fossy>that's proabbly the best solution cause that's already where all the tmp stuff it
<fossy>but make sure you clone a specific commit
<stikonas>fossy: no, it's cvs
<fossy>stikonas: oh ew
<fossy>i forgot about tt
<stikonas>there are some github mirrors
<stikonas>that are not official
<stikonas>or gitlab
<fossy>stikonas: this? https://sourceforge.net/projects/heirloom/files/heirloom-devtools/070527/
<fossy>not sure how new that is compared to cvs..
<stikonas>oh, that might be good!
<gforce_d11977>fossy: it *is* already cloned into sysa/tmp
<fossy>gforce_d11977: ooh, yeah, my bad
<fossy>lol
<fossy>idk how i missed that
***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<Hagfish> https://arxiv.org/pdf/1803.05385.pdf really interesting paper about distributed generation of random numbers, and the problem of Bulgarian judges being chosen by a computer system with a malicious user
<Hagfish>the proposal is (approximately) that participants on the network each reveal an encrypted message to each other, then reveal the decrypted plaintext, which is XORed together (and then hashed, if necessary, to make it uniform)
<Hagfish>the next question is, if you have a distributed network and a fair random number generator, why can't this be used in place of "proof of work" for a cryptocurrency?
<OriansJ>Hagfish: the point of proof of work is to make cheating on a distributed clock computationally hard to do. so the question becomes how can that system deal with people with financial reasons to cheat.
<OriansJ>As remote attestation does not work and never could work. How could fair random number generation be verified? Thus if the system requires fairness to function, you have a problem.
<OriansJ>a problem that can't be solved.
<Hagfish>yeah, remote attestation is a kind of sick joke, and the correct solution is transparency (i.e. any request for a Bulgarian judge needs to be sent out to multiple append-only logs, so that a malicious user can't re-roll the throws they don't like)
<Hagfish>OriansJ: i don't think that there will be "distributed clock" problems with a network that generates a random number every 10 minutes
<Hagfish>each node would be synced to UTC, and would generate its own encrypted random number at the start of each period, send it, and receive other nodes' random numbers for the next 2 minutes, then receive their decrypted random numbers for the next 2, then XOR
<Hagfish>the XOR would decide which node would write the next block of transactions, and they would be granted a small reward for doing so
<Hagfish>i guess the problem is reaching consensus across a lossy network
<Hagfish>if one eligible node doesn't send their encrypted random number (or they try to send it, but not every node receives it) then you have a split network
<Hagfish>forks do happen in bitcoin, but the network might be less sensitive to them because of it is race, and the longest chain (most difficulty) wins
<siraben>side note: reading parts of the bitcoin source I'm pretty sure Satoshi Nakamoto is a team of people, unless they really wrote C code in very different ways in one file to another
<siraben>it's also poorly written C in a lot of places
<stikonas>it's probably not that hard to deliberately write in different styles
<bauen1>siraben: if you write some project as an experiment you will end up with very different code styles all over
<bauen1>especially if it gets written over a long time
<siraben>that's true
<bauen1>(i haven't read the "original" bitcoin code, so can't judge that, but you can compare brainOS (myunix v1), myunix2 and myunix3 if you want some example of this)
<Hagfish>another thing to consider is, the more people you ask for help, the greater the chances of someone leaking that fact
<stikonas>yeah, especially if you do it over a long time, you learn some things and write new code better but might not have time to rewrite old things
<Hagfish>i think the original coins that "satoshi" mined haven't been moved, and are all in one account, so it's unlikely that a whole team has profited enough to keep things secret
<stikonas>yeah... and it might be that "satoshi" is not even alive today
<bauen1>kind of like a real-life "ready player one" thing
<pder>I looked into why bash segfaults in live-bootstrap and it happens in initialize_siglist() probably due to stubbed out code in mes libc
<pder>commenting out the call to initialize_siglist() allows bash to run scripts but no interactive shell
<stikonas>pder: I think for interactive shell you also need /dev/tty
<stikonas>pder: can you try to create it?
<stikonas>and see if it runs interactively
<stikonas>although, even ability to run scripts is good
<pder>Sure, also noticed configure scripts need stuff like /dev/zero
<stikonas>yeah, although, I would worry about that later...
<stikonas>we are still far away from bootstrapping autotools
<pder>I was also curious whats done differently in guix since it would seem it would run into the same issue
<stikonas>pder: doesn't guix have /dev inside build containers?
<stikonas>and bash is built with configure script
<stikonas>although, yes, it still uses mes libc
<stikonas>so one would think it should happen there as well
<stikonas>pder: maybe some of the config options?
<stikonas>also ac_cv_func_dlopen=no
<civodul>stikonas: there's a minimal deterministic /dev in build containers
<civodul> https://guix.gnu.org/manual/en/html_node/Build-Environment-Setup.html
<stikonas>ok, at the moment we have no /dev at all yet
<stikonas>well, I've just build mkdir in unmerged PR...
***nimaje1 is now known as nimaje
***coldtom0 is now known as coldtom
<gforce_d11977>fossy: have adapted my PR with your suggestions, thanks for the input
<OriansJ>Hagfish: that is the point of the proof of work to create an effective hard to fake distributed clock. Once you have a single centralized clock that everything is synced on. there is no need for most of the crypto work as you could just have a simple double entry ledger what is only valid when the clock releases the next block of recorded transactions.
<OriansJ>One thing you could do that would be even easier to chain of crypto. Where the source seed is known to everyone, as is the algorithm; Then you require that some block out of that stream is the next seed and a different block is the random value. As that would allow a universal verifiable "fair" random selection. As the person who sets the seed will not be able to predict the uses of the seeds 20years into the future; despite being able
<OriansJ>to predict what the values will be.
<OriansJ>The rules for using of the seed can absolutely be biased for a finite number of iterations but once you allow arbitrary starting points, the bias in the rules net out to zero.
<pder>stikonas: I tried creating /dev/tty /dev/console and a few others but bash still exits immediately. It also exhibits the same behavior outside of the chroot so it must be related to something else.
<stikonas>pder: ok...
<stikonas>well, at least non-interactive scripts work
<stikonas>that's most important for bootstrap...
<stikonas>I'll go back to yacc/lex this later today
<stikonas>hopefully can get bash "properly" bootstrapped
<pder>ill take a closer look later on why commenting out initialize_siglist was necessary
<gforce_d11977>fossy: i have added timestamps to the logoutput of qemu serial console, here is a full live-bootstrap run: http://intercity-vpn.de/1.txt
<Hagfish>OriansJ: interesting point about generating randomness from the blocks themselves. i'd need to understand quite a complex proof that the random number generator couldn't be profitably manipulated by specially crafted blocks
<Hagfish>i still don't understand the significance of the distributed vs. centralised clocks
<Hagfish>for example, even if all computers in the world contained quantum-entangled atomic clocks, that wouldn't mean that bitcoin miners wouldn't need to solve proof of work puzzles
<Hagfish>the PoW scheme serves, among other things, as a defence against Sybil attacks
<Hagfish>there has to be a way to chose which miner gets to define the next block, and having a centralised or decentralised agreement on wall-clock time doesn't make that any easier/harder
<Hagfish>unless you mean "clock" in some other sense, which includes the process for picking nodes (as in "clock cycles")
<stikonas>if you don't have proof of work then what is the incentive to build on the latest block?
<Hagfish>good question, hmm
<Hagfish>under the system i was proposing, nodes would build on the chain whose blocks were mined by the winner of the random lottery
<Hagfish>nodes could decide to break that rule, and appoint their own winner, but that would be equivalent to bitcoin nodes ignoring a specific chain after a fork
<Hagfish>the rule about which chain to follow is basically a Schelling Point
<Hagfish>i suppose with bitcoin you can check with an offline copy of the blockchain that each block really does have a hash value that matches the difficulty calculation
<Hagfish>in my system you would need to store all the encrypted and decrypted messages from all the nodes, to recreate the (pseudo)random number process
<Hagfish>and someone could forge those messages, i suppose, by generating a whole new set of public/private key pairs that claim to belong to the relevant participating IP addresses
<Hagfish>there could be a part of the protocol that records new nodes joining the swarm, and providing their public key
<Hagfish>so you could start with a Genesis set of nodes, and they could vote on bootstrapping up their network to potentially the maximum size of ~4bn nodes
<Hagfish>you could then reply all the messages offline to work out what the state of the network was at any given point in history
<Hagfish>*replay
<stikonas> /channel rename #bootstrappable #bitcoin :D