1 2017-01-04 02:52:56	0|morcos|BlueMatt: The remaining sdaftuar comment is in regards to the fact that you could announce two compact blocks via NewPoWValidBlock in quick succession even after the change to only announce potential new tips
  2 2017-01-04 02:55:35	0|morcos|If those are tied at the same height, then one of them will not have ever become our tip and sp wpm
  3 2017-01-04 02:56:35	0|morcos|oops..  and so won't be BLOCK_VALID_SCRIPTS or in our best chain and we'll stall any node asking for it
  4 2017-01-04 03:00:04	0|morcos|but yes the change to BLOCK_VALID_TRANSACTIONS is in the later line where we set "send".  and the recently added code in getdata to fix my bug from 9447 can go away.
  5 2017-01-04 03:03:44	0|gmaxwell|I've kinda wonered if we shouldn't just remember the NewPoWblock announcements that we've done e.g. {peer, hash} in a limitedmap, and then if we get in a request that is in that map, just blindly reply with the data on disk.
  6 2017-01-04 03:03:52	0|gmaxwell|Similar to how the relay pool works.
  7 2017-01-04 03:05:12	0|gmaxwell|(in that the relay pool means we'll give you a transaction we offered to you, even if we've since discarded it)
  8 2017-01-04 03:07:34	0|morcos|gmaxwell: that's what i was thinking at first too, but i think sdaftuar's solution might just be more elegant
  9 2017-01-04 03:09:01	0|morcos|as long as you lock cs_main if the requested hash doesn't match the cached block, that'll mean any announced block will be written to disk, and be available to be read..
 10 2017-01-04 03:10:06	0|morcos|since these will be rare, i don' tthink there is a performance issue with reading them back from disk, the only existing problem is we weren't serving them b/c we weren't seeing them as BLOCK_VALID_SCRIPTS b/c they'd never been connected
 11 2017-01-04 03:10:26	0|morcos|oh shoot... i keep forgetting... you can't serve them in that case
 12 2017-01-04 03:10:42	0|morcos|well if we're going to be pedantic about following the protocol we've got a problem
 13 2017-01-04 03:11:02	0|morcos|b/c we're announcing blocks before we even now if we're going to test them for validity, so what do we do if we never test them
 14 2017-01-04 03:11:37	0|morcos|also perhaps we never though through the case of what to do if we announce a block that turns out to be invalid... surely stalling the requester isn't the right course of action
 15 2017-01-04 03:17:35	0|gmaxwell|(actually the deseralizzation is pretty slow, as an aside)
 16 2017-01-04 03:18:09	0|gmaxwell|your concern is because we didn't really properly consider relaying unvalidated blocks, but we just glommed it on because it would have unfortunate to specify BIP152 another way.
 17 2017-01-04 03:18:34	0|morcos|i hope thats a statement and not a question
 18 2017-01-04 03:18:51	0|gmaxwell|We should specify a network message that says "I think block XYZ is invalid, if I told you about it before, forget about it, I'm not going to respond to requests about it."
 19 2017-01-04 03:19:05	0|gmaxwell|statement.
 20 2017-01-04 03:19:17	0|gmaxwell|A negative-inv if you will.
 21 2017-01-04 03:19:49	0|morcos|yeah..   but we need to do something for now..
 22 2017-01-04 03:20:08	0|gmaxwell|though perhaps like the relay pool we ought to be willing to serve up data for any block we've pre-relayed, even if we never verified it and don't intend to.
 23 2017-01-04 03:20:40	0|gmaxwell|which we could do with a relay pool like strategy. even avoid putting them on disk... (who cares about a few megabytes of blocks in ram?)
 24 2017-01-04 03:21:53	0|morcos|yes but avoiding disk is an unnecessary optimization... we're talking about a rare race condition here (and we've already writtent them to disk before we've even decided whether to validate or not)
 25 2017-01-04 03:23:59	0|gmaxwell|okay, from your comments above I was thinking there was some path where we didn't save to disk.
 26 2017-01-04 03:24:44	0|gmaxwell|We don't generally want to allow arbritary peers to fetch blocks on disk that aren't in our best chain. (leads to fingerprinting attacks). Which was why I made the peer,hash suggestion above.
 27 2017-01-04 03:26:19	0|morcos|gmaxwell: we already have other various protections that aren't always that it's in our best chain, in this case, we require non-best-chain blocks to be less than 30 days old
 28 2017-01-04 03:26:42	0|morcos|but we also require BLOCK_VALID_SCRIPTS, if we just loosen that we're ok  (for the case of untested blocks)
 29 2017-01-04 03:27:30	0|morcos|i still think we potentially have a problem about what to do with blocks that turn out to be invalid
 30 2017-01-04 03:27:53	0|morcos|back in a bit
 31 2017-01-04 03:36:30	0|gmaxwell|I think for now we should serve them if we've advertised them... but should make a protocol extension so we can refuse to.
 32 2017-01-04 03:37:06	0|gmaxwell|(we do ourselves no favors to help the network converge on things we think are invalid)
 33 2017-01-04 06:33:09	0|gmaxwell|why do we know have a birthday/rescan height for importaddress?
 34 2017-01-04 06:33:41	0|gmaxwell|I had thought this was going to get fixed with a range setting for the rescan rpc, but I see we closed that with 'you should import with birthdays' but there is no way to do that for a watching address import.
 35 2017-01-04 06:36:24	0|gmaxwell|oh I see importmulti has a timestamp. cool.
 36 2017-01-04 06:38:02	0|gmaxwell|midnightmagic: wrt the question someone was asking in #bitcoin about how do you handle an import backlog for a node that was offline: You use importmulti with the approrpiate birthdates, and it will handle any required rescan.
 37 2017-01-04 06:39:42	0|gmaxwell|perhaps the importaddress RPC help text should recommend you use importmulti instead.
 38 2017-01-04 07:21:34	0|bitcoin-git|13bitcoin/06master 14fab6c5f 15MarcoFalke: [qt] Do not translate `~`
 39 2017-01-04 07:21:34	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2a524b8e8fe6...649cf5fe894b
 40 2017-01-04 07:21:35	0|bitcoin-git|13bitcoin/06master 14649cf5f 15Wladimir J. van der Laan: Merge #9462: [qt] Do not translate tilde character...
 41 2017-01-04 07:21:54	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9462: [qt] Do not translate tilde character (06master...06Mf1701-qtTransTilde) 02https://github.com/bitcoin/bitcoin/pull/9462
 42 2017-01-04 08:11:55	0|gmaxwell|gah we still sign inside the transaction creation inner loop?! I thought we fixed that a long time ago. :-/
 43 2017-01-04 08:12:05	0|gmaxwell|insanity.
 44 2017-01-04 08:38:19	0|jonasschnelli|gmaxwell: you don't if you are using fundrawtx
 45 2017-01-04 08:38:48	0|jonasschnelli|well, you use the dummy signer
 46 2017-01-04 08:41:50	0|Jouke|pruning node do forward blocks nowadays right?
 47 2017-01-04 08:41:57	0|gmaxwell|yes.
 48 2017-01-04 08:42:53	0|Jouke|A rescan on my problem node didn't work, so I removed the block and chainstate dir and let it sync from fresh.
 49 2017-01-04 08:43:36	0|gmaxwell|rescan? why were you rescanning?
 50 2017-01-04 08:44:20	0|Jouke|I had that problem before which you helped me with a couple of days ago.
 51 2017-01-04 08:44:48	0|Jouke|It couldn't read a block from disk when I issued a getblock rpc call
 52 2017-01-04 08:44:53	0|gmaxwell|did you rescan or reindex?
 53 2017-01-04 08:45:07	0|gmaxwell|rescan will do nothing, so if that didn't work it's unsurprising.
 54 2017-01-04 08:45:16	0|Jouke|Euh, reindex indeed
 55 2017-01-04 08:45:37	0|Jouke|I did a reindex
 56 2017-01-04 08:45:47	0|gmaxwell|whew. Interesting!
 57 2017-01-04 08:46:39	0|Jouke|But since it was connected only to a pruning node, I had it temporarily connect to an other node of mine through an ssh tunnel.
 58 2017-01-04 08:46:57	0|gmaxwell|yes, can't fetch the history through the pruned node.
 59 2017-01-04 08:47:55	0|Jouke|That connection went down this evening (I'm in europe), and it synced to block 445248
 60 2017-01-04 08:48:34	0|Jouke|But the pruning node it connects to should have the rest of the blocks as prune=80000
 61 2017-01-04 08:48:47	0|gmaxwell|if you were expecting it to fetch blocks that weren't at the tip but were within the pruning window, that also won't work: the pruned node has no way to tell the peer what blocks it has.
 62 2017-01-04 08:49:57	0|gmaxwell|your fetching node will not try to sync off it. But when the pruned node has a new block it will relay it along (and if there is a reorg required, the client node will still fetch whatever blocks are required to accomplish the reorg).
 63 2017-01-04 08:50:30	0|Jouke|Hmm, ok.
 64 2017-01-04 08:50:56	0|Jouke|So my expectations were wrong. Thanks again for explaining!
 65 2017-01-04 08:57:17	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #9465: [Wallet] Do not perform ECDSA in the fee calculation inner loop. (06master...06no_signing_in_inner_loop) 02https://github.com/bitcoin/bitcoin/pull/9465
 66 2017-01-04 09:10:08	0|gmaxwell|wumpus: I'm glad I wasn't the only person who thought it was already the case.
 67 2017-01-04 09:10:32	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #9467: [Trivial] [Doc] Install Protobuf v3 on OS X (06master...06osx-protobuf-doc) 02https://github.com/bitcoin/bitcoin/pull/9467
 68 2017-01-04 09:10:48	0|gmaxwell|only noticed it wasn't when I went to decrement the fee when we found we needed less than we expected and found I couldn't because the transaction was already signed.
 69 2017-01-04 09:10:49	0|wumpus|gmaxwell: I thought that was exactly why the dummy signer was introduced, but apparently not
 70 2017-01-04 09:11:25	0|gmaxwell|I ... think there was a miscommunication when it was proposed that a dummy signer be used there. :P
 71 2017-01-04 09:12:12	0|gmaxwell|As in someone thought that it was only needed for the fundrawtransaction case. :P
 72 2017-01-04 09:12:13	0|wumpus|probably
 73 2017-01-04 09:12:27	0|wumpus|ohh, so that's why it was introduced. Yes I remember now
 74 2017-01-04 09:12:54	0|wumpus|anyhow using it for normal transaction generation makes a lot of sense
 75 2017-01-04 09:13:18	0|gmaxwell|should be a lot faster in some cases.
 76 2017-01-04 09:13:31	0|gmaxwell|but also lets us do more sensible things with fees.
 77 2017-01-04 09:23:25	0|jonasschnelli|We could remove the "real" signing from CreateTransaction and factor out SignTransaction (from signrawtx) and use everywhere Create/Fund/Sign.
 78 2017-01-04 09:23:41	0|jonasschnelli|(everywhere internally)
 79 2017-01-04 09:23:51	0|jonasschnelli|Qt / sendtoaddr / sendmany
 80 2017-01-04 09:24:57	0|jonasschnelli|Ah. Just saw. #9465
 81 2017-01-04 09:24:59	0|gribble|https://github.com/bitcoin/bitcoin/issues/9465 | [Wallet] Do not perform ECDSA signing in the fee calculation inner loop. by gmaxwell · Pull Request #9465 · bitcoin/bitcoin · GitHub
 82 2017-01-04 09:40:03	0|fanquake|Is libevent 2.1.7 actually a release candidate, or just new beta version? Maybe a chance for a new release in the next few months.
 83 2017-01-04 09:40:48	0|fanquake|wumpus would you be opposed to moving depends to the latest libevent beta (which it is pre 0.14) for the 0.14 release?
 84 2017-01-04 09:41:53	0|fanquake|Just looking through dependancies now. Qt is another one to consider. 5.7 has had a point release, so should be more stable.
 85 2017-01-04 09:42:30	0|cfields|fanquake: speaking of, I know I owe you a bunch of review/acks on depends PRs. Been rushing to get net stuff finished up. I'll find some time this week to go through those.
 86 2017-01-04 09:43:53	0|fanquake|cfields no worries. I've just fixed-up the Zero-MQ one. Was going to open a more general depends related one tonight/tomorrow. Are you working on anything there that might conflict?
 87 2017-01-04 09:45:14	0|cfields|fanquake: no, only qt would conflict. I have a halfway-rewritten .mk to take advantage of some of the new build features for 5.7. But iirc we can bump without that and save it for 5.8 if needed.
 88 2017-01-04 09:46:12	0|cfields|er, that should say halfway-done rewrite
 89 2017-01-04 09:47:38	0|fanquake|cfields cool. I'll get these changes finished up and PR. Are we at all confident of dropping Boost for 0.14.0? Otherwise is a 1.61.0 -> 1.63.0 bump worth it in the interim?
 90 2017-01-04 09:48:39	0|cfields|fanquake: yea, not going to make it for 0.14. The changes are no fun to review, so it tends to go slowly
 91 2017-01-04 09:51:47	0|fanquake|cfields fair enough, it's a long slog. You're doing great work though. :)
 92 2017-01-04 09:53:09	0|cfields|heh, thanks
 93 2017-01-04 10:21:53	0|wumpus|fanquake: no, I'd propose the same
 94 2017-01-04 10:22:10	0|wumpus|fanquake: the libevent beta is *lots* better than the last stable, lots of fixes and new features
 95 2017-01-04 10:23:06	0|fanquake|wumpus: Great, i'll work on some changes for that as well.
 96 2017-01-04 10:25:49	0|wumpus|IIRC also means a windows-specific patch is no longer necesary
 97 2017-01-04 10:26:26	0|fanquake|Yes, I think there is the possibility to drop some workarounds as well.
 98 2017-01-04 10:26:37	0|fanquake|Yea #8867
 99 2017-01-04 10:26:38	0|gribble|https://github.com/bitcoin/bitcoin/issues/8867 | Move to Libevent 2.1.x · Issue #8867 · bitcoin/bitcoin · GitHub
100 2017-01-04 11:09:49	0|bitcoin-git|13bitcoin/06master 1427765b6 15isle2983: Increment MIT Licence copyright header year on files modified in 2016...
101 2017-01-04 11:09:49	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/649cf5fe894b...c0ddd32bf629
102 2017-01-04 11:09:50	0|bitcoin-git|13bitcoin/06master 14c0ddd32 15Wladimir J. van der Laan: Merge #9450: Increment MIT licence copyright header year on files modified in 2016...
103 2017-01-04 11:10:06	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9450: Increment MIT licence copyright header year on files modified in 2016 (06master...06PR-increment-year) 02https://github.com/bitcoin/bitcoin/pull/9450
104 2017-01-04 11:22:19	0|bitcoin-git|13bitcoin/06master 147325b15 15Cory Fields: net: a few small cleanups before replacing boost threads...
105 2017-01-04 11:22:19	0|bitcoin-git|[13bitcoin] 15laanwj pushed 8 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c0ddd32bf629...d9ae1cefa081
106 2017-01-04 11:22:20	0|bitcoin-git|13bitcoin/06master 14799df91 15Cory Fields: net: add CThreadInterrupt and InterruptibleSleep
107 2017-01-04 11:22:21	0|bitcoin-git|13bitcoin/06master 140985052 15Cory Fields: net: make net interruptible...
108 2017-01-04 11:22:30	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9289: net: drop boost::thread_group (06master...06connman-threads) 02https://github.com/bitcoin/bitcoin/pull/9289
109 2017-01-04 11:23:32	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d9ae1cefa081...869781c51cc1
110 2017-01-04 11:23:33	0|bitcoin-git|13bitcoin/06master 1462607d7 15Pieter Wuille: Convert COrphanTx to keep a CTransactionRef
111 2017-01-04 11:23:33	0|bitcoin-git|13bitcoin/06master 14c44e4c4 15Pieter Wuille: Make AcceptToMemoryPool take CTransactionRef
112 2017-01-04 11:23:34	0|bitcoin-git|13bitcoin/06master 146713f0f 15Pieter Wuille: Make FillBlock consume txn_available to avoid shared_ptr copies
113 2017-01-04 11:23:44	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9283: A few more CTransactionRef optimizations (06master...06sharedblock2) 02https://github.com/bitcoin/bitcoin/pull/9283
114 2017-01-04 11:34:22	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/869781c51cc1...1ce7ede2a9df
115 2017-01-04 11:34:23	0|bitcoin-git|13bitcoin/06master 14eab8e1b 15Alex Morcos: fix a bug if the min fee is 0 for FeeFilterRounder
116 2017-01-04 11:34:23	0|bitcoin-git|13bitcoin/06master 14f8d43b8 15Alex Morcos: Avoid rollingMinimumFeeRate never being able to decay below half
117 2017-01-04 11:34:24	0|bitcoin-git|13bitcoin/06master 141ce7ede 15Wladimir J. van der Laan: Merge #9288: Fix a bug if the min fee is 0 for FeeFilterRounder...
118 2017-01-04 11:34:31	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9288: Fix a bug if the min fee is 0 for FeeFilterRounder (06master...06fixFFRbug) 02https://github.com/bitcoin/bitcoin/pull/9288
119 2017-01-04 11:48:20	0|bitcoin-git|13bitcoin/06master 143f67972 15accraze: updated listsinceblock rpc docs...
120 2017-01-04 11:48:20	0|bitcoin-git|13bitcoin/06master 14d65a13b 15Wladimir J. van der Laan: Merge #9396: Updated listsinceblock rpc documentation...
121 2017-01-04 11:48:20	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1ce7ede2a9df...d65a13b773f8
122 2017-01-04 11:48:37	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9396: Updated listsinceblock rpc documentation (06master...06docs-listsinceblock-rpc) 02https://github.com/bitcoin/bitcoin/pull/9396
123 2017-01-04 12:01:34	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d65a13b773f8...c2ea1e6561ca
124 2017-01-04 12:01:35	0|bitcoin-git|13bitcoin/06master 140513c70 15Gregory Sanders: Make rpcauth help message clearer, add example in example .conf
125 2017-01-04 12:01:35	0|bitcoin-git|13bitcoin/06master 14c2ea1e6 15MarcoFalke: Merge #9401: Make rpcauth help message clearer, add example in example .conf...
126 2017-01-04 12:01:47	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9401: Make rpcauth help message clearer, add example in example .conf (06master...06rpcauthnotes) 02https://github.com/bitcoin/bitcoin/pull/9401
127 2017-01-04 12:46:51	0|bitcoin-git|13bitcoin/06master 1435ee63c 15fanquake: [Doc] Install Protobuf v3 on OS X
128 2017-01-04 12:46:51	0|bitcoin-git|13bitcoin/06master 145bc3b6c 15MarcoFalke: Merge #9467: [Trivial] [Doc] Install Protobuf v3 on OS X...
129 2017-01-04 12:46:51	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c2ea1e6561ca...5bc3b6cede8d
130 2017-01-04 12:47:07	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9467: [Trivial] [Doc] Install Protobuf v3 on OS X (06master...06osx-protobuf-doc) 02https://github.com/bitcoin/bitcoin/pull/9467
131 2017-01-04 13:15:17	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #9468: [WIP][Depends] Dependancy updates for 0.14.0 (06master...06depends-update-014) 02https://github.com/bitcoin/bitcoin/pull/9468
132 2017-01-04 13:28:32	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #9469: [WIP][depends] Qt 5.7.1 (06master...06depends-0-14-0-qt) 02https://github.com/bitcoin/bitcoin/pull/9469
133 2017-01-04 13:37:29	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9470: qt: Set (count) placeholder in sendcoinsdialog to notranslate (06master...062017_01_more_translate_fixes) 02https://github.com/bitcoin/bitcoin/pull/9470
134 2017-01-04 13:43:06	0|fanquake|jonasschnelli What's your guess?
135 2017-01-04 13:43:13	0|jonasschnelli|No idea. :)
136 2017-01-04 13:43:21	0|jonasschnelli|I guess around 30 per day
137 2017-01-04 13:44:41	0|jonasschnelli|I though about counting words per comment,... but due to code/log copy and paste, etc., this is not really representative
138 2017-01-04 13:45:41	0|fanquake|I was going to say far less than that, maybe between 3000-5000 comments total. However now I think about it, some days I'd easily see > 30 emails from bitcoin/bitcoin heh
139 2017-01-04 13:46:03	0|fanquake|Depends how many people you have blocked :p
140 2017-01-04 13:47:15	0|MarcoFalke|Huh, you can block comments from specific people?
141 2017-01-04 13:48:02	0|fanquake|I don't think so, just block the entire user. So you won't see any PRs/comments etc
142 2017-01-04 13:48:43	0|MarcoFalke|hmm, interesting. Luckily we don't have returning spammers.
143 2017-01-04 13:50:15	0|fanquake|One thing I had been considering was going back through some ancient issues/PRs, and "locking" the conversation. That would at least stop the random comments/replies on some.
144 2017-01-04 14:00:59	0|fanquake|wumpus looks like we can drop both libevent patches
145 2017-01-04 14:08:38	0|sipa|jonasschnelli: isn't easier through the json interface?
146 2017-01-04 14:09:13	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #9471: [WIP][depends] libevent 2.1.7rc (06master...06depends-0-14-0-libevent) 02https://github.com/bitcoin/bitcoin/pull/9471
147 2017-01-04 14:09:21	0|jonasschnelli|sipa: last time I checked there where some limits and not all data was available
148 2017-01-04 14:13:29	0|jonasschnelli|sipa: I guess the main problem is: curl https://api.github.com/rate_limit
149 2017-01-04 14:13:53	0|jonasschnelli|Maybe I need to a sleep(100) and run it over night
150 2017-01-04 14:14:09	0|jonasschnelli|I mean, not I need a sleep(100), the script.
151 2017-01-04 14:19:03	0|jonasschnelli|Ah. Found the reason why I didn't used the API: "Requests that return multiple items will be paginated to 30 items by default."
152 2017-01-04 14:20:19	0|bitcoin-git|13bitcoin/06master 14388ea19 15Wladimir J. van der Laan: qt: Set (count) placeholder in sendcoinsdialog to notranslate
153 2017-01-04 14:20:19	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5bc3b6cede8d...df1ab5b4d67b
154 2017-01-04 14:20:20	0|bitcoin-git|13bitcoin/06master 14df1ab5b 15MarcoFalke: Merge #9470: qt: Set (count) placeholder in sendcoinsdialog to notranslate...
155 2017-01-04 14:20:33	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9470: qt: Set (count) placeholder in sendcoinsdialog to notranslate (06master...062017_01_more_translate_fixes) 02https://github.com/bitcoin/bitcoin/pull/9470
156 2017-01-04 14:50:39	0|luke-jr|https://www.reddit.com/r/Bitcoin/comments/5ltw5n/bitcoin_core_v0131_sends_enormously_high_fee/ seems to not be an isolated case
157 2017-01-04 14:54:24	0|MarcoFalke|jonasschnelli: I think there is already a repo with all the github comments to Bitcoin Core. (Including history for each comment)
158 2017-01-04 14:54:46	0|MarcoFalke|But I can't find the link. I think someone mentioned it last year in Zürich
159 2017-01-04 14:54:50	0|jonasschnelli|Yes. I remember that. Is it up to date? I can't recall the URL though
160 2017-01-04 14:56:39	0|jonasschnelli|A html dump is always a good thing. Also, parsing auto-generated-html is simple and a good regex exercise. :)
161 2017-01-04 14:56:58	0|luke-jr|a markdown dump would be better *hides*
162 2017-01-04 14:59:19	0|jonasschnelli|luke-jr: Yeah. But does Github offers a md dump? I don't think so.
163 2017-01-04 14:59:31	0|rabidus_|http://bitcoinfees.21.co shows that there are plenty of more those 421-450 satoshi/byte transactions. Maybe related to that bug?
164 2017-01-04 15:01:39	0|MarcoFalke|kanzure: ^ Might know the url to the repo. :)
165 2017-01-04 15:02:02	0|kanzure|actually no, i'd like to know that repo as well
166 2017-01-04 15:02:17	0|MarcoFalke|How come no one ever reported that wallet fee bug?
167 2017-01-04 15:03:31	0|kanzure|(i've also never heard of it.)
168 2017-01-04 15:05:21	0|luke-jr|jonasschnelli: there must be some way, since the AJAX gets it for comment editing
169 2017-01-04 15:07:05	0|kanzure|or email inbox receiving all comments
170 2017-01-04 15:07:32	0|kanzure|which is better because you have even deleted comments (which, ahem, has happened to btcdrak and others)
171 2017-01-04 15:13:38	0|jtimon|jonasschnelli: I just realized I never understood your proposal for the spv mode in bitcoin core (or maybe I'm missing something about bloom filter based implementations of SPV)
172 2017-01-04 15:14:00	0|jonasschnelli|jtimon: It's simple.
173 2017-01-04 15:14:08	0|jtimon|you said that this is better for privacy because it will download full blocks, which makes sense to me
174 2017-01-04 15:14:26	0|jonasschnelli|Just download blocks, scan transactions, if relevant to the wallet, mark them a fSPV=true
175 2017-01-04 15:14:26	0|jtimon|but how do you know which blocks you want to download?
176 2017-01-04 15:14:32	0|jonasschnelli|Just all of them!
177 2017-01-04 15:14:44	0|jonasschnelli|But not deeper then your wallet birthday.
178 2017-01-04 15:15:09	0|jonasschnelli|If you start a fresh bitcoin-qt/d, you download only a couple of blocks and can start using Core with SPV
179 2017-01-04 15:15:10	0|jtimon|mhmm, you download all blocks without validating them?
180 2017-01-04 15:15:29	0|jonasschnelli|jtimon: You have to do that anyways
181 2017-01-04 15:15:33	0|jonasschnelli|(if you want a full node)
182 2017-01-04 15:15:38	0|jtimon|ok, I get now, thanks
183 2017-01-04 15:15:50	0|jonasschnelli|Just download the relevant blocks first, don't validate and use them for SPV
184 2017-01-04 15:16:22	0|jonasschnelli|As soon as we have block-bloom-filters, we can find out which of the blocks are relevant to the wallet (2nd step)
185 2017-01-04 15:18:13	0|MarcoFalke|kanzure: jonasschnelli: If it is on the web, you can find it: https://github.com/zw/bitcoin-gh-meta
186 2017-01-04 15:18:20	0|jonasschnelli|MarcoFalke: thanks.
187 2017-01-04 15:18:57	0|jonasschnelli|jtimon: If your node is out-of-sync for a week, you need to catch up 144*7 blocks = ~1GB data, ... .maybe 30min.
188 2017-01-04 15:19:36	0|jonasschnelli|and the download blocks are kept for the later full-validation
189 2017-01-04 15:20:28	0|jtimon|thanks again, it was the "download all blocks from wallet creation" part that I was missing
190 2017-01-04 15:25:56	0|kanzure|MarcoFalke: thank you. i've now timestamped that repository as of 38ff87cb68592ca19b10803908cf3d1bf0320bf7 :D.
191 2017-01-04 15:29:18	0|kanzure|we should probably ask whoever maintains that to do some automatic timestamping (petertodd made a git compatibility tool)
192 2017-01-04 15:42:10	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/df1ab5b4d67b...123ea7362478
193 2017-01-04 15:42:11	0|bitcoin-git|13bitcoin/06master 14facf3e7 15MarcoFalke: [qt] `make translate`
194 2017-01-04 15:42:11	0|bitcoin-git|13bitcoin/06master 14fae26e8 15MarcoFalke: [qt] Add more sources to translate
195 2017-01-04 15:42:12	0|bitcoin-git|13bitcoin/06master 14123ea73 15Wladimir J. van der Laan: Merge #9457: [qt] Select more files for translation...
196 2017-01-04 15:42:30	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9457: [qt] Select more files for translation (06master...06Mf1701-qtTrans) 02https://github.com/bitcoin/bitcoin/pull/9457
197 2017-01-04 15:56:39	0|gmaxwell|morcos: RE #9167  I asked a question there and I think you may have answered me on IRC but I don't remember the reply.
198 2017-01-04 15:56:40	0|gribble|https://github.com/bitcoin/bitcoin/issues/9167 | IsAllFromMe by morcos · Pull Request #9167 · bitcoin/bitcoin · GitHub
199 2017-01-04 16:00:01	0|morcos|gmaxwell: yep, will copy conversation into PR
200 2017-01-04 16:01:35	0|luke-jr|gmaxwell: sigh, #9326 apparently breaks with LibreSSL
201 2017-01-04 16:01:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/9326 | Update for OpenSSL 1.1 API. by gmaxwell · Pull Request #9326 · bitcoin/bitcoin · GitHub
202 2017-01-04 16:05:56	0|gmaxwell|luke-jr: okay, well we don't support that.... And dark, I did test it with older OpenSSL.
203 2017-01-04 16:06:29	0|luke-jr|apparently LibreSSL claims to be OpenSSL >=1.1 for some stupid reason :/
204 2017-01-04 16:06:42	0|luke-jr|without supporting 1.1 APIs..
205 2017-01-04 16:07:20	0|gmaxwell|morcos: oh right, that was where I commented that we should track input values so fees could be computed accurately.
206 2017-01-04 16:07:51	0|morcos|ha, yes, i left out the rest of the conversation, because i figured that was a bigger change. sorry.
207 2017-01-04 16:08:05	0|gmaxwell|it was, I agree.
208 2017-01-04 16:08:19	0|luke-jr|libressl-2.5.0/include/openssl/opensslv.h:#define OPENSSL_VERSION_NUMBER  0x20000000L
209 2017-01-04 16:08:21	0|luke-jr|>_<
210 2017-01-04 16:10:58	0|timothy|luke-jr: cool
211 2017-01-04 16:11:16	0|gmaxwell|luke-jr: so it needs to be changed to a #if NEW_OPENSSL_API  and a #define NEW_OPENSSL_API that has a different version test for libressl and openssl?
212 2017-01-04 16:12:13	0|luke-jr|I guess so. I was just going to change it to http://bpaste.net/show/ac2c68d93576
213 2017-01-04 16:12:31	0|luke-jr|(getting some libressl user to test this before I open a PR)
214 2017-01-04 16:12:46	0|timothy|luke-jr: I think you should use something like have_func("CRYPTO_lock") || $defs.push("-DHAVE_OPENSSL_110_THREADING_API")
215 2017-01-04 16:13:09	0|timothy|check if CRYPTO_lock function exists instead of rely on OPENSSL_VERSION_NUMBER
216 2017-01-04 16:13:20	0|luke-jr|EVP_MD_CTX_new in this case
217 2017-01-04 16:13:42	0|luke-jr|I suppose that'd probably be more future-proof if LibreSSL then adds it
218 2017-01-04 16:18:47	0|luke-jr|someone here has an OpenSSL 1.1 system? Can you test http://bpaste.net/show/7565deaf5c48 ?
219 2017-01-04 16:20:19	0|luke-jr|(note re-running autogen.sh is needed)
220 2017-01-04 16:22:02	0|timothy|luke-jr: give me 2 minutes
221 2017-01-04 16:24:38	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #9472: Disentangle progress estimationc from heckpoints and update it (06master...06update_tx_estimation) 02https://github.com/bitcoin/bitcoin/pull/9472
222 2017-01-04 16:40:19	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #9474: Mark the minconf parameter to move as ignored (06master...06stale_minconf_parameter) 02https://github.com/bitcoin/bitcoin/pull/9474
223 2017-01-04 16:41:14	0|timothy|luke-jr: you have to use AC_CHECK_FUNCS instead
224 2017-01-04 16:47:13	0|luke-jr|timothy: does this work any better? http://bpaste.net/show/b0c01efeceb6
225 2017-01-04 16:49:05	0|timothy|AC_CHECK_DECLS is wrong
226 2017-01-04 16:49:30	0|timothy|wait
227 2017-01-04 16:49:57	0|gmaxwell|luke-jr: patch does not work on openssl 1.1
228 2017-01-04 16:51:22	0|gmaxwell|HAVE_DECL_EVP_MD_CTX_NEW isn't getting set.
229 2017-01-04 16:54:32	0|timothy|setting CFLAGS is useless since it's using g++
230 2017-01-04 16:55:25	0|luke-jr|hmm
231 2017-01-04 16:55:43	0|timothy|configure:29569: g++ -c -g -O2 -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS conftest.cpp >&5
232 2017-01-04 16:57:12	0|timothy|gmaxwell: do you have the same behaviour?
233 2017-01-04 17:02:13	0|luke-jr|ok, tested http://bpaste.net/show/5acc82591b69 with a non-installed OpenSSL 1.1 build, should work finally
234 2017-01-04 17:03:48	0|timothy|+CXXFLAGS="${CFLAGS} ${SSL_CFLAGS}"
235 2017-01-04 17:03:50	0|timothy|typo
236 2017-01-04 17:04:03	0|timothy|CXXFLAGS+"${CXXFLAGS} ${SSL_CFLAGS}" imho
237 2017-01-04 17:04:10	0|timothy|CXXFLAGS=
238 2017-01-04 17:05:17	0|luke-jr|oops good catch
239 2017-01-04 17:06:13	0|timothy|since SSL_CXXFLAGS doesn't exists, SSL_CFLAGS is ok
240 2017-01-04 17:06:50	0|gmaxwell|that (fixed version of luke's patch) compiles for me.
241 2017-01-04 17:07:10	0|timothy|for me too
242 2017-01-04 17:08:43	0|luke-jr|thanks
243 2017-01-04 17:08:50	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #9475: Let autoconf detect presence of EVP_MD_CTX_new (06master...06EVP_MD_CTX_new) 02https://github.com/bitcoin/bitcoin/pull/9475
244 2017-01-04 17:16:46	0|timothy|luke-jr: why don't you use  #include <openssl/evp.h> (https://www.openssl.org/docs/manmaster/man3/EVP_MD_CTX_new.html) ?
245 2017-01-04 17:18:02	0|luke-jr|timothy: the actual code doesn't.
246 2017-01-04 17:18:24	0|luke-jr|figure less hiccups if the check and code are closer aligned
247 2017-01-04 17:21:20	0|timothy|luke-jr: on openssl 1.1  you have openssl/evp.h
248 2017-01-04 17:22:00	0|luke-jr|x509_vfy.h includes evp.h, and Core's code only includes x509_vfy.h
249 2017-01-04 17:26:20	0|jtimon|how realistic it is to hope to get https://github.com/bitcoin/bitcoin/pull/8994 merged for 0.14 ?
250 2017-01-04 17:27:23	0|jtimon|what is it missing? as said in a comment, segwit.py and p2p-compactblocks.py still need to run with self.chain = "regtest" instead of self.chain = "custom". But perhaps that's ok?
251 2017-01-04 17:37:22	0|jtimon|maybe a new rpc test changing some chainparams values?
252 2017-01-04 17:50:19	0|MarcoFalke|cfields: Any guess why #9416 causes a undefined reference to `qInitResources_bitcoin()'?
253 2017-01-04 17:50:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/9416 | travis: make distdir before make by MarcoFalke · Pull Request #9416 · bitcoin/bitcoin · GitHub
254 2017-01-04 18:20:39	0|paveljanik|MarcoFalke, https://travis-ci.org/bitcoin/bitcoin/jobs/187303535#L1939
255 2017-01-04 18:20:48	0|paveljanik|Cannot find file 'res/movies/spinner-000.png'
256 2017-01-04 18:21:28	0|paveljanik|strange 8)
257 2017-01-04 18:24:29	0|Chris_Stewart_5|Just to be clear, there are public keys in the blockchain that do not pass the `IsCompressedOrUncompressedPubKey` check right? This is enforced as policy right?
258 2017-01-04 18:28:44	0|sipa|there may be
259 2017-01-04 18:28:45	0|sipa|i'm not sure
260 2017-01-04 18:28:47	0|bitcoin-git|[13bitcoin] 15instagibbs closed pull request #8992: Enable pubkey lookup for p2sh-p2wpkh in validateaddress (06master...06validatep2pkh) 02https://github.com/bitcoin/bitcoin/pull/8992
261 2017-01-04 18:28:59	0|sipa|there certainly are in testnet
262 2017-01-04 18:29:18	0|Chris_Stewart_5|sipa: Is there a BIP that was proposed that check?
263 2017-01-04 18:31:03	0|sipa|not afaik
264 2017-01-04 18:38:46	0|cfields|MarcoFalke: hmm, sounds like something's legitimately not getting included
265 2017-01-04 18:39:13	0|MarcoFalke|paveljanik had a hint. Let me try to solve the wildcard
266 2017-01-04 18:40:06	0|cfields|MarcoFalke: ah, missed that
267 2017-01-04 18:45:49	0|cfields|MarcoFalke: hmm, it's been a while, but i'm assuming that I somehow missed the other qrc in fc4ad0c7fcf2e5841756c9d1003f95c879ee5cd2
268 2017-01-04 18:48:03	0|Chris_Stewart_5|sipa: We don't have a more general public key check do we? For instance, a valid public key encoding that encompasses all encodings that are valid in openssl?
269 2017-01-04 18:48:13	0|cfields|MarcoFalke: so.. http://pastebin.com/raw/xYXmu8Jk
270 2017-01-04 18:48:22	0|MarcoFalke|cfields: Could be but when this is the cause, I don't understand why travis didn't fail back then: https://github.com/bitcoin/bitcoin/blob/fc4ad0c7fcf2e5841756c9d1003f95c879ee5cd2/.travis.yml#L76
271 2017-01-04 18:49:00	0|sipa|Chris_Stewart_5: CPubKey::IsFullyValid()
272 2017-01-04 18:49:10	0|sipa|(which is implemented in libsecp256k1)
273 2017-01-04 18:49:19	0|Chris_Stewart_5|Thank you!
274 2017-01-04 18:50:08	0|cfields|MarcoFalke: unsure. The above is just a guess. I need to catch a flight, I'll catch up on irc logs later
275 2017-01-04 18:50:27	0|MarcoFalke|sure, will try your patch
276 2017-01-04 18:50:30	0|gmaxwell|sipa: I'm doubtful that SIGCHECK_VERIFICATION_FACTOR is correct anymore except on really slow computers, fwiw.
277 2017-01-04 18:50:44	0|cfields|MarcoFalke: heh, that came off as very rude. Wasn't intentional :)
278 2017-01-04 18:50:52	0|sipa|gmaxwell: willing to change it based on HARD DATA
279 2017-01-04 18:51:04	0|MarcoFalke|cfields: I didn't read any rudeness. :P
280 2017-01-04 18:51:14	0|gmaxwell|'HARD DATA, Soft forks.'
281 2017-01-04 18:51:28	0|sipa|gmaxwell: though, it's probably better to overshoot than undershoot
282 2017-01-04 18:51:37	0|sipa|(seeing a progress bar speed up over time is nice)
283 2017-01-04 18:51:53	0|Chris_Stewart_5|/r/oddlysatisfying
284 2017-01-04 18:52:15	0|gmaxwell|jeremyrubin: did you ever explore having a simple bypass of the signature cache when validating blocks far from the best header, to reduce lock contention during IBD?
285 2017-01-04 18:52:24	0|sipa|gmaxwell: oops
286 2017-01-04 18:52:30	0|sipa|my code is wrong
287 2017-01-04 18:52:47	0|sipa|it assumes no signature checks up to the timestamp given
288 2017-01-04 18:57:40	0|Chris_Stewart_5|sipa: I did not realize libsecp256k1 had java bindings in the repo, nice!
289 2017-01-04 18:58:10	0|gmaxwell|they might even work!
290 2017-01-04 18:58:31	0|sipa|gmaxwell: they have unit tests!
291 2017-01-04 18:58:58	0|Chris_Stewart_5|assert(true == true, "true")
292 2017-01-04 19:00:12	0|sipa|gmaxwell: jeremyrubin: did you ever explore having a simple bypass of the signature cache   ->   you can't do that at the sigcache level, as there may be CHECKSIG NOTs in the chain
293 2017-01-04 19:01:21	0|gmaxwell|sipa: hm? just treat it as there being nothing in the cache for the whole block.
294 2017-01-04 19:01:37	0|sipa|Ah
295 2017-01-04 19:01:38	0|sipa|nvm
296 2017-01-04 19:01:44	0|gmaxwell|which there won't be, in ibd.
297 2017-01-04 19:02:23	0|jtimon|btw gmaxwell did you stop working on your patch to get rid of Checkpoints::GetLastCheckpoint() ? it looked quite advanced a while ago
298 2017-01-04 19:05:10	0|gmaxwell|We're really review starved right now.
299 2017-01-04 19:09:11	0|jtimon|I see
300 2017-01-04 19:09:31	0|jtimon|but you didn't open a PR, did you?
301 2017-01-04 19:10:06	0|jtimon|no, just looked
302 2017-01-04 19:10:19	0|jtimon|anyway, leaving now...
303 2017-01-04 19:18:34	0|MarcoFalke|cfields: Your patch works! Mind to create a pull for that some time after your flight?
304 2017-01-04 19:23:51	0|morcos|gmaxwell: re: 9465, it concerns me a little that DummySignatureCreator creates 72-byte signatures and not 73-byte signatures.  I realize most of the time its neglible, but it seems like it could just lead to bad edge cases.  It seems like we should always overpay instead.
305 2017-01-04 19:28:33	0|sipa|morcos: since low-S, the maximum is 72, i think
306 2017-01-04 19:28:37	0|sipa|and on average 71.5
307 2017-01-04 19:28:52	0|gmaxwell|darn sipa with the answer while I was off trying to confirm it. :)
308 2017-01-04 19:28:52	0|morcos|ah, missed that.. yeah i was caring about the maximum
309 2017-01-04 19:30:19	0|sipa|gmaxwell: of course, i also tried to confirm first :)
310 2017-01-04 19:30:37	0|morcos|out of curiousity, how were you confirming that
311 2017-01-04 19:30:44	0|sipa|32 bytes S, 33 bytes R, 6 bytes DER stupidity, 1 byte sighash
312 2017-01-04 19:31:05	0|sipa|is the maximum
313 2017-01-04 19:31:19	0|sipa|where R is 32 bytes 50% of the tie
314 2017-01-04 19:31:52	0|morcos|ok i thought you meant confirming S couldn't be more than 32 bytes, which seemed pretty obvious if i understood what low-S meant
315 2017-01-04 19:35:49	0|sipa|maybe we should grind by default to produce a 32-byte R as well
316 2017-01-04 19:35:51	0|sipa|:)
317 2017-01-04 19:36:07	0|sipa|would need 2 iterations on average
318 2017-01-04 19:38:06	0|gmaxwell|sipa: it could be done in constant time using the endomorphism, no?
319 2017-01-04 19:40:04	0|sipa|gmaxwell: oh, sure!
320 2017-01-04 19:40:15	0|sipa|the negation endomorphism, you mean?
321 2017-01-04 19:41:38	0|gmaxwell|negation doesn't change X, and it's used by low-S.  I mean multiply by lambda, potentially twice.
322 2017-01-04 19:43:03	0|sipa|is there a guarantee that that will always result in a R.x value in the lower range?
323 2017-01-04 19:49:48	0|bitcoin-git|13bitcoin/06master 14ffeb195 15Alex Morcos: add test for -walletrejectlongchains
324 2017-01-04 19:49:48	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/123ea7362478...0fc1c31a878e
325 2017-01-04 19:49:49	0|bitcoin-git|13bitcoin/06master 140fc1c31 15MarcoFalke: Merge #9395: Add test for -walletrejectlongchains...
326 2017-01-04 19:49:59	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9395: Add test for -walletrejectlongchains (06master...06fixmovedtx) 02https://github.com/bitcoin/bitcoin/pull/9395
327 2017-01-04 19:51:44	0|gmaxwell|sipa: thats why I asked, expirementally it's true bit it's not obvious to me how to prove it.
328 2017-01-04 19:53:07	0|gmaxwell|sipa: I tested for F(-1) to F(-100000) and in all case either *beta or *beta^2 results in a number less than 2**255
329 2017-01-04 19:53:34	0|gmaxwell|okay -1 to -1000000 now.
330 2017-01-04 19:55:29	0|gmaxwell|okay, theory disproved.
331 2017-01-04 19:56:42	0|bitcoin-git|13bitcoin/06master 14b50cd7a 15Alex Morcos: Fix dangerous condition in ModifyNewCoins....
332 2017-01-04 19:56:42	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0fc1c31a878e...7dac1e5e9e88
333 2017-01-04 19:56:43	0|bitcoin-git|13bitcoin/06master 147dac1e5 15Pieter Wuille: Merge #9107: Safer modify new coins...
334 2017-01-04 19:56:54	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9107: Safer modify new coins (06master...06saferModifyNewCoins) 02https://github.com/bitcoin/bitcoin/pull/9107
335 2017-01-04 19:58:48	0|gmaxwell|(it's only true 87% of the time, but happens to hold for all very large and very small field elements)
336 2017-01-04 20:32:54	0|dcousens|gmaxwell: RE https://github.com/bitcoin/bitcoin/issues/9463#issuecomment-270303374,  my point was for naming of the RPC calls
337 2017-01-04 20:33:39	0|dcousens|Wait, I've just realised I've mis-read what belcher meant, I read it as:   " bitcoin nodes known to your node via RPC."
338 2017-01-04 20:34:19	0|dcousens|as in,  RPC connections
339 2017-01-04 20:35:42	0|gmaxwell|dcousens: I thought you might have been misreading it that way, thus the question.
340 2017-01-04 20:36:06	0|dcousens|gmaxwell: cheers :)