1 2017-01-30 02:46:35 0|bitcoin-git|[13bitcoin] 15luke-jr closed pull request #9642: [Hardfork] Safe block size limit (06master...06bip-blksize) 02 https://github.com/bitcoin/bitcoin/pull/9642
2 2017-01-30 08:16:10 0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/0fea960ca917...720b57948034
3 2017-01-30 08:16:11 0|bitcoin-git|13bitcoin/06master 14342eb96 15Cory Fields: build: find qt's renamed helper libs from 5.7
4 2017-01-30 08:16:11 0|bitcoin-git|13bitcoin/06master 148efa34f 15Cory Fields: depends: add a zlib build...
5 2017-01-30 08:16:12 0|bitcoin-git|13bitcoin/06master 14b5f374f 15Cory Fields: qt: fix build with zlib for target...
6 2017-01-30 08:16:28 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9646: depends: Fix cross build for qt5.7 (06master...06fix-qt57) 02 https://github.com/bitcoin/bitcoin/pull/9646
7 2017-01-30 08:49:41 0|gmaxwell|What does -daemon do on windows?
8 2017-01-30 08:49:53 0|wumpus|give you an eror and quit
9 2017-01-30 08:50:06 0|wumpus|(at least in master)
10 2017-01-30 08:50:40 0|gmaxwell|Thanks.
11 2017-01-30 08:50:54 0|gmaxwell|For some reason I thought it worked there.
12 2017-01-30 08:50:54 0|wumpus|in older versions it's just ignored
13 2017-01-30 08:51:02 0|gmaxwell|yea, someone in #bitcoin reported it was ignored.
14 2017-01-30 08:51:44 0|wumpus|it's just not how background services work in windows
15 2017-01-30 08:52:17 0|wumpus|they are started from a special service manager, and need bookkeeping in the registry and such. No one ever bothered with that :)
16 2017-01-30 09:13:49 0|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.
17 2017-01-30 09:39:22 0|bitcoin-git|[13bitcoin] 15laanwj pushed 9 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/720b57948034...d2c9e4d42291
18 2017-01-30 09:39:23 0|bitcoin-git|13bitcoin/06master 145b15870 15Alex Morcos: Use incrementalRelayFee for BIP 125 replacement
19 2017-01-30 09:39:23 0|bitcoin-git|13bitcoin/06master 14de6400d 15Alex Morcos: Fix missing use of dustRelayFee
20 2017-01-30 09:39:24 0|bitcoin-git|13bitcoin/06master 146b331e6 15Alex Morcos: Fix to have miner test aware of new separate block min tx fee
21 2017-01-30 09:39:37 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9615: Wallet incremental fee (06master...06walletincremental) 02 https://github.com/bitcoin/bitcoin/pull/9615
22 2017-01-30 11:49:12 0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/d2c9e4d42291...36966a1c0e64
23 2017-01-30 11:49:13 0|bitcoin-git|13bitcoin/06master 145be0190 15Matt Corallo: Delete some unused (and broken) functions in CConnman
24 2017-01-30 11:49:14 0|bitcoin-git|13bitcoin/06master 142366180 15Matt Corallo: Do not add to vNodes until fOneShot/fFeeler/fAddNode have been set
25 2017-01-30 11:49:14 0|bitcoin-git|13bitcoin/06master 143c37dc4 15Matt Corallo: Ensure cs_vNodes is held when using the return value from FindNode
26 2017-01-30 11:49:33 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9626: Clean up a few CConnman cs_vNodes/CNode things (06master...062017-01-remove-broken-unused-funcs) 02 https://github.com/bitcoin/bitcoin/pull/9626
27 2017-01-30 12:13:54 0|bitcoin-git|13bitcoin/06master 14b7b48c8 15Karl-Johan Alm: Refactor: Remove using namespace <xxx> from src/*.cpp.
28 2017-01-30 12:13:54 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/36966a1c0e64...668de70be039
29 2017-01-30 12:13:55 0|bitcoin-git|13bitcoin/06master 14668de70 15MarcoFalke: Merge #9644: [refactor] Remove using namespace <xxx> from src/...
30 2017-01-30 12:14:09 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9644: [refactor] Remove using namespace <xxx> from src/ (06master...06no-using-namespace-src) 02 https://github.com/bitcoin/bitcoin/pull/9644
31 2017-01-30 12:36:32 0|bitcoin-git|13bitcoin/06master 1471fc17f 15Wladimir J. van der Laan: qt: periodic translations update
32 2017-01-30 12:36:32 0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02 https://github.com/bitcoin/bitcoin/commit/71fc17f6673eae2e44d226e21692283a85786c44
33 2017-01-30 12:50:29 0|bitcoin-git|13bitcoin/06master 14fa5137c 15MarcoFalke: [doc] Remove unused clang format dev script...
34 2017-01-30 12:50:29 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/71fc17f6673e...53ab12d9318d
35 2017-01-30 12:50:30 0|bitcoin-git|13bitcoin/06master 1453ab12d 15MarcoFalke: Merge #9649: [doc] Remove unused clang format dev script...
36 2017-01-30 12:50:44 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9649: [doc] Remove unused clang format dev script (06master...06Mf1701-clangFormat) 02 https://github.com/bitcoin/bitcoin/pull/9649
37 2017-01-30 12:51:15 0|MarcoFalke|wumpus: Could make sense to transfer the maintainer tools repo to /bitcoin-core some day?
38 2017-01-30 12:51:31 0|wumpus|yes, it should
39 2017-01-30 12:53:22 0|wumpus|"Moving repository to bitcoin-core/bitcoin-maintainer-tools. This may take a few minutes."
40 2017-01-30 12:53:55 0|MarcoFalke|nice. Lets see if my pull stays open
41 2017-01-30 12:56:21 0|MarcoFalke|Looks all fine.
42 2017-01-30 12:56:49 0|bitcoin-git|13bitcoin/06master 1495f97f4 15Luke Dashjr: Skip RAII event tests if libevent is built without event_set_mem_functions
43 2017-01-30 12:56:49 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/53ab12d9318d...e99f0d7ad443
44 2017-01-30 12:56:50 0|bitcoin-git|13bitcoin/06master 14e99f0d7 15Wladimir J. van der Laan: Merge #9647: Skip RAII event tests if libevent is built without event_set_mem_functions...
45 2017-01-30 12:57:03 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9647: Skip RAII event tests if libevent is built without event_set_mem_functions (06master...06raii_tests_optional) 02 https://github.com/bitcoin/bitcoin/pull/9647
46 2017-01-30 13:56:48 0|achow101|what does safe mode do?
47 2017-01-30 14:15:03 0|wumpus|achow101: it disables a few wallet commands concerned with sending funds IIRC
48 2017-01-30 14:15:34 0|wumpus|(anything with okSafe==false in the dispatch table)
49 2017-01-30 14:16:36 0|achow101|what causes safe mode?
50 2017-01-30 14:21:47 0|wumpus|fLargeWorkForkFound or fLargeWorkInvalidChainFound
51 2017-01-30 14:22:45 0|wumpus|more generally, when the client detects something fishy either with itself or the network
52 2017-01-30 14:23:17 0|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?
53 2017-01-30 14:24:13 0|wumpus|yes, safemode is a result of warnings
54 2017-01-30 14:25:02 0|wumpus|IIRC it will follow a large work fork (given that it validates correctly, of course) but warn and go to safe mode
55 2017-01-30 14:25:13 0|achow101|ok.
56 2017-01-30 14:25:17 0|wumpus|but I don't know the exact logic deeply you'll have to check the source code
57 2017-01-30 14:25:39 0|achow101|safe mode seems kinda useless, I can't find anything about it that would affect what most users do with the GUI
58 2017-01-30 14:26:36 0|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
59 2017-01-30 14:26:51 0|wumpus|RPC is usually driven automatically so the only way to make the operator realize something is wrong is by blocking commands
60 2017-01-30 14:27:34 0|achow101|ah. I see. that makes sense
61 2017-01-30 14:27:37 0|achow101|thanks
62 2017-01-30 15:44:55 0|sipa|jl2012: the serialization code depends on char being 1 byte, short being 2, int being 4, and long being 8
63 2017-01-30 15:45:22 0|jl2012|sipa: isn't this dependent on the architecture?
64 2017-01-30 15:45:36 0|sipa|jl2012: while technically those are dependent on architecture, everything we remotely support has rhese sizes
65 2017-01-30 15:46:35 0|sipa|wait, i believe long does differ
66 2017-01-30 15:46:40 0|jl2012|so is it ok if I use GetSizeOfCompactSize in consensus code?
67 2017-01-30 15:46:40 0|sipa|but long long does not
68 2017-01-30 15:46:58 0|jl2012|or is it already kind of consensus critical?
69 2017-01-30 15:47:14 0|sipa|you already are using it in consensus code. it affects block size calculation
70 2017-01-30 15:47:22 0|sipa|as that uses GetSerializeSize
71 2017-01-30 15:48:21 0|jl2012|isn't it better to directly use numeric number, instead of sizeof(something) ?
72 2017-01-30 15:48:59 0|sipa|yes and no
73 2017-01-30 15:49:46 0|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
74 2017-01-30 15:50:17 0|sipa|so switching the size calculation on itself would be perhaps more future proof for that function itself
75 2017-01-30 15:50:47 0|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
76 2017-01-30 15:51:29 0|jl2012|but there is already a theoretical risks of consensus failure between architectures?
77 2017-01-30 15:58:27 0|sipa|our unit tests would immediately fail when compiling in an environment where these sizes don't hol
78 2017-01-30 15:58:44 0|jl2012|that's true
79 2017-01-30 15:59:08 0|jl2012|but you know, not everyone test their codes before shipping
80 2017-01-30 15:59:08 0|sipa|if not for that, sure... see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html
81 2017-01-30 15:59:44 0|sipa|with static_assert would make the compiler fail if compiled on an invalid architecture
82 2017-01-30 16:01:39 0|jl2012|we have no consensus code dependent on OpenSSL now, right?
83 2017-01-30 16:02:48 0|sipa|indeed, not since bip66
84 2017-01-30 16:03:00 0|sipa|http://stackoverflow.com/a/384672
85 2017-01-30 16:03:46 0|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?
86 2017-01-30 16:05:12 0|sipa|hmm what special case?
87 2017-01-30 16:06:13 0|jl2012|if R is out of range, HIGH_S is allowed
88 2017-01-30 16:06:19 0|sipa|ah, yes
89 2017-01-30 16:06:44 0|sipa|i think we should just propose nullfail as a consensus rule
90 2017-01-30 16:08:36 0|jl2012|the 2 rules combined should cover all edge cases, I guess
91 2017-01-30 16:09:14 0|sipa|which 2 rules?
92 2017-01-30 16:09:23 0|jl2012|lows and nullfail
93 2017-01-30 16:10:22 0|sipa|yes, i believe so
94 2017-01-30 16:10:36 0|jl2012|just wonder if nullfail might irrevocably invalidate some scripts
95 2017-01-30 16:11:00 0|sipa|nullfail in particular simplifies things a lot... as it removes the distinction between valid encoding and valid signature
96 2017-01-30 16:17:04 0|jl2012|and it eliminate unneeded validation
97 2017-01-30 16:17:24 0|sipa|indeed, and storage
98 2017-01-30 16:18:30 0|jl2012|is there anyway to do aggregated validation in ECDSA?
99 2017-01-30 16:21:38 0|sipa|yes, but it requires passing along the oddness of the R point's y coordinate
100 2017-01-30 16:21:59 0|sipa|if you don't have that, there is an expoenntial blowup in combinations to test that is never worth it
101 2017-01-30 16:22:24 0|jl2012|so we currently can't do that?
102 2017-01-30 16:22:35 0|sipa|not with the current signature scheme, no
103 2017-01-30 16:22:51 0|jl2012|it just requires one more bit to encode that?
104 2017-01-30 16:25:38 0|sipa|yes
105 2017-01-30 16:25:47 0|sipa|but switching to schnorr is easier :)
106 2017-01-30 16:27:40 0|jl2012|actually, my original question is about cross-transaction aggregated validation. For example, validate all transactions in a block in one operation
107 2017-01-30 16:28:26 0|jl2012|and just aggregated validation, not aggregated signature (no space saving)
108 2017-01-30 16:29:51 0|sipa|yeah, with the extra bit you can do batch validation
109 2017-01-30 16:30:06 0|jl2012|it could be nicely fit in a 64 bytes (512 bits) signature: R = 256 bits, R oddness = 1 bit, LOW_S = 255 bits
110 2017-01-30 16:30:52 0|jl2012|how about Schnorr, would that require the extra bit?
111 2017-01-30 16:35:15 0|sipa|the Schnorr scheme i proposed before avoids it by requiring that bit to be 0
112 2017-01-30 16:35:18 0|sipa|implicitly
113 2017-01-30 16:35:40 0|sipa|which would equally be possible in ECDSA, but again, requires a change
114 2017-01-30 16:36:47 0|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?
115 2017-01-30 16:37:40 0|sipa|all that requires is negating the nonce :)
116 2017-01-30 16:38:04 0|jl2012|sounds like possible with a softfork?
117 2017-01-30 16:46:40 0|sipa|and changing all wallet software
118 2017-01-30 17:40:37 0|jl2012|same as low_s
119 2017-01-30 17:50:01 0|sipa|well as long as OP_CHECKSIG NOT is allowed, we can't do batch verification anyway
120 2017-01-30 17:51:51 0|sipa|though i guess it could apply to OP_CHECKSIGVERIFY only
121 2017-01-30 17:57:38 0|jl2012|NULLFAIL will do it
122 2017-01-30 22:01:13 0|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?
123 2017-01-30 22:41:05 0|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
124 2017-01-30 22:43:53 0|jtimon|achow101: thanks, yeah, was leaving that for later, but I should do those too