< eugene9999> And this is an add on to my previous Q’s - getting rid of a switch statement gets rid of lots of branches but doesn’t really mitigate the edge collision problem. I guess the one harness per target methodology is to reduce number of branches + not confuse the fuzzer with certain mutations being used on the wrong message type, right?
< gmaxwell> eugene9999: it's not really that much of a concern.
< CubicEarth> would it be straightforward to implement an RPC command, whose argument would be a block height, that would prevent a node from downloading any blocks above that height?
< fanquake> sipa, wumpus Might be time to just block this guy from the repo.
< fanquake> Spamming, troll PRs, now comments like this: https://github.com/bitcoin/bitcoin/issues/15049#issuecomment-450540096
< achow101> fanquake: +1
< gkrizek> fanquake +1
< luke-jr> CubicEarth: features need a use case
< CubicEarth> luke-jr: the purpose would be to allow a lightning node to manage the disk space bicoind uses. PUNEBLOCKCHAIN gives granular control on the back side...
< luke-jr> think it would be better to let bitcoind manage its own disk space..
< CubicEarth> Do you have a concept of how that would look?
< luke-jr> CubicEarth: something like the -prune option, but instead of pruning, waits for the manual prune to free space
< CubicEarth> luke-jr: So blocks are downloaded until the space limit is reached... and then when X MBs of blocks are manually pruned off the back, X MBs of blocks can be downloaded on the front?
< luke-jr> CubicEarth: right
< CubicEarth> luke-jr: from the external perspective, that seems just as functional
< luke-jr> CubicEarth: the difference IMO, is that eventually we probably should move to a "prune lock" system, where multiple external programs can prevent pruning until they've caught up
< CubicEarth> Oh right, I remember discussing that before. It's not a bad idea, but the range of usefulness, in terms of number of devices, seems limited. If there are too many devices (somewhere in the 5 - 20 range, I'd guess), they would better be served by an unpruned node
< CubicEarth> Otherwise a device that misbehaves can mess it up for the others
< luke-jr> not really
< CubicEarth> "misbehaving" is too strong a word... they would all have to be sufficiently synchronized
< bitcoin-git> [bitcoin] luke-jr opened pull request #15063: GUI: If BIP70 is disabled, attempt to fall back to BIP21 parsing (master...bip70_fallback_to_bip21) https://github.com/bitcoin/bitcoin/pull/15063
< bitcoin-git> [bitcoin] luke-jr opened pull request #15064: [PoC] GUI: Migrate BIP70 merchant info to mapValue["to"] (master...bip70_merchant_to_to) https://github.com/bitcoin/bitcoin/pull/15064
< wumpus> fanquake: agree
< wumpus> fanquake: blocked on bitcoin and bitcoin-core
< bitcoin-git> [bitcoin] promag opened pull request #15065: 0.17: Backport #14123 #14133 #14383 #14597 (0.17...backport-14123-14133-14383-14597) https://github.com/bitcoin/bitcoin/pull/15065
< fanquake> wumpus thanks. #15053 is a trivial merge btw.
< gribble> https://github.com/bitcoin/bitcoin/issues/15053 | [0.17] Backport #14966 by fanquake · Pull Request #15053 · bitcoin/bitcoin · GitHub
< promag> fanquake: hi, what you use vmware, parallels or other?
< fanquake> promag Have been using Virtualbox for a while. Also use Vagrant for a few things, which uses Virtualbox under the hood.
< promag> fanquake: and performs well with windows?
< fanquake> promag I have some core specific vagrant configurations in https://github.com/fanquake/core-review/
< fanquake> promag For Windows testing I use the VMs available from here: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
< fanquake> Haven't tried any "native" builds yet, just install WSL and use depends
< promag> fanquake: ok, thanks for the links!
< fanquake> promag np, let me know if you have any more questions
< bitcoin-git> [bitcoin] bitcoinVBR opened pull request #15067: Feature vbr (master...feature_VBR) https://github.com/bitcoin/bitcoin/pull/15067
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.17: https://github.com/bitcoin/bitcoin/compare/fa941016e8c1...623a19bc2b34
< bitcoin-git> bitcoin/0.17 b4602e3 1Il1: fix testmempoolaccept CLI syntax...
< bitcoin-git> bitcoin/0.17 623a19b Wladimir J. van der Laan: Merge #15053: [0.17] Backport #14966...
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 new commits to 0.17: https://github.com/bitcoin/bitcoin/compare/623a19bc2b34...16521ce08676
< bitcoin-git> bitcoin/0.17 ddd008d Pieter Wuille: Add PSBT documentation...
< bitcoin-git> bitcoin/0.17 88c566a priscoan: doc: Fix PSBT howto and example parameters...
< bitcoin-git> bitcoin/0.17 fa0c76a bitcoinhodler: Fix minor grammar error in doc...
< arubi> I'm catching up with gitian builds and planning on PRing a bunch of sigs hopefully tomorrow or the day after (slow pc). should I create one PR per version or all in one?
< wumpus> arubi: all in one is OK, you could use seprate commits per versions if that helps organizing
< bitcoin-git> [bitcoin] fanquake closed pull request #15067: Feature vbr (master...feature_VBR) https://github.com/bitcoin/bitcoin/pull/15067