1 2017-07-14 02:57:02	0|luke-jr|wumpus: poke, can you build v0.14.2-uasfsegwit1.0?
  2 2017-07-14 03:50:43	0|phantomcircuit|there's functional tests that seem to randomly fail
  3 2017-07-14 03:51:35	0|kanzure|is there a trick to getting the test framework to let node[3].generate(10) actually cause additions to listunspent output
  4 2017-07-14 03:52:46	0|sipa|kanzure: maturity is a bitch
  5 2017-07-14 03:52:54	0|sipa|you need mine 100 more blocks first
  6 2017-07-14 03:56:48	0|kanzure|but 105 didn't work either.
  7 2017-07-14 03:58:01	0|kanzure|oh.
  8 2017-07-14 04:11:55	0|bitcoin-git|[13bitcoin] 15ReneNyffenegger closed pull request #10768: Build System: Prevent warning about "maybe uninitialized variable" nStart in init.cpp (06master...06init-nStart) 02https://github.com/bitcoin/bitcoin/pull/10768
  9 2017-07-14 05:40:49	0|jtimon|what is src/wallet.backup ? and what is making my unittests fail?
 10 2017-07-14 06:22:43	0|wumpus|luke-jr: sure
 11 2017-07-14 06:23:47	0|gmaxwell|I'd seen an shorter version of this presentation before (and I think linked it here),  on failures in fault tolerant systems... some good nightmare fuel (it's on HN right now) https://c3.nasa.gov/dashlink/static/media/other/ObservedFailures1.html
 12 2017-07-14 06:29:42	0|wumpus|wtf is up with https://github.com/bitcoin/bitcoin/pull/10805
 13 2017-07-14 06:30:28	0|luke-jr|wumpus: he's saying we should make manpages and ONLY document in those
 14 2017-07-14 06:30:46	0|luke-jr|ie, get rid of the --help details and RPC help stuff
 15 2017-07-14 06:31:00	0|gmaxwell|why wouldn't we just improve the --help and improve the autogen
 16 2017-07-14 06:31:20	0|luke-jr|he seems to think documentation simply belongs in manpages
 17 2017-07-14 06:31:46	0|luke-jr|I don't necessarily agree (nor disagree).
 18 2017-07-14 06:34:14	0|gmaxwell|documentation in the system is very helpful, from a pratical perspective.
 19 2017-07-14 06:34:31	0|gmaxwell|and much easier to keep updated, and acts as source code documentation too
 20 2017-07-14 06:35:30	0|wumpus|no one is going to maintain external manpages, the generation is useful imo
 21 2017-07-14 06:36:09	0|wumpus|I agree that creates an overlap between --help output and the man page, but I don't see it as a problem
 22 2017-07-14 06:37:25	0|luke-jr|the only ways I see to improve on how we do it now are 1) we lost a manpage for bitcoin.conf, and 2) they ideally would be auto-generated during the build
 23 2017-07-14 06:38:07	0|wumpus|and moving the manpages from doc/man to src makes no sense either, that directory is already cluttered enough
 24 2017-07-14 06:46:36	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10821: Add SSE 4.2 optimized SHA256 (06master...0620170713_shasse) 02https://github.com/bitcoin/bitcoin/pull/10821
 25 2017-07-14 07:24:51	0|bitcoin-git|13bitcoin/06master 14d34d77a 15Cory Fields: build: verify that the assembler can handle crc32 functions...
 26 2017-07-14 07:24:51	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7666250ffb4e...db825d293be8
 27 2017-07-14 07:24:52	0|bitcoin-git|13bitcoin/06master 14db825d2 15Wladimir J. van der Laan: Merge #10806: build: verify that the assembler can handle crc32 functions...
 28 2017-07-14 07:25:26	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10806: build: verify that the assembler can handle crc32 functions (06master...06configure-check-asm) 02https://github.com/bitcoin/bitcoin/pull/10806
 29 2017-07-14 08:00:06	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #10822: TOTEST: Also server txo from gettxout (not just utxo and mempool) (06master...06b15-rpc-txo) 02https://github.com/bitcoin/bitcoin/pull/10822
 30 2017-07-14 08:04:58	0|jonasschnelli|Is there no RPC call (chain) to get a rawtx if I know height and txid?
 31 2017-07-14 08:05:53	0|wumpus|jonasschnelli: #10275?
 32 2017-07-14 08:05:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/10275 | [rpc] Allow fetching tx directly from specified block in getrawtransaction by kallewoof · Pull Request #10275 · bitcoin/bitcoin · GitHub
 33 2017-07-14 08:06:25	0|jonasschnelli|Oh! Nice... I missed that
 34 2017-07-14 08:06:37	0|jonasschnelli|I even commented... :/
 35 2017-07-14 08:07:01	0|jonasschnelli|Would allowing a range of blocks (defined by height) make sense as addition?
 36 2017-07-14 08:07:58	0|wumpus|not sure...
 37 2017-07-14 08:08:20	0|wumpus|when does that use case happen? you know a transaction is in a certain block range?
 38 2017-07-14 08:09:02	0|jonasschnelli|Use case, I know a txid but don't know if it is confirmed or not... maybe you can say "check the last X blocks for txid Y"
 39 2017-07-14 08:09:20	0|jonasschnelli|But yeah.. meh.
 40 2017-07-14 08:09:24	0|jonasschnelli|10275 is really nice
 41 2017-07-14 08:25:15	0|sipa|wumpus: i actually said to gmaxwell earlier today about
 42 2017-07-14 08:26:44	0|sipa|wumpus: i actually said to gmaxwell earlier today about 10820 "in about 3 years someone will try to compile with OpenBSD, and notice that it doesn't work... and then we'll add some #ifdefs around it"
 43 2017-07-14 08:47:10	0|jonasschnelli|I tried to compile Core on a openBSD VM. But I could not even install python3. The package manager idled endless at the point of decompression...
 44 2017-07-14 08:58:18	0|wumpus|sipa: hah, no need to wait for that, I compile bitcoin core on openbsd quite a lot
 45 2017-07-14 08:58:38	0|wumpus|jonasschnelli: strange
 46 2017-07-14 10:07:25	0|mmgen|signrawtransaction is adding the redeem script but not the witness data to transaction. Can anyone help?
 47 2017-07-14 10:08:17	0|mmgen|(I'm adding segwit support to my wallet)
 48 2017-07-14 10:12:19	0|mmgen|And the "signed" transaction with no witness relays OK on testnet and is included in mined block. Strange.
 49 2017-07-14 10:14:48	0|mmgen|What am I missing?
 50 2017-07-14 10:33:12	0|jonasschnelli|mmgen: can you maken an example and file an issue on github?
 51 2017-07-14 10:33:21	0|jonasschnelli|Ideally show your process and in-/output
 52 2017-07-14 10:35:25	0|mmgen|I don't think this warrants an issue.  I'm clearly doing something wrong. signrawtransaction can sign segwit ps2h TXs if you supply the redeem script and keys, right?
 53 2017-07-14 10:37:00	0|mmgen|The sign operation returns OK. TX broadcasts OK. TX is mined. But there's no signature.
 54 2017-07-14 10:53:04	0|mmgen|jonasschnelli: testnet tx d207ffb90c4ceee2ce242990f69b91f67639f25a7b2be76c13b853a0a376b1b5
 55 2017-07-14 10:57:19	0|mmgen|jonasschnelli: just mined
 56 2017-07-14 10:58:42	0|mmgen|jonasschnelli: but has no signature
 57 2017-07-14 11:11:33	0|arubi|mmgen, you're redeeming a p2sh of 0x17 0x160014b7bddbc682c9d41dda1e40c9e5bffcfca385af78
 58 2017-07-14 11:12:34	0|arubi|you want to redeem a p2sh of "0x00 0x14 0xb7bddbc682c9d41dda1e40c9e5bffcfca385af78"  where the length of that script is 0x16
 59 2017-07-14 11:16:06	0|mmgen|arubi: ok
 60 2017-07-14 11:16:20	0|mmgen|arubi: thanks, will check it out
 61 2017-07-14 11:17:39	0|arubi|np mmgen, at least it looks like it.  I don't know what you signed
 62 2017-07-14 11:19:00	0|mmgen|arubi: Busy now, I'll get back to you in about 30 min
 63 2017-07-14 11:20:54	0|arubi|ok, anyway the hash160 is of 160014B7BDDBC682C9D41DDA1E40C9E5BFFCFCA385AF78 instead of 0014B7BDDBC682C9D41DDA1E40C9E5BFFCFCA385AF78
 64 2017-07-14 11:22:03	0|mmgen|arubi: I just need to remove the leading 0x16 i think
 65 2017-07-14 11:23:06	0|mmgen|thought the 0x16 was needed for data push
 66 2017-07-14 11:28:53	0|mmgen|arubi: I was creating the redeem script like this: '160014' + hash160(pubhex)
 67 2017-07-14 11:32:47	0|mmgen|Strange that signrawtransaction didn't complain though
 68 2017-07-14 11:33:12	0|mmgen|despite my malformed script
 69 2017-07-14 11:33:56	0|arubi|it's just redeeming a p2sh of a single push of what you hash160'ed
 70 2017-07-14 11:34:01	0|arubi|it's not a segwit scriptpubkey, so no sig is needed
 71 2017-07-14 11:36:59	0|mmgen|but without the key it wouldn't sign for some reason
 72 2017-07-14 11:40:01	0|arubi|try with a different key :)
 73 2017-07-14 11:41:32	0|mmgen|arubi: will try. Thanks much for your help
 74 2017-07-14 11:55:16	0|mmgen|arubi: so any p2sh script consisting of a single data push is redeemable. OP_EQUAL returns True, the stack is empty, so it's valid.
 75 2017-07-14 11:56:00	0|mmgen|arubi: wonder if some sort of sanity check should be added to prevent goofups like this?
 76 2017-07-14 11:56:28	0|arubi|the stack isn't empty, it has a final 0x01 on it from the TRUE executing
 77 2017-07-14 11:56:57	0|mmgen|ok, True's on the stack, so it's valid
 78 2017-07-14 11:57:18	0|arubi|er, from the EQUAL
 79 2017-07-14 11:58:00	0|mmgen|so now if I spend to that address again, anyone who's seen the script can steal the coins
 80 2017-07-14 11:58:19	0|arubi|anyway,  we're getting off topic here :)
 81 2017-07-14 11:58:25	0|arubi|right
 82 2017-07-14 11:59:10	0|mmgen|so maybe the client should reject p2sh scripts consisting of a single data push then?
 83 2017-07-14 11:59:24	0|bitcoin-git|[13bitcoin] 15janstary closed pull request #10805: have proper manpages for bitcoin*(1) (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10805
 84 2017-07-14 12:00:21	0|arubi|reject how?  it can't tell what the script is when you fund the address
 85 2017-07-14 12:00:32	0|mmgen|oh, right
 86 2017-07-14 12:01:22	0|mmgen|just when you sign, and by then it's too late
 87 2017-07-14 12:02:23	0|arubi|note you'd still be pushing a single value for redeeming a p2sh(segwit), the segwit spk itself serialized
 88 2017-07-14 12:02:24	0|mmgen|so there's no real point in checking at the signing stage
 89 2017-07-14 12:04:45	0|mmgen|arubi: ok
 90 2017-07-14 13:22:45	0|cfields|sipa: I believe I know the problem with #10821. Testing a fix.
 91 2017-07-14 13:22:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/10821 | Add SSE 4.2 optimized SHA256 by sipa · Pull Request #10821 · bitcoin/bitcoin · GitHub
 92 2017-07-14 13:47:13	0|bitcoin-git|[13bitcoin] 15greenaddress opened pull request #10823: Allow all mempool txs to be replaced after a configurable timeout (default 6h) (06master...06replace-by-fee-old-transactions) 02https://github.com/bitcoin/bitcoin/pull/10823
 93 2017-07-14 13:53:59	0|cfields|sipa: interesting. clang doesn't enable -fomit-frame-pointer at any optim level
 94 2017-07-14 13:54:11	0|cfields|adding that in fixes compilation
 95 2017-07-14 13:58:04	0|luke-jr|doesn't it break debugging?
 96 2017-07-14 14:05:30	0|bitcoin-git|[13bitcoin] 15promag opened pull request #10824: Avoid unnecessary work in SetNetworkActive (06master...062017-07-set-network-active) 02https://github.com/bitcoin/bitcoin/pull/10824
 97 2017-07-14 14:08:33	0|cfields|luke-jr: it's on by default for x86_64
 98 2017-07-14 14:08:41	0|cfields|er, for gcc
 99 2017-07-14 14:14:25	0|mmgen|arubi: now redeem script is correctly formed, signrawtransaction is including the witness data, but txsend fails with 64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code -26)
100 2017-07-14 14:17:36	0|mmgen|input in question is output 0 of testnet tx dd2117779039b6abd20529c9c9ce67b4c18c0a0223129759ae01deebaa037151
101 2017-07-14 14:20:37	0|mmgen|wif: cVGLmgcfnq2jvdhNFn9UJQWe6NUCr71GMHePKZC8eXc6fNdJsRuM
102 2017-07-14 14:20:47	0|mmgen|addr: 2N3wYVH1n51ucjnGR2fjcqb6GPeUmDxQH3h
103 2017-07-14 14:25:44	0|arubi|mmgen, then your sig is not valid.  it's too off topic here. we can move to #bitcoin-dev if you want
104 2017-07-14 14:27:39	0|mmgen|arubi: agreed, this is offtop, but #bitcoin-dev requires registration doesn't it?
105 2017-07-14 14:28:47	0|arubi|oh I don't know..
106 2017-07-14 14:29:08	0|mmgen|think it does. How do I go about that?
107 2017-07-14 14:30:06	0|arubi|that's something done through nickserv
108 2017-07-14 14:32:39	0|Chris_Stewart_5|it does
109 2017-07-14 14:32:57	0|Chris_Stewart_5|and I have no idea why it does :/
110 2017-07-14 14:33:53	0|arubi|yea it's an overkill
111 2017-07-14 14:35:08	0|mmgen|yet #bitcoin-core-dev doesn't
112 2017-07-14 14:35:27	0|mmgen|I'm working on registration now
113 2017-07-14 14:39:10	0|mmgen|sent the request
114 2017-07-14 14:45:41	0|morcos|promag: Your question before about the buggy output.  That isn't buggy as far as I can tell.  What did you not like?  The -1's?
115 2017-07-14 14:45:53	0|promag|nan
116 2017-07-14 14:46:33	0|morcos|oh i think we covered that before and determined it was fine to divide by 0 (it's only for outputing text) and in this case there are no txs in the denominator
117 2017-07-14 14:47:24	0|promag|for reference the output is: Fee Calculation: Fee:4520 Bytes:226 Tgt:6 (requested 6) Reason:"Fallback fee" Decay 0.00000: Estimation: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out) Fail: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out)
118 2017-07-14 14:48:01	0|morcos|yeah so that tells me there were no data points in your fee estimation
119 2017-07-14 14:48:53	0|promag|right, but in the UI it says: "Warning: Fee estimation is currently not possible"
120 2017-07-14 14:49:53	0|morcos|promag: yes exactly..  and the debug log is telling you exactly why it is not possible.  no data points.  it could have also indicated some smaller number of data points, or enough data points but no fee rate high enough that meets the passing threshold for your target
121 2017-07-14 14:50:24	0|morcos|that debug log output is just for help determining exactly why a particular fee is put on a transaction.
122 2017-07-14 14:51:01	0|morcos|gmaxwell: speaking of which we'd recently discussed making the fallback fee higher than 20 sat/b.  I think we discussed 50 or 75.  The thinking at the time is 20 is often not high enough to ever get confirmed.
123 2017-07-14 14:51:15	0|morcos|But perhaps we were over influenced by a short period of congestion?
124 2017-07-14 14:51:36	0|promag|ok then morcos, thanks
125 2017-07-14 14:51:56	0|morcos|In any case, I'd still be ok with 50 or 75 as the default for fallback..  I don't think its so unreasonably high that people would complain if they paid that if fee estimation wasn't working
126 2017-07-14 14:52:41	0|morcos|The downside is if fees drop substantially over some period of time, lets say BTC goes up 10x, and then paying 75 sat/B is actually kind of a lot.  I suppose it's a no win situation for getting the right number here.
127 2017-07-14 14:53:04	0|morcos|Maybe the answer is to not touch the default but give advice in release notes about setting that number appropriately?
128 2017-07-14 15:17:45	0|bitcoin-git|[13bitcoin] 15fametrano opened pull request #10825: Net set regtest JSON-RPC port to 18443 to avoid conflict with testnet 18332 (06master...06fametrano-regtestport) 02https://github.com/bitcoin/bitcoin/pull/10825
129 2017-07-14 15:52:12	0|To7|Core dev, time to protect Bitcoin differently.
130 2017-07-14 15:52:14	0|To7|I need help spreading the word on this: https://medium.com/bitcoinfoundation/the-foul-smell-of-federal-cryptocurrency-legislation-bd0a58995b60
131 2017-07-14 15:52:14	0|To7|Instructions are here: https://www.reddit.com/r/Bitcoin/comments/6n9lah/anyone_knows_how_to_get_hold_of_the_other_cryptos
132 2017-07-14 16:24:03	0|instagibbs|is there reasoning for sendrawtransaction bypassing free relay limit?
133 2017-07-14 17:34:18	0|instagibbs|oh im hallucinating, it doesn't
134 2017-07-14 17:37:18	0|instagibbs|(anymore)
135 2017-07-14 17:38:48	0|sipa|cfields: adding -fomit-frame-pointer sounds like it may in general improve performance then...
136 2017-07-14 17:39:45	0|cfields|sipa: I'm not sure if clang/ld64 add necessary debug sections, though
137 2017-07-14 17:40:46	0|bitcoin-git|[13bitcoin] 15Thecave3 opened pull request #10827: fixed grammar error (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/10827
138 2017-07-14 17:41:30	0|BlueMatt|who uses listsinceblock?
139 2017-07-14 17:41:33	0|BlueMatt|anyone?
140 2017-07-14 17:41:47	0|cfields|sipa: i'll experiment
141 2017-07-14 17:42:24	0|instagibbs|BlueMatt, there exists users... why
142 2017-07-14 17:42:32	0|BlueMatt|without looking at the code (just the docs), can folks tell me what they think the "target_confirmations" parameter means in listsinceblock?
143 2017-07-14 17:42:41	0|BlueMatt|"2. target_confirmations:    (numeric, optional) The confirmations required, must be 1 or more\n"
144 2017-07-14 17:42:45	0|BlueMatt|https://github.com/bitcoin/bitcoin/blob/master/src/wallet/rpcwallet.cpp#L1734
145 2017-07-14 17:44:01	0|Murch|Is anyone aware of best case practices regarding path derivation of segwit addresses?
146 2017-07-14 17:44:12	0|instagibbs|BlueMatt, https://github.com/bitcoin/bitcoin/pull/10655
147 2017-07-14 17:44:34	0|Murch|We currently have two paths for receive and change addresses, and we're considering to adding another two paths for segwit receive and change addresses.
148 2017-07-14 17:44:49	0|instagibbs|Murch, there are none right now AFAIK. BIP49 I think is the only proposed one for Mycelium or something
149 2017-07-14 17:44:59	0|BlueMatt|instagibbs: ahh, ok, that still leaves me wondering what in the fuck the purpose of that argument is
150 2017-07-14 17:45:15	0|Murch|instagibbs: Thanks, I'll take a look.
151 2017-07-14 17:45:55	0|instagibbs|Murch, I'd suggest asking various wallet authors, don't think there's consensus on that at all
152 2017-07-14 17:46:28	0|Murch|What would be a good way to reach them? Would that perhaps be worth a mail to the bitcoin-dev list?
153 2017-07-14 17:46:51	0|BlueMatt|instagibbs: care to ack that? I find that astoundingly poor docs, should fix for 15 if possible
154 2017-07-14 17:47:03	0|instagibbs|BlueMatt, asking the author, I have actually no clue
155 2017-07-14 17:47:50	0|BlueMatt|the docs on 10655 make it a bit more clear, ie if you care about when things hit 6 confs, you calling listsinceblock with old blocks each time so that you keep getting reminded of things with 6 confs
156 2017-07-14 17:47:57	0|BlueMatt|and then you filter for txn with 6 confs yourself
157 2017-07-14 17:48:08	0|BlueMatt|still seems a super strange api to me, but i can see why it would be useful
158 2017-07-14 17:48:13	0|instagibbs|Murch, yeah I think so. Also bug bigger players individually maybe
159 2017-07-14 17:48:32	0|Murch|instagibbs: Thanks for the consult. ;)
160 2017-07-14 18:04:23	0|cfields|sipa: heh, not a good sign: Assertion failed: (consensus.hashGenesisBlock == uint256S("0x000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943")),
161 2017-07-14 18:05:03	0|cfields|makes for a good backtrace example, though: https://pastebin.com/raw/kA3bavgA
162 2017-07-14 18:05:36	0|sipa|cfields: bah, i could make it manually save and restore the frame.pointer during the duration of the asm blocm
163 2017-07-14 18:05:55	0|cfields|sipa: that's with 10821 and -fomit-frame-pointer
164 2017-07-14 18:06:25	0|cfields|no clue if that's the cause of the failure, or something else busted
165 2017-07-14 18:55:22	0|bitcoin-git|13bitcoin/06master 1418bacec 15Alex Morcos: Make check to distinguish between orphan txs and old txs more efficient....
166 2017-07-14 18:55:22	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/db825d293be8...66270a416edb
167 2017-07-14 18:55:23	0|bitcoin-git|13bitcoin/06master 1466270a4 15Pieter Wuille: Merge #10557: Make check to distinguish between orphan txs and old txs more efficient....
168 2017-07-14 18:55:44	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10557: Make check to distinguish between orphan txs and old txs more efficient. (06master...06dontcheckoutputs) 02https://github.com/bitcoin/bitcoin/pull/10557
169 2017-07-14 19:05:31	0|bitcoin-git|[13bitcoin] 15Thecave3 closed pull request #10827: fixed grammar error (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/10827
170 2017-07-14 19:20:28	0|jonasschnelli|hmm.. we should add bench to the gitian build/exported binaries
171 2017-07-14 19:34:31	0|sipa|cfields: could you send me a disassembled version of that function?
172 2017-07-14 19:55:02	0|cfields|sipa: sure, give me just a few min
173 2017-07-14 19:55:13	0|cfields|i managed to get it working when built from yasm
174 2017-07-14 19:59:21	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #10829: Simple, backwards compatible RPC multiwallet support. (06master...06pr/multiparam) 02https://github.com/bitcoin/bitcoin/pull/10829
175 2017-07-14 20:00:28	0|sipa|cfields: the code here was an attempt to actually translate it to extended asm, where the compiler still manages the stack and register allocation
176 2017-07-14 20:01:03	0|sipa|cfields: i can go for the more straightforward way of just making it produce literally the same bytecode as yasm, where the asm is responsible for saving/restoring registers etc
177 2017-07-14 20:01:12	0|cfields|sipa: understood, i just wanted to get a working asm dump to compare to
178 2017-07-14 20:05:17	0|cfields|heh, no clue what all this padding is about
179 2017-07-14 20:08:00	0|cfields|sipa: https://pastebin.com/raw/G4nHr9F5
180 2017-07-14 20:08:08	0|cfields|i snipped the padding
181 2017-07-14 20:10:01	0|cfields|for comparison, yasm's output: https://pastebin.com/raw/Sk3BfXyW
182 2017-07-14 20:11:15	0|cfields|note that I had to -DLINUX with yasm, otherwise I'd get the same crash
183 2017-07-14 20:13:00	0|BlueMatt|sipa: can you mark 10807 as 0.15 (or merge it) since easy bugfix
184 2017-07-14 20:30:54	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10830: [WIP] [wallet] keypool restore (06master...06pr10240) 02https://github.com/bitcoin/bitcoin/pull/10830
185 2017-07-14 20:32:07	0|jnewbery|#10830 is #10240 rebased on master. Please mark it as high priority & 0.15
186 2017-07-14 20:32:08	0|gribble|https://github.com/bitcoin/bitcoin/issues/10830 | [WIP] [wallet] keypool restore by jnewbery · Pull Request #10830 · bitcoin/bitcoin · GitHub
187 2017-07-14 20:32:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
188 2017-07-14 20:32:17	0|cfields|sipa: may also be helpful to know that the resulting hash is: 19cde05babd9831f8c68059b7f520e513af54fa572f36e3c85ae67bb67e6096a
189 2017-07-14 20:32:24	0|cfields|(initial sha2 state)
190 2017-07-14 21:23:09	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #10240: Add HD wallet auto-restore functionality (06master...062017/04/hd_rescan) 02https://github.com/bitcoin/bitcoin/pull/10240
191 2017-07-14 21:54:31	0|bitcoin-git|13bitcoin/06master 144652791 15João Barbosa: Fix uninitialized atomic variables
192 2017-07-14 21:54:31	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/66270a416edb...b7d6623c76e1
193 2017-07-14 21:54:32	0|bitcoin-git|13bitcoin/06master 14b7d6623 15Pieter Wuille: Merge #10819: Fix uninitialized atomic variables...
194 2017-07-14 21:55:06	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10819: Fix uninitialized atomic variables (06master...062017-07-fix-unitialized-atomic) 02https://github.com/bitcoin/bitcoin/pull/10819
195 2017-07-14 21:55:28	0|sipa|cfields: i can make the code use one less register
196 2017-07-14 21:55:45	0|cfields|sipa: i've been trying to figure it out :)
197 2017-07-14 21:56:06	0|cfields|sipa: i think you can shortcut the end address calculation?
198 2017-07-14 21:56:17	0|sipa|cfields: if you look at the yasm source, NUM_BLOCKS and e use the same register
199 2017-07-14 21:56:34	0|sipa|one uses it in 32-bit mode (edx) and one in 64-bit mode (rdx)
200 2017-07-14 21:56:43	0|sipa|which my search/replacing treated as two different things
201 2017-07-14 21:57:14	0|cfields|ah
202 2017-07-14 22:03:02	0|cfields|ok i see, that makes sense. That's the one I was trying to save as well. But so far I'd just managed to piss off the assembler in a bunch of different ways.
203 2017-07-14 22:03:54	0|sipa|cfields: so s/%7/%k2/
204 2017-07-14 22:04:06	0|sipa|%k2 means "the same as %2, but in 32-bit mode"
205 2017-07-14 22:04:24	0|sipa|and then more shuffling to get rid of the e variable...
206 2017-07-14 22:05:24	0|cfields|roger
207 2017-07-14 22:07:06	0|cfields|sipa: i'm confused as to why inp_end can't be pre-calculated and passed as an input, skipping %2 altogether?
208 2017-07-14 22:08:45	0|sipa|cfields: we could move that out to the C code, yes
209 2017-07-14 22:09:22	0|sipa|the asm code really uses a begin_ptr and end_ptr
210 2017-07-14 22:09:35	0|sipa|and the first 3 instructions convert the (begin_ptr, num_blocks) to that
211 2017-07-14 22:10:14	0|cfields|sipa: right ok, thanks. no need to do that rather than your approach ofc, but it helps to know that would've worked
212 2017-07-14 22:12:00	0|gmaxwell|sipa was in the process of changing everything to use explicit registers and then he was going to manually save bp on the stack so he could use it and restore it at the end.
213 2017-07-14 22:12:21	0|sipa|this approach now should be faster
214 2017-07-14 22:12:35	0|sipa|as it only saves/restores exactly what is needed
215 2017-07-14 22:14:03	0|cfields|testing now
216 2017-07-14 22:18:08	0|sipa|cfields: thanks!
217 2017-07-14 22:20:45	0|cfields|sipa: builds now, but still produces a busted hash :(
218 2017-07-14 22:21:10	0|sipa|:'(
219 2017-07-14 22:21:29	0|sipa|cfields: with or without -fomit-frame-pointer ?
220 2017-07-14 22:21:40	0|cfields|without now
221 2017-07-14 22:22:15	0|cfields|i'll try without the stack protector
222 2017-07-14 22:23:16	0|cfields|same thing
223 2017-07-14 22:23:19	0|sipa|cfields: i can try force assigning variables to registers, to make the code comparable to the yasm code?
224 2017-07-14 22:23:55	0|sipa|to make sure the same assignment is used
225 2017-07-14 22:24:05	0|cfields|sure
226 2017-07-14 22:24:55	0|cfields|sipa: from what i can see, the input is no longer necessarily 32bit aligned
227 2017-07-14 22:25:00	0|cfields|is that a possible issue?
228 2017-07-14 22:25:18	0|sipa|cfields: oh!
229 2017-07-14 22:25:31	0|sipa|how do you mean?
230 2017-07-14 22:25:56	0|cfields|let me double-check, i might've reversed something in testing
231 2017-07-14 22:29:45	0|cfields|sipa: yea, the ReadBE32 on the chunk guaranteed alignment before, without that, is something else handling it?
232 2017-07-14 22:30:54	0|sipa|cfields: the asm code can deal with unaligned input data
233 2017-07-14 22:31:10	0|cfields|ok
234 2017-07-14 22:32:19	0|sipa|cfields: i think that the xfer array may need stronger alignment than the compiler is giving it
235 2017-07-14 22:37:45	0|sipa|cfields: care to try again?
236 2017-07-14 22:38:23	0|cfields|sure, i'll take a break from fighting this thing.
237 2017-07-14 22:40:55	0|cfields|heh, i was trying the same thing, but i pissed it off trying to make it 32bit aligned
238 2017-07-14 22:40:57	0|cfields|no go :(
239 2017-07-14 22:41:12	0|sipa|same error?
240 2017-07-14 22:41:26	0|cfields|yea. you just added the attribute, right?
241 2017-07-14 22:41:36	0|sipa|yes
242 2017-07-14 22:42:26	0|cfields|btw, that can be alignas(16) with c++11
243 2017-07-14 22:45:39	0|cfields|generated asm now: https://pastebin.com/raw/SRe0gzUf
244 2017-07-14 22:46:45	0|cfields|any clue what the huge chunk of padding is?
245 2017-07-14 22:47:23	0|sipa|the nopws?
246 2017-07-14 22:47:47	0|sipa|cfields: can you try changing the movdqa instructions to movdqu ?
247 2017-07-14 22:47:53	0|sipa|(a = aligned, u = unaligned)
248 2017-07-14 22:48:04	0|cfields|yea, 0x91 through 0x10000
249 2017-07-14 22:48:12	0|cfields|ok
250 2017-07-14 22:50:05	0|cfields|nope :(
251 2017-07-14 22:50:12	0|sipa|cfields: my guess is that to the OSX assembler ".align 16" means "align to a 2^16-byte boundary"
252 2017-07-14 22:50:54	0|sipa|instead of "align to 16-byte boundary"
253 2017-07-14 22:50:56	0|cfields|ah
254 2017-07-14 22:54:07	0|sipa|cfields: pushed again, try again pretty please?
255 2017-07-14 22:54:16	0|cfields|heh, sure
256 2017-07-14 22:54:21	0|sipa|added some more alignas'es
257 2017-07-14 22:54:33	0|sipa|i think there are instructions beyond movdqa that require aligned input
258 2017-07-14 22:57:16	0|cfields|still no go
259 2017-07-14 22:57:43	0|cfields|you saw me mention that the result is always the sha2 init values, right?
260 2017-07-14 22:58:01	0|sipa|oh, no
261 2017-07-14 22:58:20	0|cfields|hash is "19cde05babd9831f8c68059b7f520e513af54fa572f36e3c85ae67bb67e6096a"
262 2017-07-14 23:03:05	0|sipa|cfields: you're aware the yasm function takes its parameters in a different order?
263 2017-07-14 23:03:55	0|cfields|yes, i had to reverse them to make it work
264 2017-07-14 23:05:02	0|sipa|grrr
265 2017-07-14 23:05:50	0|sipa|i really don't see how the state can be untouched with your disasm code... unless blocks=0
266 2017-07-14 23:15:33	0|cfields|i'm stumped too. It gets in there sometimes with blocks=0, but even if I early-return, same result
267 2017-07-14 23:16:00	0|sipa|can you give a latest disasm?
268 2017-07-14 23:16:17	0|sipa|can you step through it with a debugger, to see if it's actually doing anything?
269 2017-07-14 23:16:28	0|sipa|(stepi in gdb will execute 1 instruction)
270 2017-07-14 23:16:48	0|cfields|i've tried to get in with no luck
271 2017-07-14 23:16:50	0|cfields|i can try again
272 2017-07-14 23:17:06	0|cfields|(it's lldb, and i'm not at all familiar with it)
273 2017-07-14 23:23:47	0|sipa|cfields: just some thing i'm noticing from the latest disasm you posted: the stack pointer isn't being updated, but is addressed with negative offsets (which is legal, but different from other platforms)
274 2017-07-14 23:24:01	0|sipa|it also saves and restores the frame pointer, but does not actually use it
275 2017-07-14 23:25:06	0|cfields|sipa: i noticed the negative offsets too. how can that be the case?
276 2017-07-14 23:25:41	0|sipa|cfields: it's legal to use some stack space below the stack pointer (google for red zone)
277 2017-07-14 23:26:23	0|sipa|if you want to set a breakpoint, set it to the loop2 label
278 2017-07-14 23:26:38	0|cfields|interesting
279 2017-07-14 23:26:45	0|sipa|if loop2 is reached, it should always update the context
280 2017-07-14 23:26:58	0|cfields|that's a rabbit hole for a different day though :)
281 2017-07-14 23:26:59	0|sipa|(the updating happens in the addq/movq sequence right before done_loop)
282 2017-07-14 23:27:12	0|sipa|eh, addl/movl
283 2017-07-14 23:27:41	0|sipa|can you just post a latest disasm? :)
284 2017-07-14 23:27:50	0|cfields|haha, 1 sec
285 2017-07-14 23:35:01	0|cfields|sipa: https://pastebin.com/raw/rqNABs3S
286 2017-07-14 23:36:29	0|cfields|uh, I switched to -O0 for better debugging, let me know if you want an -O2 to match the others
287 2017-07-14 23:36:46	0|cfields|i assume it doesn't matter much here
288 2017-07-14 23:36:59	0|cfields|i was just trying to get it un-inlined
289 2017-07-14 23:37:29	0|cfields|(it wasn't anyway. oops)
290 2017-07-14 23:38:21	0|sipa|cfields: my latest code just doesn't compile with clang 4.0
291 2017-07-14 23:38:30	0|sipa|are you sure you're testing the right thing?
292 2017-07-14 23:38:36	0|cfields|i moved the alignas's around
293 2017-07-14 23:38:40	0|cfields|if that's what you mean
294 2017-07-14 23:38:44	0|sipa|ok
295 2017-07-14 23:38:46	0|sipa|yes
296 2017-07-14 23:39:08	0|sipa|trying to reproduce on linux
297 2017-07-14 23:39:43	0|cfields|i tried dumping the dispatcher and hard-coding the call instead
298 2017-07-14 23:39:55	0|cfields|thought there might be some static init race. no help though.
299 2017-07-14 23:40:15	0|sipa|what clang version are you using?
300 2017-07-14 23:40:36	0|cfields|stupid apple...
301 2017-07-14 23:40:50	0|cfields|Apple LLVM version 7.3.0 (clang-703.0.29)
302 2017-07-14 23:41:01	0|cfields|no clue what ^^ is
303 2017-07-14 23:41:19	0|cfields|let me see if a cross build works, then we'll have an upstream clang for data point
304 2017-07-14 23:42:45	0|sipa|works fine with clang-4.0
305 2017-07-14 23:42:48	0|sipa|trying 3.7 now
306 2017-07-14 23:43:13	0|sipa|eh, 3.7 fails on some c++11 stuff
307 2017-07-14 23:43:33	0|cfields|eh?
308 2017-07-14 23:43:33	0|cfields|for reference, i'm building with 3.7.1 now for cross
309 2017-07-14 23:43:44	0|sipa|In file included from ./httpserver.h:10:
310 2017-07-14 23:43:44	0|sipa|/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/functional:1370:11: error: no matching constructor for initialization of 'std::tuple<packaged_task<bool (event_base *, evhttp *)>, event_base *, evhttp *>'
311 2017-07-14 23:43:47	0|cfields|c++ lib issues?
312 2017-07-14 23:43:48	0|sipa|: _M_bound(std::forward<_Tp>(__f), std::forward<_Up>(__args)...)
313 2017-07-14 23:43:51	0|sipa|^        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
314 2017-07-14 23:44:07	0|sipa|why is it using gcc-6.3's include dir?
315 2017-07-14 23:44:26	0|cfields|give it -stdlib=libc++
316 2017-07-14 23:46:18	0|cfields|(you might need LD_LIBRARY_PATH set to run)
317 2017-07-14 23:47:11	0|cfields|ok, cross with 3.7.1 dies the same way
318 2017-07-14 23:49:33	0|sipa|ok, compiling with 3.7.0
319 2017-07-14 23:52:03	0|sipa|/home/pw/git/bitcoin-shasse/src/util.cpp:861: undefined reference to `boost::filesystem::path::imbue(std::__1::locale const&)'
320 2017-07-14 23:53:01	0|cfields|heh, your boost was built against libstdc++
321 2017-07-14 23:53:27	0|sipa|can i do a depends build on linux with clang?
322 2017-07-14 23:53:32	0|sipa|on/for lnux
323 2017-07-14 23:54:11	0|cfields|you can probably just do up a tiny stub app using CSHA256 directly, no?