--- Day changed Mon Jan 30 2017 00:14 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 00:16 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/0fea960ca917...720b57948034 00:16 < bitcoin-git> bitcoin/master 342eb96 Cory Fields: build: find qt's renamed helper libs from 5.7 00:16 < bitcoin-git> bitcoin/master 8efa34f Cory Fields: depends: add a zlib build... 00:16 < bitcoin-git> bitcoin/master b5f374f Cory Fields: qt: fix build with zlib for target... 00:16 < bitcoin-git> [bitcoin] laanwj closed pull request #9646: depends: Fix cross build for qt5.7 (master...fix-qt57) https://github.com/bitcoin/bitcoin/pull/9646 00:18 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 00:18 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:23 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds] 00:38 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:49 < gmaxwell> What does -daemon do on windows? 00:49 < wumpus> give you an eror and quit 00:50 < wumpus> (at least in master) 00:50 < gmaxwell> Thanks. 00:50 < wumpus> in older versions it's just ignored 00:50 < gmaxwell> For some reason I thought it worked there. 00:51 < gmaxwell> yea, someone in #bitcoin reported it was ignored. 00:51 < wumpus> it's just not how background services work in windows 00:52 < wumpus> they are started from a special service manager, and need bookkeeping in the registry and such. No one ever bothered with that :) 01:13 < wumpus> I wouldn't be opposed to someone implementing that of course. It would need changes to the installer as well as the application itself. 01:22 -!- harrymm [~wayne@104.207.83.18] has quit [Ping timeout: 245 seconds] 01:33 -!- Soligor_ [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 255 seconds] 01:34 -!- aguycalled [~aguycalle@2a02:2450:102d:b5:4547:3b33:3019:3062] has quit [Remote host closed the connection] 01:39 < bitcoin-git> [bitcoin] laanwj pushed 9 new commits to master: https://github.com/bitcoin/bitcoin/compare/720b57948034...d2c9e4d42291 01:39 < bitcoin-git> bitcoin/master 5b15870 Alex Morcos: Use incrementalRelayFee for BIP 125 replacement 01:39 < bitcoin-git> bitcoin/master de6400d Alex Morcos: Fix missing use of dustRelayFee 01:39 < bitcoin-git> bitcoin/master 6b331e6 Alex Morcos: Fix to have miner test aware of new separate block min tx fee 01:39 < bitcoin-git> [bitcoin] laanwj closed pull request #9615: Wallet incremental fee (master...walletincremental) https://github.com/bitcoin/bitcoin/pull/9615 01:45 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:46 -!- harrymm [~wayne@104.207.83.17] has joined #bitcoin-core-dev 01:49 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 240 seconds] 01:49 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 01:50 -!- harrymm [~wayne@104.207.83.17] has quit [Ping timeout: 240 seconds] 01:55 -!- harrymm [~wayne@104.207.83.17] has joined #bitcoin-core-dev 01:57 -!- AaronvanW [~AaronvanW@207pc74.sshunet.nl] has joined #bitcoin-core-dev 01:57 -!- AaronvanW [~AaronvanW@207pc74.sshunet.nl] has quit [Changing host] 01:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:27 -!- harrymm [~wayne@104.207.83.17] has quit [Ping timeout: 240 seconds] 02:41 -!- harrymm [~wayne@191.96.49.22] has joined #bitcoin-core-dev 02:48 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev 03:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 03:03 -!- wvr [~wvr@8.red-88-8-194.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 03:17 -!- harrymm [~wayne@191.96.49.22] has quit [Ping timeout: 256 seconds] 03:22 -!- harrymm [~wayne@191.96.49.22] has joined #bitcoin-core-dev 03:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:49 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/d2c9e4d42291...36966a1c0e64 03:49 < bitcoin-git> bitcoin/master 5be0190 Matt Corallo: Delete some unused (and broken) functions in CConnman 03:49 < bitcoin-git> bitcoin/master 3c37dc4 Matt Corallo: Ensure cs_vNodes is held when using the return value from FindNode 03:49 < bitcoin-git> bitcoin/master 2366180 Matt Corallo: Do not add to vNodes until fOneShot/fFeeler/fAddNode have been set 03:49 < bitcoin-git> [bitcoin] laanwj closed pull request #9626: Clean up a few CConnman cs_vNodes/CNode things (master...2017-01-remove-broken-unused-funcs) https://github.com/bitcoin/bitcoin/pull/9626 03:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 04:13 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/36966a1c0e64...668de70be039 04:13 < bitcoin-git> bitcoin/master b7b48c8 Karl-Johan Alm: Refactor: Remove using namespace from src/*.cpp. 04:13 < bitcoin-git> bitcoin/master 668de70 MarcoFalke: Merge #9644: [refactor] Remove using namespace from src/... 04:14 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9644: [refactor] Remove using namespace from src/ (master...no-using-namespace-src) https://github.com/bitcoin/bitcoin/pull/9644 04:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:36 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/71fc17f6673eae2e44d226e21692283a85786c44 04:36 < bitcoin-git> bitcoin/master 71fc17f Wladimir J. van der Laan: qt: periodic translations update 04:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 04:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:50 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/71fc17f6673e...53ab12d9318d 04:50 < bitcoin-git> bitcoin/master fa5137c MarcoFalke: [doc] Remove unused clang format dev script... 04:50 < bitcoin-git> bitcoin/master 53ab12d MarcoFalke: Merge #9649: [doc] Remove unused clang format dev script... 04:50 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9649: [doc] Remove unused clang format dev script (master...Mf1701-clangFormat) https://github.com/bitcoin/bitcoin/pull/9649 04:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 04:51 < MarcoFalke> wumpus: Could make sense to transfer the maintainer tools repo to /bitcoin-core some day? 04:51 < wumpus> yes, it should 04:53 < wumpus> "Moving repository to bitcoin-core/bitcoin-maintainer-tools. This may take a few minutes." 04:53 < MarcoFalke> nice. Lets see if my pull stays open 04:56 < MarcoFalke> Looks all fine. 04:56 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/53ab12d9318d...e99f0d7ad443 04:56 < bitcoin-git> bitcoin/master 95f97f4 Luke Dashjr: Skip RAII event tests if libevent is built without event_set_mem_functions 04:56 < bitcoin-git> bitcoin/master e99f0d7 Wladimir J. van der Laan: Merge #9647: Skip RAII event tests if libevent is built without event_set_mem_functions... 04:57 < bitcoin-git> [bitcoin] laanwj closed pull request #9647: Skip RAII event tests if libevent is built without event_set_mem_functions (master...raii_tests_optional) https://github.com/bitcoin/bitcoin/pull/9647 05:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 05:47 -!- Netsplit *.net <-> *.split quits: LeMiner 05:48 -!- Netsplit over, joins: LeMiner 05:56 < achow101> what does safe mode do? 05:56 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 05:57 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 06:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:09 -!- aguycalled [~aguycalle@2a02:2450:102d:b5:bcd0:84fd:6347:f6fe] has joined #bitcoin-core-dev 06:12 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 06:14 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has quit [Ping timeout: 260 seconds] 06:15 < wumpus> achow101: it disables a few wallet commands concerned with sending funds IIRC 06:15 < wumpus> (anything with okSafe==false in the dispatch table) 06:16 < achow101> what causes safe mode? 06:18 -!- p4r4ms4m [~Fuchus@88.128.80.239] has joined #bitcoin-core-dev 06:21 < wumpus> fLargeWorkForkFound or fLargeWorkInvalidChainFound 06:22 < wumpus> more generally, when the client detects something fishy either with itself or the network 06:23 < achow101> if a large work fork is found (>6 blocks deep) and has more work than the current tip, will it switch to that fork and warn the user? 06:24 < wumpus> yes, safemode is a result of warnings 06:25 < wumpus> IIRC it will follow a large work fork (given that it validates correctly, of course) but warn and go to safe mode 06:25 < achow101> ok. 06:25 < wumpus> but I don't know the exact logic deeply you'll have to check the source code 06:25 < achow101> safe mode seems kinda useless, I can't find anything about it that would affect what most users do with the GUI 06:26 < wumpus> it doesn't affect the GUI, from what I remember that's on purpose: GUI is used manually so if there is a big warning visible and the user still wants to send, they can 06:26 < wumpus> RPC is usually driven automatically so the only way to make the operator realize something is wrong is by blocking commands 06:27 < achow101> ah. I see. that makes sense 06:27 < achow101> thanks 06:28 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 258 seconds] 06:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 06:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 07:03 -!- droark [~droark@50-242-99-126-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 07:08 -!- droark [~droark@50-242-99-126-static.hfc.comcastbusiness.net] has quit [Ping timeout: 264 seconds] 07:11 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 07:19 -!- p4r4ms4m [~Fuchus@88.128.80.239] has quit [Ping timeout: 240 seconds] 07:29 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 07:44 < sipa> jl2012: the serialization code depends on char being 1 byte, short being 2, int being 4, and long being 8 07:45 < jl2012> sipa: isn't this dependent on the architecture? 07:45 -!- gielbier [~michiel@unaffiliated/gielbier] has joined #bitcoin-core-dev 07:45 < sipa> jl2012: while technically those are dependent on architecture, everything we remotely support has rhese sizes 07:46 < sipa> wait, i believe long does differ 07:46 < jl2012> so is it ok if I use GetSizeOfCompactSize in consensus code? 07:46 < sipa> but long long does not 07:46 < jl2012> or is it already kind of consensus critical? 07:47 < sipa> you already are using it in consensus code. it affects block size calculation 07:47 < sipa> as that uses GetSerializeSize 07:48 < jl2012> isn't it better to directly use numeric number, instead of sizeof(something) ? 07:48 < sipa> yes and no 07:49 < sipa> we're using char/short/int/long long in serialization code anyway, though we've slowly moving away from those in favor of int16 int32_t, int64_t etc 07:50 < sipa> so switching the size calculation on itself would be perhaps more future proof for that function itself 07:50 < sipa> we sjould really get rid of the use of those data type in serialization code (and probably all of consensus code) in the first place 07:51 -!- p4r4ms4m [~Fu@aftr-37-201-243-30.unity-media.net] has joined #bitcoin-core-dev 07:51 < jl2012> but there is already a theoretical risks of consensus failure between architectures? 07:58 < sipa> our unit tests would immediately fail when compiling in an environment where these sizes don't hol 07:58 < jl2012> that's true 07:59 < jl2012> but you know, not everyone test their codes before shipping 07:59 < sipa> if not for that, sure... see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html 07:59 < sipa> with static_assert would make the compiler fail if compiled on an invalid architecture 08:01 < jl2012> we have no consensus code dependent on OpenSSL now, right? 08:02 < sipa> indeed, not since bip66 08:02 < sipa> http://stackoverflow.com/a/384672 08:03 < jl2012> by the way, are we going to fix the LOW_S special case I found earlier? Or just use the NULLFAIL rule (sig must be empty if failed) to cover that? 08:05 < sipa> hmm what special case? 08:06 < jl2012> if R is out of range, HIGH_S is allowed 08:06 < sipa> ah, yes 08:06 < sipa> i think we should just propose nullfail as a consensus rule 08:07 -!- harrymm [~wayne@191.96.49.22] has quit [Ping timeout: 256 seconds] 08:08 < jl2012> the 2 rules combined should cover all edge cases, I guess 08:09 < sipa> which 2 rules? 08:09 < jl2012> lows and nullfail 08:10 < sipa> yes, i believe so 08:10 < jl2012> just wonder if nullfail might irrevocably invalidate some scripts 08:10 < sipa> nullfail in particular simplifies things a lot... as it removes the distinction between valid encoding and valid signature 08:17 < jl2012> and it eliminate unneeded validation 08:17 < sipa> indeed, and storage 08:18 < jl2012> is there anyway to do aggregated validation in ECDSA? 08:21 < sipa> yes, but it requires passing along the oddness of the R point's y coordinate 08:21 < sipa> if you don't have that, there is an expoenntial blowup in combinations to test that is never worth it 08:22 < jl2012> so we currently can't do that? 08:22 < sipa> not with the current signature scheme, no 08:22 < jl2012> it just requires one more bit to encode that? 08:23 -!- harrymm [~wayne@104.207.83.19] has joined #bitcoin-core-dev 08:25 < sipa> yes 08:25 < sipa> but switching to schnorr is easier :) 08:27 < jl2012> actually, my original question is about cross-transaction aggregated validation. For example, validate all transactions in a block in one operation 08:28 < jl2012> and just aggregated validation, not aggregated signature (no space saving) 08:29 < sipa> yeah, with the extra bit you can do batch validation 08:30 < jl2012> it could be nicely fit in a 64 bytes (512 bits) signature: R = 256 bits, R oddness = 1 bit, LOW_S = 255 bits 08:30 < jl2012> how about Schnorr, would that require the extra bit? 08:35 < sipa> the Schnorr scheme i proposed before avoids it by requiring that bit to be 0 08:35 < sipa> implicitly 08:35 < sipa> which would equally be possible in ECDSA, but again, requires a change 08:36 < jl2012> so you just assume the bit is 0. If a signature has a non-0 bit, the wallet will find a different nonce to sign again? 08:37 < sipa> all that requires is negating the nonce :) 08:38 < jl2012> sounds like possible with a softfork? 08:38 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 08:46 < sipa> and changing all wallet software 08:52 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer] 08:53 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:01 -!- harrymm [~wayne@104.207.83.19] has quit [Ping timeout: 255 seconds] 09:05 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev 09:11 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 09:19 -!- RoyceX [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 09:20 -!- Kexkey [~kexkey@23.105.149.2] has joined #bitcoin-core-dev 09:22 -!- cheese_ [~x@unaffiliated/cheeseo] has quit [Ping timeout: 252 seconds] 09:24 -!- aguycalled [~aguycalle@2a02:2450:102d:b5:bcd0:84fd:6347:f6fe] has quit [Read error: Connection reset by peer] 09:24 -!- aguycalled [~aguycalle@37.120.75.4] has joined #bitcoin-core-dev 09:25 -!- Kexkey [~kexkey@23.105.149.2] has quit [Ping timeout: 240 seconds] 09:40 < jl2012> same as low_s 09:44 -!- stevenroose [~steven@vps.weuste.club] has joined #bitcoin-core-dev 09:47 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 09:47 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 09:47 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 09:50 < sipa> well as long as OP_CHECKSIG NOT is allowed, we can't do batch verification anyway 09:50 -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 09:51 -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has quit [Client Quit] 09:51 < sipa> though i guess it could apply to OP_CHECKSIGVERIFY only 09:52 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 240 seconds] 09:57 -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 09:57 < jl2012> NULLFAIL will do it 10:01 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 10:01 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 10:05 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 10:06 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds] 10:26 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Quit: bye] 10:27 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 10:30 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Read error: Connection reset by peer] 10:31 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 10:35 -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has quit [Quit: ZZZzzz…] 10:37 -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 10:38 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 10:40 -!- p4r4ms4m [~Fu@aftr-37-201-243-30.unity-media.net] has quit [Ping timeout: 240 seconds] 10:41 -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has quit [Client Quit] 10:41 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 10:48 -!- mariorz [sid490@gateway/web/irccloud.com/x-fxhbilsncdnmtabn] has joined #bitcoin-core-dev 11:03 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 11:04 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 11:16 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 11:16 -!- echonaut3 [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 11:24 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 11:29 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 12:28 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds] 12:57 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 13:13 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 13:27 -!- Jouke [~jouke@a83-163-42-163.adsl.xs4all.nl] has quit [Ping timeout: 240 seconds] 13:32 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 13:35 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 13:57 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 14:00 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has left #bitcoin-core-dev ["Closing Window"] 14:01 < jtimon> re https://github.com/bitcoin-core/gitian.sigs/pull/469 I assume it's not important now, but I wanted to confirm if I'm doing this properly, do I need to add my key to https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-keys first? 14:01 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer] 14:08 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 255 seconds] 14:11 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 14:19 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 255 seconds] 14:24 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 14:25 -!- aguycalled [~aguycalle@37.120.75.4] has quit [Read error: Connection reset by peer] 14:30 -!- aguycalled [~aguycalle@37.120.75.4] has joined #bitcoin-core-dev 14:41 < achow101> jtimon: looks right. you should add your key to the gitian-keys. also, you should do the code-signed binaries too, and if possible, mac 14:43 < jtimon> achow101: thanks, yeah, was leaving that for later, but I should do those too 14:47 -!- aguycalled [~aguycalle@37.120.75.4] has quit [Read error: Connection reset by peer] 14:47 -!- aguycalled [~aguycalle@2a02:2450:102d:b5:912a:61b0:31f0:8092] has joined #bitcoin-core-dev 15:15 -!- aguycalled [~aguycalle@2a02:2450:102d:b5:912a:61b0:31f0:8092] has quit [Remote host closed the connection] 15:38 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 15:48 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 15:51 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 15:59 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev 16:21 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 16:31 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-ynrpbxyxmwbpsjke] has quit [Read error: Connection reset by peer] 16:32 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-gosisbbvxbxovtuf] has joined #bitcoin-core-dev 16:40 < bitcoin-git> [bitcoin] jtimon opened pull request #9654: Add jtimon pgp keys for commit sigs and future gitian builds (master...jtimon-key-gpg) https://github.com/bitcoin/bitcoin/pull/9654 16:47 -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 16:57 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:37 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-gdrxecfhstpkvnpo] has quit [Quit: Connection closed for inactivity] 18:05 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 18:08 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds] 18:54 -!- dermoth_ [~thomas@dial-216-221-47-10.mtl.aei.ca] has joined #bitcoin-core-dev 18:55 -!- dermoth [~thomas@dsl-199-102-159-125.mtl.aei.ca] has quit [Disconnected by services] 18:55 -!- dermoth_ is now known as dermoth 19:17 -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has quit [Quit: ZZZzzz…] 19:42 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke] 20:46 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 20:50 -!- waxwing [~waxwing@58.137.128.131] has quit [Quit: Leaving] 20:55 -!- chris2000 [~chris2000@p5DCB5598.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 20:58 -!- chris200_ [~chris2000@p5082A407.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 21:35 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 21:45 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 21:48 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 21:55 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 22:03 -!- guest23190302109 [18aafbf0@gateway/web/freenode/ip.24.170.251.240] has joined #bitcoin-core-dev 22:04 -!- guest23190302109 [18aafbf0@gateway/web/freenode/ip.24.170.251.240] has left #bitcoin-core-dev [] 22:15 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-konkfvkpvxooncxq] has joined #bitcoin-core-dev 22:33 < luke-jr> what would others think of a feature where you can sign a message using the UTXO set to show you probably run a full node? 22:46 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds] 22:56 < jl2012> you could outsource this, I suppose 22:57 -!- jouke [~jouke@unaffiliated/komkommer] has joined #bitcoin-core-dev 23:00 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 23:12 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 23:13 < sipa> if you do it as a challenge-response, and require a response within not-much-more-than-ping-time, you'd at least prove you're close to a full node 23:15 < luke-jr> jl2012: yes, it won't be 100% reliable, but it might be handy 23:16 < luke-jr> sipa: that sounds much more complicated (can't really integrate with a browser) :/ 23:16 < luke-jr> it would also exclude those who have remote full nodes under their own control 23:17 < luke-jr> depending on implementation I guess 23:17 < luke-jr> I suppose the node can contact the webpage directly, but that seems like not the best idea for security 23:21 < sipa> webpage? 23:22 < sipa> maybe you have a very different use case in mind than me 23:31 -!- cjamthagen [~user@h-88-153.a230.priv.bahnhof.se] has quit [Quit: WeeChat 1.0.1] 23:45 -!- cjamthagen [~user@h-88-153.a230.priv.bahnhof.se] has joined #bitcoin-core-dev