1 2016-08-16 06:06:11	0|GitHub162|13bitcoin/06master 143897668 15CryptoVote: Adds issue template. [skip ci]
  2 2016-08-16 06:06:11	0|GitHub162|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6e5e5abba6f8...bbd9740f534f
  3 2016-08-16 06:06:12	0|GitHub162|13bitcoin/06master 14bbd9740 15Wladimir J. van der Laan: Merge #8058: [Doc] Add issue template...
  4 2016-08-16 06:06:17	0|GitHub125|[13bitcoin] 15laanwj closed pull request #8058: [Doc] Add issue template (06master...06docPRT) 02https://github.com/bitcoin/bitcoin/pull/8058
  5 2016-08-16 08:10:46	0|gmaxwell|I'm surprised no large miners are on 0.13rc yet.
  6 2016-08-16 08:11:06	0|gmaxwell|(I know none aren't because I watched dozens of blocks go by today without picking up some pretty high fee CPFP transactions)
  7 2016-08-16 08:57:15	0|Lightsword|gmaxwell, should I update to it in production?
  8 2016-08-16 08:59:42	0|gmaxwell|I think you should. As far as we know it's mature and stable. I've been mining on it since before the RCs and haven't seen any issues.  Obviously normal risks of new software apply, so you might want to keep a closer eye on it than normal.
  9 2016-08-16 09:00:42	0|Lightsword|gmaxwell, are there any config differences that changes since 0.13 that I should set?
 10 2016-08-16 09:01:47	0|gmaxwell|Some changes in the how block size limits are configured, mentioned in the release notes. I'm not recalling anything else that would be applicable to you, but I'll go through the release notes right now.
 11 2016-08-16 09:06:14	0|sipa|Lightsword: actually, comments on the release notes are pretty welcome
 12 2016-08-16 09:06:31	0|sipa|it's often hard to judge what is obvious and what is confusing to someone who hasn't followed all the changes in detail
 13 2016-08-16 09:19:41	0|GitHub169|[13bitcoin] 15sipa opened pull request #8519: [0.13] A few small improvements to the 0.13 release notes (060.13...06relnotes-0.13) 02https://github.com/bitcoin/bitcoin/pull/8519
 14 2016-08-16 09:20:43	0|GitHub58|[13bitcoin] 15laanwj opened pull request #8520: build: Remove check for `openssl/ec.h` (06master...062016_08_remove_openssl_ech_check) 02https://github.com/bitcoin/bitcoin/pull/8520
 15 2016-08-16 09:26:00	0|GitHub37|13bitcoin/06master 14edb6cf1 15instagibbs: remove no-longer-used InitError logic
 16 2016-08-16 09:26:00	0|GitHub37|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bbd9740f534f...2c2d471e18f0
 17 2016-08-16 09:26:01	0|GitHub37|13bitcoin/06master 142c2d471 15Wladimir J. van der Laan: Merge #8516: [trivial] remove no-longer-used InitError logic...
 18 2016-08-16 09:26:15	0|GitHub26|[13bitcoin] 15laanwj closed pull request #8516: [trivial] remove no-longer-used InitError logic (06master...06deadiniterr) 02https://github.com/bitcoin/bitcoin/pull/8516
 19 2016-08-16 09:31:31	0|Lightsword|sipa, one thing that might be handy is to have a list of all miner relevant config optimizations somewhere
 20 2016-08-16 09:34:24	0|Lightsword|gmaxwell, anything I might be missing here? https://gist.github.com/jameshilliard/ba6116f873066e794120e34f49ee5e63
 21 2016-08-16 09:35:19	0|sipa|bytespersigop=1 exposes you to an attack with high-sigops transactions
 22 2016-08-16 09:35:43	0|sipa|(but if that's ok for you, you can obviously set it, it doesn't hurt anyone else)
 23 2016-08-16 09:36:23	0|Lightsword|sipa, ugh…I have that because sendrawtransaction doesn’t have an option like this https://github.com/bitcoin/bitcoin/pull/7533
 24 2016-08-16 09:36:32	0|sipa|in 0.13 the meaning of bytespersigop changed; it doesn't cause rejection of transactions that exceed the bytes/sigop ratio; it merely requires a higher fee for them
 25 2016-08-16 09:36:50	0|Lightsword|oh
 26 2016-08-16 09:38:23	0|Lightsword|so I should be able to remove that and still send higher sigops transactions now?
 27 2016-08-16 09:38:41	0|sipa|yes; they'll just be treated as if they were larger
 28 2016-08-16 09:39:16	0|sipa|say a 200 byte transaction with 20 sigops... for fee and miner selection purposes it will be treated as if it was 400 bytes large
 29 2016-08-16 09:39:29	0|sipa|(the default is -bytespersigop=20)
 30 2016-08-16 09:40:01	0|sipa|may i ask why you need to send such transactions?
 31 2016-08-16 09:40:35	0|Lightsword|some transactions with OP_RETURN’s it seemed were throwing sigops errors when I tried sending them
 32 2016-08-16 09:41:20	0|Lightsword|they weren’t transactions I created, but was asked to mine for some company
 33 2016-08-16 09:41:21	0|sipa|OP_RETURN shouldn't affect that... rather the opposite
 34 2016-08-16 09:41:31	0|sipa|they increase the size without increasing sigops
 35 2016-08-16 09:41:50	0|sipa|anyway, ok
 36 2016-08-16 09:42:30	0|Lightsword|sipa, here’s an example https://blockchain.info/tx/5a3f68d824b75d2f659c545acbc395dc152b589264d301a40dd1d29858ed3c6a
 37 2016-08-16 09:42:49	0|sipa|ah, raw multisig
 38 2016-08-16 09:43:14	0|sipa|yes, that was the reason for changing the behaviour of -bytespersigop, because it accidentally killed some raw multisig transactions
 39 2016-08-16 09:43:44	0|Lightsword|ok, so I’ll remove that then
 40 2016-08-16 09:44:36	0|sipa|-enforcenodebloom was removed, it's always on now
 41 2016-08-16 09:44:57	0|Lightsword|ok, removed that as well
 42 2016-08-16 10:05:42	0|GitHub99|[13bitcoin] 15laanwj opened pull request #8521: qa: Remove duplicate `hash160` implementation (06master...062016_08_hash160_dupe) 02https://github.com/bitcoin/bitcoin/pull/8521
 43 2016-08-16 10:23:15	0|GitHub136|13bitcoin/060.13 147f84015 15Pieter Wuille: Inline mempool RPCs and feefilter into misc sections
 44 2016-08-16 10:23:15	0|GitHub136|13bitcoin/060.13 14fe20b83 15Pieter Wuille: Remove refactors from list of changes
 45 2016-08-16 10:23:15	0|GitHub136|[13bitcoin] 15laanwj pushed 4 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/b52c67c4b188...4374f0ee35f8
 46 2016-08-16 10:23:15	0|GitHub97|[13bitcoin] 15laanwj closed pull request #8519: [0.13] A few small improvements to the 0.13 release notes (060.13...06relnotes-0.13) 02https://github.com/bitcoin/bitcoin/pull/8519
 47 2016-08-16 10:23:16	0|GitHub136|13bitcoin/060.13 142f58589 15Pieter Wuille: Mention dump/import support for HD wallets
 48 2016-08-16 10:26:56	0|wumpus|it may help releasing 0.13.0, it makes sense for no one to mine (in a big operation) with an rc
 49 2016-08-16 10:27:22	0|sipa|wumpus: parse failure
 50 2016-08-16 10:27:45	0|wumpus|well I wouldn't use a rc to mine either
 51 2016-08-16 10:28:00	0|wumpus|and just wait for the release
 52 2016-08-16 10:28:37	0|sipa|well, me personally would like to see people from all parts of the ecosystem - including mingers - test the rc, to find potential problems with it
 53 2016-08-16 10:29:04	0|sipa|on the other hand, i can't really state "the rc is safe to mine with!", as that would imply it should be a release already
 54 2016-08-16 10:29:22	0|sipa|s/mingers/miners/
 55 2016-08-16 10:29:29	0|wumpus|maybe they tested on small scale
 56 2016-08-16 10:30:45	0|wumpus|"that would imply it should be a release already" maybe it should
 57 2016-08-16 10:31:07	0|sipa|a few days won't matter
 58 2016-08-16 10:31:23	0|wumpus|any reason to not tag rc3 as final right now?
 59 2016-08-16 10:32:18	0|sipa|i know of no problems
 60 2016-08-16 10:32:18	0|wumpus|it had almost no changes compared to rc2, so I don't think it needs as long testing as rc2
 61 2016-08-16 10:33:11	0|sipa|#8490 ?
 62 2016-08-16 10:34:08	0|wumpus|needs rebase
 63 2016-08-16 10:47:44	0|gmaxwell|Since, afaict, virtually no one in this space has reasonable qualification testing, if people don't mine on RCs we might as well not have them as far as mining is concerned.
 64 2016-08-16 10:48:42	0|sipa|#8518 worries me, but shouldn't affect mainnet in 0.13.0
 65 2016-08-16 10:56:43	0|gmaxwell|sipa: since there were segwit peers in his log that weren't disconnected, I don't see any reason to believe that it isn't just as it describes-- peers that were stalling the transfer.
 66 2016-08-16 10:58:31	0|sipa|ah
 67 2016-08-16 10:58:42	0|sipa|but it seems he is not making progress
 68 2016-08-16 10:59:36	0|sipa|i think it's due to having multiple potential chains on top of his current state
 69 2016-08-16 11:07:34	0|MarcoFalke|gmaxwell: the peers will come in and go after 2 seconds. I have the Debug window open and it looks like a fifo queue of peers.
 70 2016-08-16 11:08:30	0|MarcoFalke|Somewhat odd that no one reported similar problems, though.
 71 2016-08-16 11:28:36	0|MarcoFalke|Deleted peers.dat twice. On the first try it synced fine. On the second try I was back at the stalling problem.
 72 2016-08-16 11:30:13	0|MarcoFalke|Could it be that we are populating the fetch window with headers and then expect the 0.13 peer to deliver a block in 2 seconds?
 73 2016-08-16 12:33:09	0|sipa|NicolasDorier: 8295 used locks and a cachedhashesmap, no?
 74 2016-08-16 12:33:51	0|NicolasDorier|yes, my mistake
 75 2016-08-16 12:34:00	0|NicolasDorier|I checked your PR after, edited my comment
 76 2016-08-16 12:35:00	0|sipa|ah, i see
 77 2016-08-16 12:36:01	0|NicolasDorier|sipa: 8464 seems fine as well may make things easier as well for libconsensus stuff later
 78 2016-08-16 12:36:28	0|NicolasDorier|uh no
 79 2016-08-16 12:36:37	0|NicolasDorier|this one  https://github.com/sipa/bitcoin/commits/noprecomputecachedhashes
 80 2016-08-16 12:37:32	0|NicolasDorier|it is smaller diff as well
 81 2016-08-16 12:38:53	0|NicolasDorier|I'm fine for merging my PR, but also fine if you make a new PR and squash those two commits together, I think your implementation is simpler, more efficient and will make my life easier for libconsensus later.
 82 2016-08-16 12:44:14	0|NicolasDorier|sipa: yep, just reviewed it, now I would prefer you make a new PR which supersede mine with  https://github.com/sipa/bitcoin/commits/noprecomputecachedhashes, you can squash the two commits as well.
 83 2016-08-16 12:47:50	0|NicolasDorier|However I don't understand why  std::vector<std::unique_ptr<CachedHashes>> is needed and can't be  just std::vector<CachedHashes>. The CachedHashes have the same life time as the vector
 84 2016-08-16 12:48:12	0|sipa|NicolasDorier: resizing a vector changes the addresses
 85 2016-08-16 12:48:40	0|sipa|by using an unique_ptr for each element, the cavhedhashes don't move
 86 2016-08-16 12:48:54	0|sipa|ah
 87 2016-08-16 12:49:11	0|sipa|we could just resize the vector to have block.vtx.size() entries
 88 2016-08-16 12:50:35	0|NicolasDorier|sipa: well, in this case there is a bug in my PR ? I am using a map<uint256, CachedHashes>
 89 2016-08-16 12:50:45	0|NicolasDorier|ah no
 90 2016-08-16 12:50:49	0|NicolasDorier|I'm copying stuff
 91 2016-08-16 12:51:06	0|sipa|indeed, and you do the lookup every time again
 92 2016-08-16 12:51:11	0|sipa|i do it ahead of time
 93 2016-08-16 12:51:29	0|sipa|each CScriptCheck gets a pointer to the CachedHashes it uses
 94 2016-08-16 12:51:57	0|sipa|also, adding elements to a map does not invalidate pointers
 95 2016-08-16 12:52:16	0|NicolasDorier|it does not relocate the elements as the vector ?
 96 2016-08-16 12:52:22	0|sipa|indeed
 97 2016-08-16 12:53:52	0|NicolasDorier|I slightly prefer a resize followed by std::vector<CachedHashes> instead of using a unique_ptr. Anyway, whatever you choose let me know when you do the PR. Squash my commit, I don't really care, easier to review.
 98 2016-08-16 12:54:31	0|sipa|yes, i agree; reserve + no unique_ptr is better
 99 2016-08-16 12:59:06	0|NicolasDorier|sipa: Just a reminder, you were mentionning that you were OK with a HashCacheMap because it would be useful for later. I did not really followed why (something with signature aggregation if I remember), that's just reminder.
100 2016-08-16 12:59:56	0|sipa|NicolasDorier: yes, that's why i'm not strongly in favor of my own solution :)
101 2016-08-16 13:00:05	0|sipa|we'll need something like this anyway
102 2016-08-16 13:00:11	0|NicolasDorier|mmh
103 2016-08-16 13:00:36	0|sipa|doesn't mean we can't use this now
104 2016-08-16 13:01:41	0|NicolasDorier|well, whichever is fine for me.  I still don't see far enough to see how the HashCacheMap will be useful, as how the signature aggregation will be implemented is still blurry in my mind. Both of them are fine to me, if you do a PR, will test and ACK as well.
105 2016-08-16 13:02:54	0|sipa|not HashCachedMap itself; but some mutable data structure that individual script checks can modify
106 2016-08-16 13:03:56	0|NicolasDorier|if so I think it is better to do it later with another class specially for that like a "TransactionContext" or something like that
107 2016-08-16 13:04:32	0|NicolasDorier|not a big deal to code when it will be needed
108 2016-08-16 13:15:23	0|GitHub76|[13bitcoin] 15sipa opened pull request #8524: Precompute sighashes (06master...06noprecomputecachedhashes) 02https://github.com/bitcoin/bitcoin/pull/8524
109 2016-08-16 13:16:54	0|sipa|NicolasDorier: i left you as author since you still wrote most of the code
110 2016-08-16 13:33:30	0|NicolasDorier|as you want, but well, except the big_transaction tests nothing will be really left in reality :D
111 2016-08-16 13:33:56	0|sipa|the tests are important :)
112 2016-08-16 13:38:36	0|sipa|NicolasDorier: split the commit into 2
113 2016-08-16 13:38:38	0|sipa|better now?
114 2016-08-16 13:39:08	0|NicolasDorier|why splitting ?
115 2016-08-16 13:39:24	0|NicolasDorier|ah you mean make a separate commit for the test only ?
116 2016-08-16 13:39:55	0|NicolasDorier|as you want, I don't really mind
117 2016-08-16 14:48:56	0|sipa|it seems that the only versions on the network that would relay invalid witness txn are 0.10.x
118 2016-08-16 14:49:14	0|sipa|<=0.9 would not, due to nonstandard script
119 2016-08-16 14:49:23	0|sipa|>=0.11 would not, due to CLEANSTACK rule
120 2016-08-16 14:50:08	0|sipa|given that, could we just not bother with the double validation for witness txn, and special rules about not DoS scoring invalid witness txn for non-witness peers?
121 2016-08-16 15:42:54	0|GitHub8|[13bitcoin] 15sipa opened pull request #8525: Do not store witness txn in rejection cache (06master...06nowitnessreject) 02https://github.com/bitcoin/bitcoin/pull/8525
122 2016-08-16 15:51:49	0|GitHub50|[13bitcoin] 15jl2012 opened pull request #8526: Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH (06master...06minimalif) 02https://github.com/bitcoin/bitcoin/pull/8526
123 2016-08-16 16:03:00	0|GitHub26|[13bitcoin] 15sipa opened pull request #8527: Take minRelayTxFee into account in FEEFILTER messages (06master...06clampfeefilter) 02https://github.com/bitcoin/bitcoin/pull/8527
124 2016-08-16 17:04:32	0|kanzure|jonasschnelli: re: peer authentication bip, https://github.com/jonasschnelli/bips/pull/1
125 2016-08-16 17:25:53	0|Chris_Stewart_5|sipa: Is the hash type included in the DER signature 'total size' of the signature?
126 2016-08-16 17:27:53	0|arubi|Chris_Stewart_5, are you asking about the second byte after 0x30, or about IsValidSignatureEncoding() ?  if former, no, if latter, yes
127 2016-08-16 17:28:48	0|sipa|what arubi said
128 2016-08-16 17:29:23	0|Chris_Stewart_5|arubi: That was exactly what i was asking about. Thanks :-)
129 2016-08-16 17:31:29	0|sipa|Chris_Stewart_5: the sighash type is something bitcoin specific
130 2016-08-16 17:31:44	0|sipa|so it's not part of the DER standard for encoding ECDSA signatures
131 2016-08-16 17:31:57	0|sipa|and the length part is from DER
132 2016-08-16 17:32:15	0|arubi|yw Chris_Stewart_5 :)
133 2016-08-16 17:33:53	0|Chris_Stewart_5|Yeah -- I was conflating the two.
134 2016-08-16 18:10:08	0|Chris_Stewart_5|Is this the function that was used to check encoding pre BIP66?
135 2016-08-16 18:10:11	0|Chris_Stewart_5|https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L185
136 2016-08-16 18:14:49	0|sipa|Chris_Stewart_5: also post BIP66
137 2016-08-16 18:25:22	0|instagibbs|sdaftuar, this comment refering to the reject filter? https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/p2p-segwit.py#L949
138 2016-08-16 18:28:48	0|sipa|instagibbs: i assume it is about the askfor logic
139 2016-08-16 18:28:51	0|sipa|which retries
140 2016-08-16 18:31:42	0|instagibbs|an announcement the second time works just fine on my end
141 2016-08-16 19:11:24	0|GitHub92|[13bitcoin] 15instagibbs opened pull request #8528: Update p2p-segwit.py to reflect correct AskFor behavior (06master...06rejectsw) 02https://github.com/bitcoin/bitcoin/pull/8528
142 2016-08-16 19:42:00	0|instagibbs|this is referring to the reject filter, right? https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/p2p-segwit.py#L294
143 2016-08-16 19:42:34	0|instagibbs|I'm trying to make an example of the segwit DoS issue, and found a case that I think should be catching it but isn't
144 2016-08-16 19:42:44	0|instagibbs|(to my reading anyways)