--- Log opened Thu Aug 16 00:00:41 2018 00:06 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 00:18 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 00:26 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Quit: ZNC 1.7.0 - https://znc.in] 00:28 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev 00:49 < gmaxwell> sipa: 13989 is doing avx512 sha256d64, and gets a 19% speedup for the MerkleRoot benchmark. 00:57 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 01:12 -!- joshb[m] [joshbmatri@gateway/shell/matrix.org/x-qjsopuejknktjbxp] has quit [Read error: Connection reset by peer] 01:12 -!- squarfed[m] [squarfedma@gateway/shell/matrix.org/x-imjfruilmaepomkt] has quit [Write error: Connection reset by peer] 01:12 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-nyqlkxyfzgueuysk] has quit [Read error: Connection reset by peer] 01:17 -!- savil [savilmatri@gateway/shell/matrix.org/x-etxndewahlljdhqo] has joined #bitcoin-core-dev 01:19 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [] 01:20 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 01:25 < wumpus> time to tag rc1? 01:27 < wumpus> I'm sure enough issues will come up during gitian building (although I was able to do so succesfully) for the first time with bionic, but I think it makes sense to start testing? 01:33 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 01:34 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev 01:37 -!- reallll [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 01:38 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 01:47 -!- ExtraCrispy [~ExtraCris@67.215.11.12] has joined #bitcoin-core-dev 01:56 -!- murrayn [~dafuq@unaffiliated/murrayn] has joined #bitcoin-core-dev 01:57 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 01:58 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 02:05 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 02:40 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Remote host closed the connection] 02:42 -!- Jmabsd [~jmabsd@pcd247152.netvigator.com] has quit [Read error: Connection reset by peer] 02:44 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 02:44 < fanquake> wumpus sounds good 02:48 < wumpus> ok! let's do it then 02:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:56 < wumpus> yesterday no one protested either so... 02:56 -!- dcousens [~dcousens@110.140.174.10] has quit [Ping timeout: 244 seconds] 02:57 -!- dcousens [~dcousens@110.140.174.10] has joined #bitcoin-core-dev 02:58 < fanquake> Just take that as silent optimism/agreement or something 03:01 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.] 03:02 < wumpus> I'm just trying to avoid forgetting a dumb step (yes, version has been bumped) 03:08 < wumpus> * [new tag] v0.17.0rc1 -> v0.17.0rc1 03:10 < wumpus> there we go 03:11 < fanquake> That's what rc's are for anyways. Wouldn't be the first time we've fixed something up quickly with an rc2 etc. 03:11 < fanquake> wew! 03:13 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev 04:08 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 04:16 -!- rex4539 [~rex4539@2a02:587:3516:600:501e:2e3c:67e:5260] has joined #bitcoin-core-dev 04:17 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 04:36 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Read error: No route to host] 04:38 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 04:53 < wumpus> 0.17.0rc1 gitian sigs (unsigned) up, wonder if anyone reproduces 04:57 < jonasschnelli> wumpus: still building: https://bitcoin.jonasschnelli.ch/build/743 04:58 < jonasschnelli> windows and osx match though... linux: will see 05:06 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Remote host closed the connection] 05:06 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev 05:14 < wumpus> awesome ! 05:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 05:22 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has joined #bitcoin-core-dev 05:25 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 05:25 < jonasschnelli> linux is a match as well 05:26 -!- Krellan [~Krellan@2601:640:4000:9258:7c56:e7e3:77dd:3c96] has quit [Read error: Connection reset by peer] 05:26 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 05:27 -!- Krellan [~Krellan@2601:640:4000:9258:a801:65f2:b64f:68a1] has joined #bitcoin-core-dev 05:58 < jonasschnelli> Benchmarks for v2 message format composing (encrypted): 05:59 < jonasschnelli> 100 blocks: V1 legacy (dblSHA): 1.43978, V2 (ChaCha20/Poly1305): 1.42594 05:59 < jonasschnelli> (and this is with SHA SSE4.1/AVX versus non NI acceletarted chacha) 06:20 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:22 < fanquake> thanks for the quick build ken2812221, more matching sigs 06:28 -!- ken2812221_ is now known as ken2812221 06:28 < ken2812221> fanquake: nice 06:32 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 06:32 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 06:34 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 06:34 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 06:36 < wumpus> jonasschnelli: nice 06:36 -!- asoltys [~adam@115.96.198.104.bc.googleusercontent.com] has quit [Ping timeout: 268 seconds] 06:39 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 260 seconds] 06:48 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 06:58 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 07:13 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 07:20 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev 07:22 < promag> with 0.17 branched, #13529 can be reviewed 07:23 < gribble> https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub 07:23 < promag> wumpus: ^ 07:23 < promag> maybe I should push a rebased commit? 07:25 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 07:25 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has quit [Ping timeout: 265 seconds] 07:35 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev 07:37 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 07:38 < wumpus> promag: will review 07:39 < wumpus> looks like you first need to address the issues, apparently you did break some things! 08:05 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 08:05 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 08:09 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 08:10 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 240 seconds] 08:11 < promag> wumpus: yeah I saw that after writing the above :( 08:15 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving] 08:15 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev 08:33 < gmaxwell> jonasschnelli: well the reason I was offering to try sticking on newhope is that I _think_ I can add it in with only a few lines code change. If we're of the view that we'll want it long term, then maybe it'll make sense to do up front if it really does turn out to be that simple. 08:35 < jonasschnelli> gmaxwell: Yes. Agree. I just too deep into implementing the ecdh/chachapoly stuff right now... but as soon as some tests are finished, I'm happy to try the NH implementation. 08:35 < jonasschnelli> I need to research (or ask you) a bit more, though 08:35 < gmaxwell> OKAY but thats why I was offering to help. :P 08:35 < gmaxwell> Sure. Fortunately it's really simple. 08:36 < jonasschnelli> What implementation are you looking at? 08:37 < jonasschnelli> Doesn't it also require SHA3? 08:37 < gmaxwell> https://github.com/newhopecrypto/newhope-usenix/tree/master/ref 08:37 < gmaxwell> No. 08:37 < jonasschnelli> ok 08:37 < gmaxwell> it uses chacha20 internally just as a random number generator. 08:38 < gmaxwell> oh actually there is a sha3 impl there too. I guess it's using that to hash the final state. 08:38 < jonasschnelli> gmaxwell: replace that with sha2? -> https://github.com/newhopecrypto/newhope-usenix/blob/master/ref/newhope.c#L58? 08:39 < gmaxwell> yes, we can just replace that with sha2. 08:49 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 08:50 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 08:51 < gmaxwell> You see how it works though? https://github.com/newhopecrypto/newhope-usenix/blob/master/ref/test/test_newhope.c#L36 Initator runs newhope_keygen and sticks senda on their message, responder runs newhope_sharedb with that as an argument and gets the shared keyb and sendb to send, intiator gets sendb and feeds it to newhope_shareda and gets the same shared secret out. 08:53 < gmaxwell> The messages are constant length (1824 and 2048 bytes IIRC). 08:55 < gmaxwell> And we'd probably go and change the API slightly so that it takes randomness as an argument rather than reading /dev/urandom itself. 08:57 < gmaxwell> though for an intial test that could be ignored. 09:01 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:98e6:a9c0:ee38:c1b3] has joined #bitcoin-core-dev 09:06 -!- ExtraCrispy [~ExtraCris@67.215.11.12] has quit [Remote host closed the connection] 09:08 < jonasschnelli> gmaxwell: so it basically works the same as DH (in terms of network interactions)? 09:09 < jonasschnelli> Could we append send_a (the message) to the ecdh-32byte-pubkey? 09:10 < jonasschnelli> I guess the NH handshake doesn't have to follow under the ECDH encrypted channel? 09:12 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Ping timeout: 260 seconds] 09:13 < gmaxwell> Correct on all counts. 09:13 < gmaxwell> It's not _exactly_ the same as DH in terms of network interactions because in DH both alice and bob can send their pubkeys at the same time, but in newhope alice sends then bob sends. But we're not using DH that way anways. 09:14 < gmaxwell> So we can implement it just by appending send_a to the initator pubkey, and send_b to the responder pubkey. 09:15 < gmaxwell> then we just hash the secrets that come out of both DH and newhope. 09:16 -!- LeMiner [~LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer] 09:17 < jonasschnelli> gmaxwell: I see. Whats the length of the newhope secret output? 32b? 09:21 < gmaxwell> 32 bytes, yes. 09:23 < jonasschnelli> Okay. From a protocol level, this seems easy. 09:24 < jonasschnelli> Are the NH messagedsidentifiable (DPIish)? 09:25 < gmaxwell> No, not more than the secp256k1 public keys. 09:26 < jonasschnelli> ok. then ECDH doesn't need to go first 09:27 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 09:28 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 09:30 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 09:32 < jonasschnelli> yeah. I don't see a reason why we should not add newhope to the handshake (unless I completely must understand it) 09:35 < gmaxwell> The only arguments I can make against it are that (1) it might turn out to not add much security (e.g. if newhope gets broken), and then we're stuck carrying it around buring bytes, loc, and cpu cycles on it (2) implementers that insist on writing everything from scratch instead of using public domain C code will have a harder time, (3) more stuff to integrate. 09:36 < gmaxwell> For other applications, like using it in SSL the size and speed impacts matter more. For us, I think they're basically irrelevant. Newhope is as fast as (or maybe even faster than, with AVX in use) ECDH. 09:39 < jonasschnelli> I hope my implementation for detecting a version message or a key-handshake will still work since it's now longer then 32b 09:40 < gmaxwell> You should just be able to read the first N bytes and decide, then keep reading. 09:44 < jonasschnelli> yeah... avoid pubkeys with netmagic, read 4 bytes and continue with handshake when not equal the net magic 09:46 < wumpus> RISC-V node (on actual hw) started syncing 09:49 < sipa> wooho 09:49 < gmaxwell> wumpus: \O/ 09:50 < gmaxwell> now just submit some patches upstream to add hardware SHA2 and ECC so that the next one will finish in reasonable time. :P 09:53 < sipa> just add a HW instruction vrfybtcnblk 09:53 < sipa> wait, what did the R in RISC stand for again? 09:53 < wumpus> hehe 09:54 < gmaxwell> well, brainfuck has fewer operations, so clearly RISCV isn't RISC? :P 09:54 < wumpus> it stands for Rich Instruction Set Computing 09:54 < sipa> ah. 09:54 < sipa> gmaxwell: try whitespace 09:55 < sipa> i guess whitespace has more instructions, but just encoded in 3 characters 09:55 < gmaxwell> wumpus: as opposed to constrained instruction set computing? 09:55 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has joined #bitcoin-core-dev 09:56 < wumpus> though tbh at this point I'm less worried about performance than about obscure chip and compiler issues 09:56 < wumpus> gmaxwell: exactly! 09:57 -!- thebiglq12345 [~thebiglq1@pool-108-6-186-213.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 09:59 < gmaxwell> jonasschnelli: in any case, newhope is a member of the class of fast PQ schemes that are newer and more likely to turn out to be insecure against even classical computers. But the only alternatives that aren't have properties that would make us not use them.. e.g. the McEliece public keys are like 1MB. 10:14 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 244 seconds] 10:33 < gmaxwell> jonasschnelli: oh, actually we'd want to be using this implementation https://github.com/newhopecrypto/newhope/tree/master/ref as it's their NIST submission, and has a substantial simplifcation to the protocol innards. 11:00 < jonasschnelli> ok. thanks... I'll look into it. 11:01 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 11:02 < wumpus> apparently the MMC interface on the HiFive unleashed is really slow, either due to the current kernel version, or due to some hardware limitation 11:04 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 260 seconds] 11:04 < wumpus> the debian/fedora developers use nbd, though currently I have a 100mbit switch connected for the embedded LAN so that's not going to be great either :-) 11:08 < wumpus> but all in all I'm quite happy with this, for the first larger-scale ASIC implementation of a new architecture it's cool how far this gets 11:08 < sipa> the risc-v instrunction encoding is pretty cool 11:09 < sipa> everything is natively a 32 bit instruction, but there are optional extensions that compress certain instructions down 11:09 < wumpus> yes how they do variable-length is interesting 11:09 < sipa> but that compression can be implemented as a pure postprocessing step in the assembler 11:10 < wumpus> isa : rv64imafdc I think -c is the 16-bit compressed instruction extension, so it has that 11:11 -!- ken2812221 [~ken281222@180.217.133.119] has quit [Ping timeout: 272 seconds] 11:11 -!- Randolf [~randolf@96.53.47.42] has quit [Quit: Leaving] 11:12 -!- Krellan [~Krellan@2601:640:4000:9258:a801:65f2:b64f:68a1] has quit [Ping timeout: 260 seconds] 11:12 < wumpus> M=Integer 11:13 < wumpus> Multiplication and Division, A=Atomic instructions, F=32-bit fp, D=64-bit fp, C=Compressed instructions 11:13 -!- Krellan [~Krellan@2601:640:4000:9258:a801:65f2:b64f:68a1] has joined #bitcoin-core-dev 11:13 < sipa> no B=bit manipulation? 11:13 < wumpus> apparently not! 11:14 < wumpus> "This chapter is a placeholder for a future standard extension to provide bit manipulation instruc- 11:15 < sipa> ah 11:15 < wumpus> the version of the spec I have calls it future, at least 11:15 < sipa> i guess basic bit manipulation is available in the base set of instructions 11:16 < wumpus> yes: ANDI/ORI/XORI 11:17 < wumpus> they're in the mandatory part 11:18 < wumpus> I guess the idea of -B will be to provide a more extensive set, say for direct injection/extraction of bit sequences, popcount, count leading/trailing bits, etc 11:21 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.] 11:22 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 11:22 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 11:23 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 11:35 -!- grafcaps [~haroldbr@104.137.194.255] has joined #bitcoin-core-dev 11:35 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 11:35 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 11:39 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Read error: Connection reset by peer] 11:42 < jonasschnelli> gmaxwell: I guess a configuration option that would allow ecdh only handshake would make little sense? 11:42 < jonasschnelli> I down side with newhope could be the implementation burden if we also want SPV clients to adopt it. 11:44 -!- davex__ [~user@97-119-97-211.omah.qwest.net] has left #bitcoin-core-dev ["Leaving"] 11:45 -!- Krellan [~Krellan@2601:640:4000:9258:a801:65f2:b64f:68a1] has quit [Remote host closed the connection] 11:45 < gmaxwell> jonasschnelli: I don't think it would make sense to make it optional. 11:45 -!- davex__ [~user@97-119-97-211.omah.qwest.net] has joined #bitcoin-core-dev 11:46 < gmaxwell> jonasschnelli: there are, for example, java implementations and whatnot. 11:46 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 11:47 -!- thaumavorio [~thaumavor@thaumavor.io] has joined #bitcoin-core-dev 11:48 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 11:50 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 12:01 < promag> meeting? 12:01 * luke-jr pokes wumpus 12:03 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev 12:03 < wumpus> hello 12:03 < sdaftuar> hi 12:03 < wumpus> #startmeeting 12:03 < lightningbot> Meeting started Thu Aug 16 19:03:54 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:03 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:03 < jonasschnelli> Yeah... hi 12:04 < meshcollider> hi 12:04 < promag> hi 12:04 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark mi 12:04 < wumpus> chagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator 12:04 < gmaxwell> darn, just beat me to it. 12:04 < achow101> hi 12:04 < sipa> hi 12:04 < wumpus> apparently I divided michagogo in two 12:04 < sdaftuar> ouch 12:05 < meshcollider> Hope he's not too cut up about it 12:05 < wumpus> PSA: we've tagged 0.17.0rc1, let us know if you have any trouble gitian-building due to the upgrade of the guest to Ubuntu 18.04/bionic 12:05 -!- ken2812221 [~androirc@2001-b400-e28f-9c9b-60f1-1b5a-b7fe-3f56.emome-ip6.hinet.net] has joined #bitcoin-core-dev 12:06 < jonasschnelli> As mentioned its a bit sad that we dropped debian 9 (newest version) as gitian host,... but apparently compiling lxc was simpler then expected 12:06 < wumpus> now that 0.17 release cycle is started, it might be time to bring back "high priority for review" as a topic 12:06 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [Read error: Connection reset by peer] 12:07 < wumpus> I have some instructions for debian 9 here: https://gist.github.com/laanwj/c62e101bfd68718f0686926dfd10666b 12:07 < jtimon> hi 12:07 < wumpus> (yes, you need to build lxc and debootstrap from source) 12:07 < jonasschnelli> Nice wumpus 12:07 < wumpus> we should probably integrate that into the documentation 12:08 < jonasschnelli> Yes. Until lxc 2.1.1 is supported by debians apt 12:08 < wumpus> yes, 3.x is probably overkill 12:08 < luke-jr> wumpus: did we ever get a solution for making a bionic base VM? :/ 12:08 < jonasschnelli> Works fine here with 2.1.1 12:09 < luke-jr> (for qemu) 12:09 < achow101> also, with the suite bump, don't forget to do bin/make-base-vm again 12:09 < wumpus> luke-jr: I don't think so, I think LXC and Docker are the only options at the moment 12:09 < luke-jr> achow101: last I checked that doesn't work 12:09 < achow101> luke-jr: there's a fork of vmbuilder that works for bionic 12:09 -!- viaj3ro [AdiIRC@31.16.118.221] has joined #bitcoin-core-dev 12:09 < achow101> luke-jr: https://github.com/newroco/vmbuilder 12:10 < luke-jr> #link https://github.com/newroco/vmbuilder 12:10 < wumpus> but the fork might be worth a try ! 12:10 < achow101> luke-jr: see also https://github.com/devrandom/gitian-builder/issues/191 12:11 < wumpus> anyhow -- please ask in this channel if you have any problems getting gitian running 12:11 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev 12:12 < wumpus> #topic High priority for review 12:12 < wumpus> https://github.com/bitcoin/bitcoin/projects/8 there's only one PR in there at the moment, #13100 12:12 < gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub 12:12 < sipa> i'd like #13723 12:12 < gribble> https://github.com/bitcoin/bitcoin/issues/13723 | PSBT key path cleanups by sipa · Pull Request #13723 · bitcoin/bitcoin · GitHub 12:13 < sipa> (it's the basis for further psbt/descript integration) 12:13 < instagibbs> https://github.com/bitcoin/bitcoin/pull/13968 bugfixes for psbt stuff too(0.17 backport) 12:13 < instagibbs> #13968 12:13 < gribble> https://github.com/bitcoin/bitcoin/issues/13968 | [wallet] couple of walletcreatefundedpsbt fixes by instagibbs · Pull Request #13968 · bitcoin/bitcoin · GitHub 12:14 < ken2812221> #13866 12:14 < gribble> https://github.com/bitcoin/bitcoin/issues/13866 | utils: Use _wfopen and _wfreopen on Windows by ken2812221 · Pull Request #13866 · bitcoin/bitcoin · GitHub 12:14 < wumpus> 13723 added 12:15 < jtimon> if high priority is still for blockers, https://github.com/bitcoin/bitcoin/pull/13311 is kind of a blocker for https://github.com/bitcoin/bitcoin/pull/8994 which is itself a blocker for toher things I wanted to do 12:15 < wumpus> the other two as well 12:15 < wumpus> #13311 12:15 < gribble> https://github.com/bitcoin/bitcoin/issues/13311 | Dont edit Chainparams after initialization by jtimon · Pull Request #13311 · bitcoin/bitcoin · GitHub 12:16 < promag> wumpus: can you replace 13100 with #13529? 12:16 < gribble> https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub 12:17 < wumpus> promag: ok 12:17 < wumpus> jtimon: added 12:17 < jtimon> yeah, thanks 12:17 < achow101> I would like #12493 12:17 < gribble> https://github.com/bitcoin/bitcoin/issues/12493 | [wallet] Reopen CDBEnv after encryption instead of shutting down by achow101 · Pull Request #12493 · bitcoin/bitcoin · GitHub 12:17 < promag> ty 12:17 < wumpus> achow101: ok, yes, probably makes sense to merge that early in the 0.18 cycle 12:18 < wumpus> achow101: it sounds sort of--risky 12:18 < gmaxwell> achow101: did we ever work through the problems that were preventing "don't create a wallet until a key is requested or until encryption is added" ? 12:18 < gmaxwell> As that would also get rid of the shutdown on encryption for many users. 12:18 < achow101> gmaxwell: the problems with that were backups IIRC 12:19 < achow101> gmaxwell: actually that problem was with generate keys on use, not create wallet on use 12:19 < achow101> in that case, I don't think so. but I also don't remember the problems with create wallet on use. I think I just never got around to implementing it 12:20 < gmaxwell> right. I thought there were some dumb bugs with create on use that were going to get fixed as a side effect of pending multiwallet work. 12:20 -!- ken2812221 [~androirc@2001-b400-e28f-9c9b-60f1-1b5a-b7fe-3f56.emome-ip6.hinet.net] has quit [Remote host closed the connection] 12:21 < wumpus> any other proposed topics? 12:21 -!- ken2812221 [~androirc@2001-b400-e28f-9c9b-60f1-1b5a-b7fe-3f56.emome-ip6.hinet.net] has joined #bitcoin-core-dev 12:22 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 12:23 < sipa> short announcement: we're working on an extension to descriptors to support nested and/or/threshold constructions 12:25 < wumpus> cool! 12:25 < sdaftuar> topic suggestion: open floor for people to share what they 12:25 < jonasschnelli> nice 12:25 < sdaftuar> re wokring on 12:26 < sdaftuar> (since we don't have any other topics apparently :P) 12:26 < sipa> i like wok rings 12:26 < wumpus> #topic open floor for people to share what they are working on 12:26 < jonasschnelli> Working on p2p level encryption since a couple of weeks (thats why I'm pretty quite on github). Will open PR in 1-2 weeks. 12:27 < wumpus> sipa: so this is for further improvements to scantxoutset I suppose? 12:27 < sipa> wumpus: and all the things :) 12:27 < wumpus> right 12:27 < sipa> wumpus: so you can import and(xpub/...,or(xpub/...,xpub/...)) into your wallet as watch-only chain for example 12:27 < achow101> wumpus: hopefully for eventually a replacement-ish thing to the wallet 12:27 < sipa> and get psbt to sign for it 12:28 < instagibbs> so excite 12:28 < wumpus> that's neat 12:28 < jonasschnelli> sipa: how would/could that lead to xpub watch only wallets? 12:28 < sipa> jonasschnelli: yes 12:29 < sipa> that's the goal of the descriptors 12:29 < instagibbs> achow101, not sure if he was joking, but he said he wouldnt have to implement it if I did the HWI version. I'll keep leaning on him 12:29 < jonasschnelli> That would be a great feature... could also be extended to the GUI including coin selection (send screen), but don't sign/broadcast (obviously) but will create a PSBT (file) 12:30 < instagibbs> my guess is for any hope of Core support of HWW, we want to not have to support a bunch of PSBT drivers... 12:30 < instagibbs> oh sorry wrong window 12:30 < jonasschnelli> instagibbs: you mean more support then the PSBT? 12:31 < sipa> jonasschnelli: seems reasonable yes 12:31 < sipa> i need to think through how to integrate things in the wallet itself, so you can import descriptors 12:31 < sipa> and how to make it compatible with all existing RPCs etc 12:32 < gmaxwell> sipa: not just and/or/threshold but also CSV and hashlocks? 12:32 < instagibbs> gmaxwell, yes 12:32 < sipa> gmaxwell: oh yes 12:32 < instagibbs> (oh rhetorical) 12:32 < sipa> but my goal is that the wallet eventually consists of a bunch of descriptors with metadata (and labels and transactions, and precomputed pubkeys to replace keypools) 12:33 < gmaxwell> If lots of people can help sipa finish that work it would be good. :P 12:34 < sipa> but independently andytoshi and i started looking into how we can efficiently compile arbitrary and/or/k-of-n/locktime/hash expressions to script 12:34 < sipa> which would just plug into descriptors, and then be available to everything that uses them 12:35 -!- ken2812221 [~androirc@2001-b400-e28f-9c9b-60f1-1b5a-b7fe-3f56.emome-ip6.hinet.net] has quit [Remote host closed the connection] 12:35 -!- ken2812221 [~androirc@2001-b400-e28f-9c9b-60f1-1b5a-b7fe-3f56.emome-ip6.hinet.net] has joined #bitcoin-core-dev 12:36 < wumpus> so I"ve been working on the RISC-V support, today I was able to do basic bring-up of the hardware (HiFive Unleashed) and test the gitian-built executables, which work! 12:36 < wumpus> been able to run the test_bitcoin succesfully and sync part of the chain, I'll keep the node running 12:36 < wumpus> probably the first RISC-V bitcoin node in the world 12:37 < jonasschnelli> \o/ nice! 12:37 < gmaxwell> nmkgl and I have been working on reconciliation based transaction relay. (With sipa's help too, that why I want people to help finish the descriptor work, ... :P ) 12:38 < sdaftuar> gmaxwell: as in set reconciliation, eg to sync mempools? 12:38 < sipa> sdaftuar: yup 12:39 < gmaxwell> sdaftuar: Yes, but I believed we found a better design that doesn't sync the mempools directly. 12:39 < sdaftuar> neat, i'd be interested in learning more if you guys have a summary at some point. 12:39 < sipa> sdaftuar: it uses a more computationally expensive set reconcilation protocol than IBLT, but it's much more space efficient 12:40 < gmaxwell> muuuch more. 12:40 < sipa> (basically the amount of data transferred is equal to the expected difference between the two sets) 12:41 < sipa> but it's in the order of 40ms here to find 300 differences 12:41 < gmaxwell> I also came up with a new reconcilation protocol with a different performance tradeoff (much faster to decode, but slightly less space efficient), though it doesn't look like we'll have cause to use it. 12:42 < gmaxwell> sdaftuar: in any case the short summary of what we're thinking now vs before is that instead of reconciling mempools, reconcile the transactions that the peers would have otherwise INVed to each other. 12:42 < gmaxwell> this avoids cases like a mempool policy difference causing transations to get 'stuck' in the difference set forever until they get mined. 12:42 < sipa> oooh nice 12:42 < sipa> i missed that 12:43 < gmaxwell> Then it can just be coupled with some simple mechenism to fast-start an empty or stale mempool. 12:43 < gmaxwell> (I have a proposal for that too, just a simple one/two message protocol) 12:44 -!- ken2812221 [~androirc@2001-b400-e28f-9c9b-60f1-1b5a-b7fe-3f56.emome-ip6.hinet.net] has quit [Remote host closed the connection] 12:44 < instagibbs> would this be complementary to a ip-hiding protocol like dandelion? 12:44 < sdaftuar> ah, that sounds neat 12:44 < BlueMatt> hmm, and then you could bucket and do reconciliation slowly for low-feerate buckets, or no reason to do that anymore? 12:44 < BlueMatt> instagibbs: I'd presume so, this would be during fluff-faze :p 12:44 < sipa> instagibbs: yes, orthogonal 12:45 < sipa> this is changing the diffusion phase 12:45 < sipa> not the stem 12:45 < instagibbs> BlueMatt, not exactly fluffing anymore :) 12:45 < gmaxwell> instagibbs: it's orthorgonal, the main motivation is getting rid of the really high bandwidth overhead for rumoring. 12:45 < instagibbs> sipa understood 12:45 < gmaxwell> Probably some differences in context here. :) 12:45 < gmaxwell> Right now, ignoring peers that IBD, the vast majority of node bandwidth is wasted on INV rumoring. 12:45 < BlueMatt> gmaxwell: wait, was that a response to my question? 12:46 < gmaxwell> BlueMatt: sure, it could be split by feerate too, though I'm not sure we'll have a reason to because the reconcilation is so efficient. 12:46 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 12:46 < BlueMatt> hmm, guess I need to think about this more 12:46 < sdaftuar> do you have an estimate on the bandwidth reduction? 12:47 < gmaxwell> No, don't have a mature enough simulator yet. Also I haven't measured overheads since we improved inv batching. 12:49 < gmaxwell> But previously INV overhead was something like 80% of node bandwidth (excluding IBDing peers). 12:49 < gmaxwell> And this should mostly eliminate that overhead. 12:50 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 12:52 < wumpus> looks like we've run out of topics, but not out of time yet 12:52 < gmaxwell> In any case, we've been largely off in number theory land optimizing the recon itself... but I think we've got what we need there now. :) 12:53 < sdaftuar> btw i've been thinking about dandelion recently, trying to work through anti-DoS measures for stem routing 12:57 < gmaxwell> sdaftuar: Good! This seems to be one of those things that is easy in theory (if either you ignore getting it right or ignore how hard it is to implement) but hard in practice. :) 12:57 < wumpus> would be good to reduce the DoS surface there, yes 13:00 < sipa> PLOINKIDOOF 13:00 < wumpus> #endmeeting 13:00 < lightningbot> Meeting ended Thu Aug 16 20:00:03 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-16-19.03.html 13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-16-19.03.txt 13:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-16-19.03.log.html 13:01 < sdaftuar> ploinkidoof? 13:07 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 13:09 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 13:12 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 13:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 13:12 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 13:13 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [] 13:13 < jonasschnelli> rekeying and message queues is a nightmare 13:16 < sipa> it would be much easier if it wrre deterministic rather than negotiated 13:17 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 256 seconds] 13:18 < jonasschnelli> sipa: not sure. Since you need to decrypt the length in chacha20poly1305@openssh 13:19 < jonasschnelli> Or maybe whenever a message exceeds the limit, the following one will be encrypted with the new key 13:19 < jonasschnelli> but the time limit could be tricky,... the byte limit probably not 13:22 < gmaxwell> wait why is rekeying and message queues a nightmare. 13:23 < sipa> gmaxwell: because parsing protocol messages happens before processing them 13:23 < jonasschnelli> gmaxwell: because decomposing and queuing (where you decrypt) is done before processing 13:23 < sipa> a rekey means you need to undo the parsing for unprocessed things 13:23 < gmaxwell> the rekeying should be handled at the decryption layer, when you decrypt and find a rekey message then the very next bytes out you decrypt with the new stuff. 13:24 < jonasschnelli> I currently try to approach where I pause the read channel when I'm detecting a rekey during parsing 13:25 < sipa> i guess it would be easier if rekeying was done at a meta layer 13:25 < sipa> say a flag bit in the encrypted packet 13:25 < sipa> rather than an actual protocol message 13:25 < gmaxwell> Is the e.g. an out of range length. 13:26 < jonasschnelli> Rekeying when the decrypted length is oor seems fragile though,... 13:26 < jonasschnelli> I kinda like gmaxwell approach of putting the rekeyin logic in the decryption handler 13:26 < gmaxwell> Why? 13:26 < jonasschnelli> gmaxwell: isn't it technically possible that you get a valid length ( so? if your stream is corrupted you'll dsync, fail auth, and disconnect. 13:28 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 13:28 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:98e6:a9c0:ee38:c1b3] has quit [Ping timeout: 260 seconds] 13:28 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 13:29 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 13:30 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 13:30 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:98e6:a9c0:ee38:c1b3] has joined #bitcoin-core-dev 13:30 -!- prod_ [~prod@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 13:30 < jonasschnelli> gmaxwell: is the probability very of an valid length with an unexpected key that low that a reconnect would be an acceptable workaround? 13:30 < jonasschnelli> *very low 13:31 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 13:31 < gmaxwell> I think we're probably talking past each other. 13:31 < jonasschnelli> heh... 13:31 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 13:31 < gmaxwell> what I'm trying to suggest is that to signal rekeying, under the old key, you send a specific length value which we would otherwise never use (due to it being out of range) 13:32 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 13:32 < jonasschnelli> Assume when I rekey in case of decrypting to an invalid length... i guess there is a probability that the decrypted length with the now invalid key is within the MAX_SIZE boundary.... right? 13:32 < gmaxwell> No. 13:32 < jonasschnelli> aha! I see 13:33 < jonasschnelli> Wait.. 13:33 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 13:33 < gmaxwell> You don't decrypt the same data again. You see an invalid length, you rekey and throw out that length and continue. 13:34 < jonasschnelli> So... peer A asking for a rekey by setting an invalid length encrypted under the old key, then next message will use the new key?` 13:34 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 13:34 < gmaxwell> Yes. 13:34 < jonasschnelli> So the message with the invalid length is a dummy, right? 13:34 < gmaxwell> yes. 13:34 < gmaxwell> I dunno if thats easier than just handling the rekey message at the decryption layer. 13:34 < jonasschnelli> Could the dummy message be a rekey message. :) 13:35 < gmaxwell> I was just presenting it as an alternative. :) 13:35 < gmaxwell> sure. But it could also, for example be an empty message (length 0) which maybe is easier structurally to handle. 13:35 < jonasschnelli> Yes. I like the invalid length approach since it doesn't require the parsing message logic 13:36 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Client Quit] 13:36 < jonasschnelli> Length 0 would be an option and would not be confused with a real invalid decryption 13:36 < jonasschnelli> But length 0 would also be prone to DPI I guess 13:36 < jonasschnelli> Since it would be the smalles package always 13:36 < jonasschnelli> (could artificial blow up though) 13:37 < sipa> sdaftuar: my one line summary: we have a way to compute a 'sketch' from a set of N bit elements, with a size of M*N (so equal in size to M elements), in such a way that you can recover the contents from a sketch as long as there aren't more than M elements in it. Now, XORing two sketches gives you a sketch of the set of elements that are in one of the two input sets (but not both) 13:37 < gmaxwell> this protocol doesn't resist traffic analysis. 13:37 < jonasschnelli> Yes... right,.. 13:38 < jonasschnelli> But with the 32byte pure pubkey handshake and the encrypted length, we are pretty stealth and make lives a bit harder for DPI configurators 13:38 < gmaxwell> jonasschnelli: I don't see how the length0 thing changes anything. 13:38 < gmaxwell> the length is still encrypted. 13:38 < jonasschnelli> I think the length 0 package could still contain a payload of the size of an inv 13:39 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 13:39 < jonasschnelli> Yes. I just though the size of that package (if someone analyses package burst) a rekey if the payload would be length 0 would be easy to identify ... but probably so other commands. 13:40 < jonasschnelli> *with 13:40 < jonasschnelli> But I guess my point is weak... length 0 seems to be the most advance idea how to tigger a rekey on the encryption layer 13:40 < gmaxwell> Sending a minimum length (just len and auth tag) message is no more or less identifable than any other size. If socket handling merges multiple messages, they're not identifyable at all, and if socket handling splits every message, the lengths are implicitly visible. 13:41 < gmaxwell> the only downside I see to length 0 is that we might otherwise want to use them for keepalives. :) 13:41 < gmaxwell> (which you might want to send more often than once per ten minutes) 13:41 < gmaxwell> but I guess we ping at the protocol level, so nevermind. :P 13:42 < jonasschnelli> We could also use MAX_INT32 for the rekey 13:42 < gmaxwell> I forget how the length is encoded. Is it encoded with a variable length encoding? 13:43 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 244 seconds] 13:44 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:98e6:a9c0:ee38:c1b3] has quit [Ping timeout: 260 seconds] 13:44 < gmaxwell> sipa, sdaftuar: An astute reader might notice that a set of M N bit elements can be communicated in log2(2^N choose M) bits. so this scheme is not quite perfectly efficient, but it's close. 13:45 < jonasschnelli> gmaxwell: length is a fix 4 byte uint32 13:45 < jonasschnelli> encrypted with a key only used for chacha20-crypt the length 13:46 < gmaxwell> jonasschnelli: oh, okay, for some reason I thought we had something with lower overhead there. I guess it doesn't matter much since most of our messages are fairly long. 13:47 < gmaxwell> jonasschnelli: indeed MAX_UINT32 could just be a length 0 message that triggers rekey. 13:47 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:98e6:a9c0:ee38:c1b3] has joined #bitcoin-core-dev 13:47 < sdaftuar> sipa gmaxwell: what's the failure mode/fallback scenario if a sketch can't be reconciled? 13:47 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 13:48 < gmaxwell> sdaftuar: Sketch data can be incrementally sent. so if M wasn't enough I can just send you one more value and now you have M+1. 13:48 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 13:48 < sdaftuar> oh neat 13:49 < sipa> it can even be incrementally computed 13:49 < sdaftuar> does that require saving the old sketch? 13:49 < sdaftuar> oh 13:49 < sipa> (but computing a sketch is very cheap, recovering data form one is expensive) 13:49 < jonasschnelli> gmaxwell: ideally, there would be a way to flag the rekey in a non-extra message,.. so flag in the first message using the new key 13:49 < gmaxwell> In practice we'll have a limit on the maximum M, both for memory reasons storing the sketches and computation (decode is quadratic). ... so if we exceeded that, you'd just fail to relay those transactions since the last reconcile with that peer, better luck next time around. 13:49 < jonasschnelli> (to avoid accessing the push message logic from with the encryption logic) 13:50 < gmaxwell> sdaftuar: The sketch decode has two steps, the first step is perfectly incremental. So we waste no cpu getting the sketch data a little at a time. The second step is not incremental, though we can arrange things so that we can be pretty sure if it'll be successful or not before starting it. 13:51 < gmaxwell> jonasschnelli: well just steal the most significant bit of the length. 13:51 < gmaxwell> 2^31 byte messages should be enough for anyone. 13:52 < jonasschnelli> But megablocks! 13:52 < jonasschnelli> Yes. Great idea 13:52 < gmaxwell> 2^31 is still 2GB. :P 13:52 * jonasschnelli got called to bed 13:53 < gmaxwell> night 13:56 < gmaxwell> sdaftuar: the actual construction of this system is a binary BCH code, with a message 2^n bits long which has up to M 'errors' (the set difference) in it that we need to correct. So obviously, we should call it something like BCH faulting transaction relay. :P 13:58 < sdaftuar> just bch relay sounds nice and concise 13:59 * warren blinked hard upon reading BCH 14:00 < sdaftuar> anyway that sounds awesome, i assume it's close enough that we can hope to have it for 0.18? 14:01 < gmaxwell> I don't see why it couldn't be done in a couple months, assuming that as we implement we don't get stuck on stupid protocol issues. 14:02 < gmaxwell> or fall too far down the number theory rathole of microoptimizing the set reconcillation. 14:02 < sdaftuar> :) 14:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 14:02 < sipa> sdaftuar: the algorithm is based on a project called 'pinsketch', which relies on a library called NTL, which is LGPL and a lot of code 14:03 < gmaxwell> it's really quite a lovely problem to work on. :) 14:03 < sipa> sdaftuar: so we reimplemented inlt from scratch in a few hundred lines, and it's faster too :) 14:03 < sdaftuar> yeah i look forward to being nerdsniped when you share your results 14:03 < sdaftuar> sipa: lol 14:03 < gmaxwell> and came up with a bunch of moderately smart optimizations... 14:04 < sdaftuar> i was about to groan about dealing with a 3rd party library and lgpl, i should have known better than to think you'd let that be a problem :) 14:05 < gmaxwell> sdaftuar: that was what held me off from doing more of this a year ago. 14:13 -!- thebiglq12345 [~thebiglq1@pool-108-6-186-213.nycmny.fios.verizon.net] has quit [Read error: Connection reset by peer] 14:21 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [] 14:23 < sipa> sdaftuar: curiously, the author of pinsketch is someone i've met at real world crypto; he did a talk on UTXO commitment data structures 14:46 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Quit: Leaving.] 14:59 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 15:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 15:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 15:08 -!- jhfrontz [~Adium@ip-107-50-240-106.akrnoh.spcsdns.net] has joined #bitcoin-core-dev 15:20 -!- jhfrontz [~Adium@ip-107-50-240-106.akrnoh.spcsdns.net] has quit [Ping timeout: 244 seconds] 15:27 -!- jhfrontz [~Adium@ip-184-195-173-14.akrnoh.spcsdns.net] has joined #bitcoin-core-dev 15:32 -!- jhfrontz [~Adium@ip-184-195-173-14.akrnoh.spcsdns.net] has quit [Quit: Leaving.] 15:32 -!- jhfrontz [~Adium@ip-184-195-173-14.akrnoh.spcsdns.net] has joined #bitcoin-core-dev 15:38 -!- jhfrontz [~Adium@ip-184-195-173-14.akrnoh.spcsdns.net] has quit [Quit: Leaving.] 15:38 -!- jhfrontz [~Adium@ip-184-195-173-14.akrnoh.spcsdns.net] has joined #bitcoin-core-dev 15:46 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has quit [Remote host closed the connection] 15:48 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 240 seconds] 15:58 -!- jhfrontz [~Adium@ip-184-195-173-14.akrnoh.spcsdns.net] has quit [Ping timeout: 260 seconds] 16:04 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 16:05 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 16:07 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 240 seconds] 16:07 < luke-jr> achow101: MarcoFalke: that VMBuilder fork doesn't actually work :< 16:07 < luke-jr> at least not for bionic 16:08 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 255 seconds] 16:08 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 16:09 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev 16:09 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Remote host closed the connection] 16:13 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 16:20 -!- kevink [5ad952b6@gateway/web/freenode/ip.90.217.82.182] has joined #bitcoin-core-dev 16:24 < kevink> I'm using Bitcoin Core's API and am wondering whats the difference between `duplicate-inconclusive` and `duplicate` when calling `submitblock`. I'm just trying to verify that a block exists in the blockchain and `submitblock` seems like the simplest way to do that. 16:26 -!- promag [~promag@83.223.235.97] has joined #bitcoin-core-dev 16:27 < sipa> kevink: try getblockheader instead 16:29 < phantomcircuit> kevink, submit block is definitely not the way to do that, getblockheader is 16:29 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Quit: Leaving] 16:31 -!- promag [~promag@83.223.235.97] has quit [Ping timeout: 244 seconds] 16:36 < kevink> The reason I wanted to use submitblock was because I'm encoding and decoding the blockdata into an image using https://gist.github.com/laanwj/51f276c44ba9882bb4b27cc6f3a499a4 and wanted to check that it also remained a valid block after being decoded. 16:44 < sipa> compute its hash, and query for it 16:48 < gmaxwell> I guess we don't have a decoderawblock rpc that would construct the hash for you! 16:49 -!- viaj3ro [AdiIRC@31.16.118.221] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 16:54 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 17:01 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...] 17:05 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:98e6:a9c0:ee38:c1b3] has quit [Ping timeout: 255 seconds] 17:11 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 17:14 -!- kevink [5ad952b6@gateway/web/freenode/ip.90.217.82.182] has quit [Quit: Page closed] 17:35 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 17:35 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:58db:29ce:c623:4b7a] has joined #bitcoin-core-dev 17:36 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 17:36 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 17:39 < michagogo> Hrm 17:39 < michagogo> I got a new computer 17:40 < michagogo> But all my VMs, including the Ubuntu I use for gitian, are in virtualbox 17:40 < michagogo> And it seems that Windows 10 actually runs in a Hyper-V VM, which hogs the vtx… 17:41 < michagogo> Not to mention that if I want Docker that’s Hyper-V too 17:42 < michagogo> So I guess I need to figure out how to migrate, but I feel like that’ll be a pain 17:42 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 17:42 < michagogo> Especially because the Hyper-V console sucks 17:43 < michagogo> To the point that for Windows VMs, they tell you you’re better off RDPing in 17:45 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 260 seconds] 17:46 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer] 17:46 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 17:48 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer] 17:48 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 17:48 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 240 seconds] 17:49 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 17:53 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has joined #bitcoin-core-dev 18:05 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.] 18:05 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 18:26 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 18:29 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 2.0] 18:29 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 18:35 < achow101> luke-jr: really? It worked for me 18:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 18:39 < luke-jr> achow101: it's trying to install grub, and there's no package or something 18:39 < luke-jr> 2018-08-16 23:26:15,629 INFO : E: Package 'grub' has no installation candidate 18:41 < achow101> luke-jr: are you sure you are using the correct vmbuilder? 18:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 18:46 < luke-jr> achow101: no, but I tried both master and bionic branches.. 18:55 -!- ken2812221 [~ken281222@180.217.169.165] has joined #bitcoin-core-dev 19:10 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev 19:13 -!- rls [~rls@69.197.143.181] has quit [Read error: Connection reset by peer] 19:14 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:58db:29ce:c623:4b7a] has quit [Ping timeout: 260 seconds] 19:23 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 19:28 -!- thib [~thib@wikimedia/Thibaut120094] has joined #bitcoin-core-dev 19:36 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has quit [Ping timeout: 252 seconds] 19:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 19:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 19:47 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 19:47 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:4528:5ba8:618d:cf54] has joined #bitcoin-core-dev 19:50 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 255 seconds] 19:55 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 20:07 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 20:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 20:38 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:4528:5ba8:618d:cf54] has quit [Remote host closed the connection] 21:34 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 21:35 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 21:37 -!- unholymachine [~quassel@2601:8c:c003:9f16:5944:3771:8b45:9046] has quit [Read error: Connection reset by peer] 21:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 21:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 22:28 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 22:28 < fanquake> MarcoFalke Any idea why your sigs don't match the others that have been submitted? 22:35 < luke-jr> achow101: I don't see how the code in that branch can possibly work. It hard-codes "grub" 22:52 < achow101> luke-jr: I'm not sure 22:52 < achow101> fanquake: I'm getting the same sigs as MarcoFalke 22:53 < achow101> fanquake: I used docker to build, maybe that's causing the difference? 22:54 < fanquake> achow101 hmm ok. So wumpus, ken, jonass and myself match, yourself and marco match differently. 22:54 < fanquake> achow101: that could be it. I'll do a docker build and see if there's a difference. 23:02 -!- rex4539 [~rex4539@2a02:587:3516:600:501e:2e3c:67e:5260] has quit [Quit: Textual IRC Client: www.textualapp.com] 23:12 -!- rex4539 [~rex4539@2a02:587:3516:600:84d8:144d:6ace:febc] has joined #bitcoin-core-dev 23:27 -!- Krellan [~Krellan@2601:640:4000:9258:8d13:3cc8:d32c:a57c] has joined #bitcoin-core-dev 23:33 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.] 23:46 < ken2812221> The difference is linux only. 23:49 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] --- Log closed Fri Aug 17 00:00:43 2018