< bitcoin-git>
[bitcoin] kallewoof opened pull request #17994: validation: flush undo files after last block write (master...200124-rev-files) https://github.com/bitcoin/bitcoin/pull/17994
< kallewoof>
Nicolas Dorier has an interesting suggestion for Signet: use the same genesis block for all networks. I noticed that most implementations of software hard codes the genesis block hash, and would have to have rather complex code to deal with signet "dynamic genesis"... which defeats the purpose of Signet, since it's supposed to be easy and fun to drop in place when testing stuff. It obviously means light/non-block-
< kallewoof>
signature-checking nodes risk following the wrong chain, though...
< aj>
kallewoof: "easy to drop in" is just a different way of saying "light nodes risk following the wrong chain" i think...
< kallewoof>
aj: Right. I think having the magic number = sha256d(signet_challenge) would greatly reduce that risk, though. And presumably light nodes will connect to trusted peers already.
< kallewoof>
The big issue is if there are two parallel long-term signets and a light client on the less-work-chain accidentally finds a peer on the more-work-chain.
< aj>
kallewoof: maybe you could distinguish chains in a light friendly way by having different outputs in the coinbase of the block 1?
< kallewoof>
aj: one idea was to suggest that light clients download block 1 and verify it including its signature. But that means custom code.
< aj>
kallewoof: looking at the output is a wallet-y thing to do, and you could make it neverspendable as far as full nodes are concerned so it's always in the utxo set
< aj>
kallewoof: yeah, that sounds like as much custome code as it would be to cope with non-const genesis?
< kallewoof>
aj: I'm not sure I see what you're suggesting. Should we add an output in block 1 with OP_RETURN hash256(signet-challenge)?
< aj>
kallewoof: maybe an output in block 1 paying to p2pkh where the private key is hash256(signet-challenge) with an amount of 0?
< sipa>
have a checkpoint at block 1 to force a chain?
< aj>
have the block 1 hash be the signet challenge?
< aj>
no that makes no sense. but be the signet id maybe?
< kallewoof>
sipa: Can do that, but it means having to provide everyone with more parameters. Right now it has challenge and genesis_nonce and seed_nodes. With the static genesis block, we would drop to only providing challenge and seed node. providing the block 1 hash along sounds like it would mean more custom code (at least for non-full-sig-checking-nodes)...
< kallewoof>
aj: That would mean custom code to deal with validation. Would love to avoid
< kallewoof>
Bitcoin Core nodes would not need anything extra since they are checking the block signature for all blocks anyway. Light nodes would need something extra. The magic number being sha256d(challenge) would mitigate this to a great extent. Maybe simply provide the hash of block 1 as a checkpoint would be sufficient.
< aj>
kallewoof: p2pkh where the public key is NUMS+hash256(signet-challenge)*G (nums point from elements)
< kallewoof>
aj: someone could maliciously do this to multiple signet chains to screw with people.
< kallewoof>
aj: i.e. have a p2pkh in one chain that sends to a different signet challenge
< aj>
kallewoof: screwing with light nodes is trivial, this is just to prevent non-malicious accidents though?
< kallewoof>
hm.. using the magic number truncated hash & a checkpoint sounds like it achieves this without anyone getting screwed, though.
< aj>
kallewoof: if you were malicious you'd just build more unsigned blocks than the real chain after the checkpoint
< aj>
kallewoof: but yeah, a checkpoint sounds really simple to me
< kallewoof>
Yeah
< kallewoof>
So basically, "base parameters = challenge and (optionally but helpfully) 1+ seed nodes; for light clients, it is recommended that they also set the checkpoint block 1 = <given hash>". yeah, that sounds better.
< aj>
doesn't need to be block 1, i think?
< kallewoof>
if it is, we dont have to say which block it is
< aj>
checkpoints for block 50k after the signet's been up for a year could be helpful is all?
< luke-jr>
are these test networks or not? who cares if light clients follow the wrong chain? :/
< kallewoof>
luke-jr: if they are testing a specific feature, it would make no sense if they were on a chain that didn't support those features
< aj>
kallewoof: hm, testing anyprevout by saying "this challenge, and here's a checkpoint after anyprevout's been activated" seems appealing. be nice to solve the seed nodes by looking up hash(challenge).seeds.signet.org or something
< kallewoof>
thrown into a meeting, will comment soon. love the seeds.signet.org idea btw
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #17995: Load vcpkg port files from a separate repository. (master...vcpkg-ports-separate) https://github.com/bitcoin/bitcoin/pull/17995
< elichai2>
This is what needed to require that template T isn't of type MyClass `template<class T, typename std::enable_if<!std::is_same<typename std::remove_reference<T>::type, MyClass>::value, int>::type = 0>`
< luke-jr>
provoostenator: you can't reproduce it even with the random seed?
< provoostenator>
I'll try on an Ubuntu machine...
< provoostenator>
Is that random seed fixed, unique to the machine or random?
< provoostenator>
Oddly on macOS the test suite seems to ignore that environment variable. It's not getting echoed.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #17996: tests: Add fuzzing harness for functions with floating-point parameters (master...fuzzers-float) https://github.com/bitcoin/bitcoin/pull/17996
< provoostenator>
... yes, I'm able to reproduce on Ubuntu. Equally useless error message, but at least easier to debug this way than on Travis.
< provoostenator>
Mmm, I reproduced it once. And then it went away, not even make distclean makes it come back.
< sipa>
git clean -dfx naar de redding?
< provoostenator>
I tried that, with a backup of depends, didn't work. Now trying without a depends backup.
< provoostenator>
I also cleared ccache
< provoostenator>
That didn't help either. That's weird.
< sipa>
next step: swap out the motherboard
< provoostenator>
Yeah, I'm melting some candles above the CPU fan...
< gwillen>
huh, what kid of circumstances can produce "recipe for target failed" with no other visible errors
< gwillen>
I don't actually know that much about how make and testcases and such are plumbed in terms of output
< provoostenator>
My guess is that I'm doing something slightly evil in either system.{h,cpp} or src/test/system_tests.cpp that causes it to build incorrectly in some circumstance?.
< gwillen>
I assume stderr is getting piped into the log, so lack of error means that core is just crashing silently? Have you tried running it under valgrind and friends?
< provoostenator>
Not yet
< gwillen>
huh, the failing test _is_ under valgrind it looks like?
< gwillen>
I'm surprised that doesn't print _something_ out on any failure
< gwillen>
and that's the only one that failed, curious
< bitcoin-git>
[bitcoin] emilengler opened pull request #17998: gui: Shortcut to close modaloverlay (master...2020-01-escape-modaloverlay) https://github.com/bitcoin/bitcoin/pull/17998