1 2017-12-20 00:14:51	0|promag|jonasschnelli: is it possible to know if a rescan is in progress?
  2 2017-12-20 00:25:35	0|midnightmagic|good heavens, lots of new sigs in the gitian.sigs repo.
  3 2017-12-20 00:26:06	0|luke-jr|sipa: jonasschnelli: FWIW, my test had chainstate on a 5400 RPM drive with btrfs+compression (no encryption); i7-4771 CPU
  4 2017-12-20 00:26:54	0|phantomcircuit|gmaxwell, expiration is keeping the relay fee from going up?
  5 2017-12-20 00:27:21	0|luke-jr|short of the compression, I think that's about the worst-possible disk scenario (although it may be all cached in RAM..)
  6 2017-12-20 00:27:21	0|phantomcircuit|iirc we dont remember expired transactions at all, i expected that to mean they just end up back in the mempool after a few hours
  7 2017-12-20 00:45:55	0|DrBenway|hi folks, is the 2018 roadmap published anywhere? i can't seem to find it
  8 2017-12-20 00:46:34	0|sipa|there is no roadmap
  9 2017-12-20 00:46:36	0|bitcoin-git|[13bitcoin] 15agsstaff opened pull request #11954: update (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11954
 10 2017-12-20 00:46:57	0|DrBenway|is there some kind of plan for the future or are you guys just maintaining the current codebase and trying to keep it as is?
 11 2017-12-20 00:47:08	0|sipa|many people have many plans for the future
 12 2017-12-20 00:47:20	0|DrBenway|and none of it is public?
 13 2017-12-20 00:47:20	0|sipa|but bitcoin core is just an open source project
 14 2017-12-20 00:47:28	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11954: update (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11954
 15 2017-12-20 00:47:40	0|sipa|DrBenway: what is your roadmap?
 16 2017-12-20 00:47:54	0|DrBenway|sipa: i dont have one. but im also not a project
 17 2017-12-20 00:47:58	0|sipa|neither am i
 18 2017-12-20 00:48:15	0|DrBenway|o_O
 19 2017-12-20 00:48:37	0|DrBenway|friendly community
 20 2017-12-20 00:48:42	0|sipa|i volunteer my time, and i'll gladly tell you what i'm working on or excited about
 21 2017-12-20 00:48:57	0|sipa|but i can't tell people what they need to work on, or guarantee what they will prioritize
 22 2017-12-20 00:49:05	0|sipa|that's up to them
 23 2017-12-20 00:49:41	0|DrBenway|so what are you working on?
 24 2017-12-20 00:49:49	0|jonasschnelli|promag: currently not possible...
 25 2017-12-20 00:50:07	0|jonasschnelli|though adding a check in getwalletinfo would be trivial
 26 2017-12-20 00:50:28	0|jonasschnelli|just test if you can reserve via the WalletRescanReserver
 27 2017-12-20 00:50:32	0|sipa|DrBenway: i'm currently working on segwit wallet support in bitcoin core, reviewing many other changes, and longer term i'm working on a signature aggregation proposal and a few further out cryptographic constructions
 28 2017-12-20 00:50:47	0|eck|what are you excited about?
 29 2017-12-20 00:51:16	0|DrBenway|is bitcoin core going ahead with segwit? there's been so much back and forth that im not sure anymore
 30 2017-12-20 00:52:12	0|meshcollider|DrBenway: Segwit has been activated for months... you are probably getting confused with S2X which is definitely not going ahead, no
 31 2017-12-20 00:52:56	0|DrBenway|so currently signatures are not stored with the block itself? or there's an extended block?
 32 2017-12-20 00:53:12	0|sipa|DrBenway: segwit absolutely keeps all signatures in blocks
 33 2017-12-20 00:53:16	0|meshcollider|Signatures are stored within the block yes
 34 2017-12-20 00:53:27	0|sipa|they're just moved to another place, and hashed slightly differently
 35 2017-12-20 00:53:48	0|DrBenway|i thought the whole idea of segwit was that the signature would go in an extended block? (im not sure where that extended block ends up in the blcok chain)
 36 2017-12-20 00:53:55	0|DrBenway|ok
 37 2017-12-20 00:53:55	0|sipa|no
 38 2017-12-20 00:54:25	0|sipa|the point is (1) signatures are not committed to by transaction ids (but still included in blocks) and (2) are discounted for the purposes of resource limits
 39 2017-12-20 00:54:38	0|sipa|but if you download a block, it still has all the signatures
 40 2017-12-20 00:54:43	0|sipa|it'll be invalid without them
 41 2017-12-20 00:54:54	0|DrBenway|sure
 42 2017-12-20 00:55:13	0|cfields|NicolasDorier: ping. transaction_tests/test_big_witness_transaction takes 20sec to sign the inputs on x86. I suspect it takes minutes on travis. Suggestions for reducing that without defeating the purpose of the test?
 43 2017-12-20 00:55:18	0|DrBenway|and that was done as a mean of reducing memory in case that the signute is used several times within a single block?
 44 2017-12-20 00:55:34	0|DrBenway|s/memory/data
 45 2017-12-20 00:55:45	0|meshcollider|DrBenway: no, signatures can't be reused for different transactions
 46 2017-12-20 00:55:47	0|sipa|DrBenway: https://segwit.org/
 47 2017-12-20 01:09:19	0|echeveria|GBT over ZMQ seems to be a win.
 48 2017-12-20 01:10:21	0|promag|echeveria: GBT?
 49 2017-12-20 01:10:41	0|echeveria|`getblocktemplate`
 50 2017-12-20 01:10:41	0|meshcollider|getblocktemplate?
 51 2017-12-20 01:11:00	0|meshcollider|those are used for very different things though?
 52 2017-12-20 01:11:57	0|echeveria|not really. at the moment there's a load of suboptimal ways of getting work updates from Bitcoin Core, adding a GBT endpoint means you don't need to poll or do any roundtrips to RPC.
 53 2017-12-20 01:12:34	0|echeveria|the status quo at the moment is using -blocknotify to trigger a RPC call, which involves spawning a shell, making a HTTP connection, and the RPC request time.
 54 2017-12-20 01:14:36	0|promag|echeveria: you can use pubrawblock
 55 2017-12-20 01:14:45	0|promag|ops, pubhashblock
 56 2017-12-20 01:16:12	0|echeveria|promag: that still needs a round trip.
 57 2017-12-20 01:16:12	0|promag|I don't think it's a good idea to have a gbt notification
 58 2017-12-20 01:16:58	0|promag|echeveria: how would you define template_request of gbt?
 59 2017-12-20 01:17:32	0|promag|what is the problem of the round trip?
 60 2017-12-20 01:18:14	0|echeveria|template_request?
 61 2017-12-20 01:18:24	0|promag|gbt argument
 62 2017-12-20 01:19:34	0|sipa|promag: ?
 63 2017-12-20 01:19:50	0|echeveria|promag: none of those arguments are necessary.
 64 2017-12-20 01:24:10	0|promag|not sure if a notification is the right thing
 65 2017-12-20 01:25:07	0|promag|current notifications are things that "happened" where what you want is to pub a computation (a heavy one?)
 66 2017-12-20 01:25:17	0|sipa|echeveria: you're saying to compare with -blocknotify... but you can use GBT over RPC, and use ZMQ notifications too
 67 2017-12-20 01:25:30	0|sipa|i would certainly advise against using -blocknotify
 68 2017-12-20 01:25:55	0|echeveria|by 'seems to be a win' I meant the code is written and running.
 69 2017-12-20 01:25:55	0|promag|right, that's why I said to use pubhashblock
 70 2017-12-20 01:29:34	0|promag|echeveria: even if that was possible, you should keep the gbt thru rpc. don't rely only in zmq notifications.
 71 2017-12-20 01:30:10	0|promag|for intance, with rpc you get errors
 72 2017-12-20 01:30:43	0|echeveria|not seeing a scheduled ZMQ frame is also an error.
 73 2017-12-20 01:31:00	0|sipa|ZMQ is unreliable
 74 2017-12-20 01:31:49	0|promag|I'm not talking about that errors, for instance, if the node crash, you will be sitting there waiting for notifications...
 75 2017-12-20 01:33:41	0|promag|with RPC you can measure the request duration, trigger something if above a certain value, etc it's much more expressive than zmq notifications
 76 2017-12-20 01:35:02	0|promag|zmq notifications are cool to avoid polling or the nasty process spawn, but then use the existing interface
 77 2017-12-20 01:35:14	0|promag|the roundtrip should not be a problem imo
 78 2017-12-20 01:44:24	0|morcos|gmaxwell: what is the issue with expired transactions keeping the relay fee from going up?  why do you want the relay fee to go up and how will it go up faster with your idea?
 79 2017-12-20 01:45:28	0|morcos|at first glance it doesn't make much sense to me.  for instance i just today placed some transactions that were 120 sat/byte.  i'm assuming they'll get confirmed over christmas weekend.  the whole point of longer estimates is people might be able to wait for the weekly cycle so the mempool should be big enough to handle that
 80 2017-12-20 01:45:57	0|echeveria|promag: not receiving a scheduled message, or missing a sequence number clearly indicates that.
 81 2017-12-20 01:45:57	0|morcos|on top of that, i think you want to be able to do CPFP and its nice to have the stuck transactions still in mempools
 82 2017-12-20 01:46:01	0|gmaxwell|morcos: relay fee now appears to be unrealistically low.  e.g. we're regularly wasting bandwidth on transactions that are not going to confirm before they expire.
 83 2017-12-20 01:46:36	0|morcos|gmaxwell: ahh.. i think thats ok.
 84 2017-12-20 01:46:51	0|promag|echeveria: not receiving a scheduled message - you mean you timeout when no notification arrives?
 85 2017-12-20 01:46:53	0|gmaxwell|what I'm suggesting is that the only way transactions that aren't making it to the top of your mempool would expire is if they're evicted due to low fee. So they'd be there for CPFPing.
 86 2017-12-20 01:47:07	0|echeveria|promag: yes.
 87 2017-12-20 01:47:33	0|morcos|hopefully we wrote it up in the PR that did mempool limiting, but we were aware of that issue, but the amount of free relay that can be achieved that way is limited  (and is not that much)
 88 2017-12-20 01:48:43	0|morcos|gmaxwell: i'm confused.  i thought you wanted to expire/evict/remove them if they haven't been in the top 4M weight for 48 hours?
 89 2017-12-20 01:48:52	0|morcos|oh but then you want to make that the mempool min fee?
 90 2017-12-20 01:49:30	0|gmaxwell|no, the other way around. I want to have a counter on each txn that counts roughly how long it's been in the top 4MB weight, and only expires once that goes over 48 hours.
 91 2017-12-20 01:49:40	0|promag|echeveria: not the best approach though, worst case you would be 10min until you do something
 92 2017-12-20 01:49:46	0|gmaxwell|because if it's in the top 4mb and not getting mined, then it's been softforked out.
 93 2017-12-20 01:49:49	0|echeveria|promag: 5 seconds.
 94 2017-12-20 01:49:52	0|morcos|ohhhh
 95 2017-12-20 01:50:19	0|morcos|wow i misunderstood, ok, so you want to get rid of expiration, but need to solve for the unminable txs
 96 2017-12-20 01:50:22	0|morcos|yeah that makes way more sense
 97 2017-12-20 01:50:26	0|promag|you mean you gbt each 5 seconds?
 98 2017-12-20 01:50:36	0|echeveria|yes.
 99 2017-12-20 01:50:50	0|promag|so why do you need zmq?
100 2017-12-20 01:50:53	0|echeveria|this is not unexpected, ckpool does GBT every 100ms in some modes.
101 2017-12-20 01:51:00	0|gmaxwell|morcos: yes, I want to get rid of expiration but don't want the risk of your mempool getting filled up with high fee unminable coins.
102 2017-12-20 01:51:29	0|echeveria|promag: please try and consider what you're arguing. it's clearly ludicrous to poll GBT RPC every 5 seconds, the amount of work wasted would be colossal.
103 2017-12-20 01:51:37	0|gmaxwell|also for unmineable tx, two weeks is a horrific amount of time to keep them around anyways...
104 2017-12-20 01:51:55	0|echeveria|promag: pushing GBT on UpdateTip, and every 5 seconds is clearly different.
105 2017-12-20 01:52:18	0|promag|how is that less work?
106 2017-12-20 01:52:42	0|echeveria|there's no round trips, and I'm not sequestering cs_main every 100ms.
107 2017-12-20 01:53:07	0|promag|every 100ms or 5s?
108 2017-12-20 01:53:21	0|morcos|gmaxwell: it's an intersting idea, but i'm not sure how large the problem is that you're trying to address.  at least with mempool expiration there is a cumbersome mechanism to replace a non-RBF tx
109 2017-12-20 01:53:23	0|echeveria|> ckpool does GBT every 100ms in some modes.
110 2017-12-20 01:53:44	0|promag|so in those modes with zmq there would be a zmq notification each 100ms?
111 2017-12-20 01:54:14	0|promag|I mean, even to pub the notification you have to acquire cs_main like gbt
112 2017-12-20 01:54:29	0|echeveria|( poll RPC every 100ms | ZMQ on UpdateTip + every 5 seconds) two different things.
113 2017-12-20 01:54:39	0|morcos|without expiration, then you kind of have to hope it gets evicted, and then you have nodes with larger mempools actually having a worse picture of things b/c they dont' accept the replacement
114 2017-12-20 01:54:48	0|morcos|would make more sense in a full-rbf world
115 2017-12-20 01:55:25	0|gmaxwell|morcos: I'm not sure yet if 1s/vb is a feerate that will never confirm... but I do think we don't want minifee to be frequently below the never-confirm rate.
116 2017-12-20 01:55:28	0|aj|could just continue to expire non-rbf txes after a week?
117 2017-12-20 01:56:39	0|morcos|gmaxwell: i agree with that, except what we really want is the incremental rate to not be below that.. not just the mempool min fee, where the incremental rate is the floor for minrelay
118 2017-12-20 01:56:54	0|morcos|and the bump requirement for RBF and mempool min fee after eviction
119 2017-12-20 01:56:56	0|gmaxwell|Speaking of RBF, I've been thinking some of the the RBF pinning problem, and think we could solve it by having a flag set on a transaction that an unconfirmed spend of its outputs is only allowed in the mempool the resulting package feerate would be near-confirmation.
120 2017-12-20 01:57:17	0|morcos|so perhaps we want a way to set incremental fee... but i'm just not sure yet how to do that
121 2017-12-20 01:58:16	0|aj|gmaxwell: noticing you're seeing unmined transactions that you think seem valid might be a useful warning indicator of weird things going on (eg, it might mean your fee estimation is being based on bad data?)
122 2017-12-20 01:58:17	0|gmaxwell|RBF-pinning for those who don't know what I'm referring to is the issue where you make a moderate fee RBF payment with an intention of bidding up the RBF over the next couple days until it confirms... but then one of your payees manages their input-clutter by immediately creating a very low feerate 100kb transaction that aggregates up all their small inputs.
123 2017-12-20 01:58:37	0|morcos|i know people hate defaults...  but arguably the best thing to do is just change the default incremental relay rate
124 2017-12-20 01:59:58	0|gmaxwell|The RBF pinning problem is then that the RBFer above can't RBF their transaction unless they also pay the incremental rate for the 100kb child.
125 2017-12-20 01:59:59	0|morcos|aj: yes, i wrote a MPAM (miner policy alignment meter) for Core, but Peter Todd had some esoteric complaints about it and i forgot it.. i forget a lot of things though
126 2017-12-20 02:00:02	0|gmaxwell|Which is quite expensive!
127 2017-12-20 02:01:13	0|promag|echeveria: right, but you can do that now
128 2017-12-20 02:02:04	0|gmaxwell|a user of ours who hit rbf-pinning hard was trying to suggest that we prohibit all spends of unconfirmed outputs, which is nuts... but perhaps something to opt-in where the outputs could only be spent by txn that would bump the feerate to near confirmation.. everyone could still CPFP... but no more major pinning problem.
129 2017-12-20 02:03:26	0|morcos|i think we need segfee for segregating the fee out of txid, so you can increase it without invalidating descendants
130 2017-12-20 02:04:16	0|aj|morcos: isn't that CPFP?
131 2017-12-20 02:04:19	0|gmaxwell|yea... I've thought abot that.
132 2017-12-20 02:04:31	0|gmaxwell|CPFP is inherently not that efficient.
133 2017-12-20 02:05:06	0|morcos|gmaxwell: one somewhat smart suggestion on those lines would be to have an online mode for Core where if the wallet expects to remain online, it doesn't bother broadcasting lower fee txs until later (but then i guess you'd stil have to resign if the parent changed)
134 2017-12-20 02:05:17	0|aj|gmaxwell: is this where you point to a wiki page from five years ago explaining how to do it efficiently?
135 2017-12-20 02:05:38	0|gmaxwell|morcos: yep, made the same observation myself, but it reuires the second party to be helpful at their own very slight expense.
136 2017-12-20 02:07:41	0|phantomcircuit|wait there's no way to trigger wallet rescan unless the private key is actually new
137 2017-12-20 02:07:44	0|phantomcircuit|lol
138 2017-12-20 02:08:12	0|morcos|i probably shouldn't be spitting out my stupid ideas here without thinking on them first, but we could imagine a more efficient CPFP via some softfork mechanism, where a future tx (without needing to spend prior txs outputs could pay for them)
139 2017-12-20 02:08:33	0|morcos|you could reduce the cost so barely over 32 bytes on the paying tx and could include as many paid for txs as you wanted
140 2017-12-20 02:09:45	0|morcos|which you broadcast in an extended tx format potentially, but hmmm...   how do you know which ones go with it in the block perhaps by required ordering and then just the number of txs
141 2017-12-20 02:09:51	0|morcos|getting complicated and messy
142 2017-12-20 02:10:43	0|gmaxwell|Well these sighash no input things wouldn't invalidate the child but they are phenominally dangerous and we really wouldn't want to encourage their use outside of specialized cases.
143 2017-12-20 02:10:51	0|gmaxwell|(they have no replay protection of any form at all...)
144 2017-12-20 02:11:44	0|aj|having the 100kB RBF-pinning tx use SIGHASH_NOINPUT could be made to work okay afaics
145 2017-12-20 02:11:46	0|aj|but augh
146 2017-12-20 02:17:24	0|echeveria|promag: yes I can, because I've written the patch.
147 2017-12-20 02:19:00	0|promag|echeveria: PR #?
148 2017-12-20 02:19:08	0|gmaxwell|aj: yes except you really can't safely do that, because the payer needs to know to be sure to NEVER pay to that pubkey again.
149 2017-12-20 03:08:45	0|bob___|hello
150 2017-12-20 03:09:49	0|Guest49262|Bonjour
151 2017-12-20 03:09:51	0|bob___|having an issue with bitcoin core changing the transaction fee to a lower amount?
152 2017-12-20 03:10:07	0|bob___|can anyone help?
153 2017-12-20 03:15:14	0|kikooo|yop
154 2017-12-20 03:22:48	0|meshcollider|bob___: try #bitcoin channel, this one is not for support
155 2017-12-20 03:42:36	0|adiabat|did I hear sighash_noinput?  I love that stuff! :) (but yes, I understand that it's a serious foot-cannon)
156 2017-12-20 07:01:54	0|fanquake|If everyone could refrain from being part of a secret society that'd be great.
157 2017-12-20 07:10:16	0|bitcoin-git|[13bitcoin] 15fockkboy opened pull request #11958: Update README.md to let people know about (((Bilderberg))) and HIGH FEES! (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11958
158 2017-12-20 07:10:50	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11958: Update README.md to let people know about (((Bilderberg))) and HIGH FEES! (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11958
159 2017-12-20 07:11:15	0|wumpus|sorry MJ12 doesn't take kindly on people trying to quit
160 2017-12-20 07:11:58	0|phantomcircuit|is there a reason there isn't a wallet rescan rpc separate from the import* functions?
161 2017-12-20 07:12:33	0|gmaxwell|phantomcircuit: you haven't submitted yet. Bonus points if you make it handle multiwallet sanely (not scanning them one at a fking time!)
162 2017-12-20 07:12:50	0|fanquake|wumpus :o
163 2017-12-20 07:12:53	0|gmaxwell|double bonus if it lets you specify a blinking range (code from importmulti, I guess)
164 2017-12-20 07:15:17	0|wumpus|phantomcircuit: the reasoning behind that was always that it was unnecessary, because import should let you provide the key birthdates and thus it can determine what to scan for itself
165 2017-12-20 07:15:38	0|wumpus|phantomcircuit: if you need a loose rescan, something is usually wrong
166 2017-12-20 07:15:49	0|wumpus|phantomcircuit: so it's a diagnostic option for startup only
167 2017-12-20 07:17:22	0|phantomcircuit|yeah what's wrong is i used importprivkey with rescan false and the only way to fix it is to restart with -rescan but i dont want to restart
168 2017-12-20 07:17:45	0|sipa|phantomcircuit: you mean the rescanblockchain RPC? https://github.com/bitcoin/bitcoin/blob/master/src/wallet/rpcwallet.cpp#L3362
169 2017-12-20 07:18:11	0|gmaxwell|oh yea, that reasoning, I forgot about that.
170 2017-12-20 07:18:19	0|gmaxwell|crazy users rescanning for no reason. :(
171 2017-12-20 07:18:54	0|sipa|guys. we. have. an. RPC. for. that.
172 2017-12-20 07:19:08	0|phantomcircuit|oh
173 2017-12-20 07:19:09	0|phantomcircuit|neat
174 2017-12-20 07:19:42	0|gmaxwell|is it hidden?
175 2017-12-20 07:19:49	0|wumpus|ok. Please don't ask about existing RPCs, apparently I've lost track :-)
176 2017-12-20 07:19:50	0|gmaxwell|speaking of hidden... we have some things that should get unhidden.
177 2017-12-20 07:20:00	0|gmaxwell|The logging thing, in particular which is the best damn rpc ever.
178 2017-12-20 07:20:14	0|echeveria|logging?
179 2017-12-20 07:20:17	0|wumpus|no, it's not hidden
180 2017-12-20 07:20:22	0|sipa|what about the increasebalance RPC? i think that one's pretty neat too
181 2017-12-20 07:20:30	0|wumpus|the only hidden one is 'resendwallettransactions'
182 2017-12-20 07:20:43	0|wumpus|noooo sipa don't mention that one, it's only for secret society use
183 2017-12-20 07:21:03	0|eck|gentlemen save this for the bilderberg meeting, please
184 2017-12-20 07:21:08	0|gmaxwell|echeveria: there is an RPC to set the amount of logging detail.
185 2017-12-20 07:21:14	0|fanquake|Too late now. Trending on Reddit asap.
186 2017-12-20 07:21:37	0|gmaxwell|echeveria: which means you can shut off the chatty as heck leveldb stuff when it irritates you without restarting. :P
187 2017-12-20 07:22:05	0|echeveria|gmaxwell: that’s handy, my node takes a very long time to restart, and restarting tends to absolve problems I’d like to debug with -debug=net.
188 2017-12-20 07:22:34	0|Sentineo|the syntax is pretty easy, just do not forget to escape the " :)
189 2017-12-20 07:22:48	0|wumpus|logging was unhidden in #11626
190 2017-12-20 07:22:50	0|gmaxwell|blocksonly is also hidden. though I think the rational for hiding it has not been addressed. :(
191 2017-12-20 07:22:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/11626 | rpc: Make `logging` RPC public by laanwj · Pull Request #11626 · bitcoin/bitcoin · GitHub
192 2017-12-20 07:22:55	0|gmaxwell|woot.
193 2017-12-20 07:23:16	0|Sentineo|yep 15.1 has it in help
194 2017-12-20 07:23:20	0|echeveria|very, very large mempools take an extraordinary time to load (I understand why).
195 2017-12-20 07:23:26	0|gmaxwell|I'm sorry I've been on github less lately.
196 2017-12-20 07:23:38	0|gmaxwell|echeveria: huh? what are you talking about
197 2017-12-20 07:23:46	0|Sentineo|echeveria: my node when restarted fails to import the mempool saved anyway
198 2017-12-20 07:23:48	0|gmaxwell|echeveria: mempool restore is entirely non-invasive and in the background.
199 2017-12-20 07:24:45	0|echeveria|gmaxwell: yes, it’s very much not a problem, it’s just a reason that changing the debug level is a great feature to have.
200 2017-12-20 07:25:22	0|echeveria|if I want to debug=mempoolrej it needs to have the mempool.dat loaded :)
201 2017-12-20 07:26:00	0|Sentineo|having other stuff like turning on rpc/rest on the fly would be neat
202 2017-12-20 07:27:16	0|gmaxwell|Sentineo: gonna use the rpc to turn on RPC?
203 2017-12-20 07:27:46	0|Sentineo|did not put much thought into it apearantly gmaxwell :P
204 2017-12-20 07:27:55	0|wumpus|hahahahah yes that would be really neat
205 2017-12-20 07:28:11	0|Sentineo|but yeh, that would be really neat :D
206 2017-12-20 07:28:46	0|wumpus|non-causal RPC switching, powered by flux capacitor
207 2017-12-20 07:29:26	0|Sentineo|the switch could be called "Delorien" :)
208 2017-12-20 07:30:05	0|Sentineo|delorean - sorry .. typo
209 2017-12-20 07:30:36	0|fanquake|gmaxwell if you're going to be on GH again soon, you might be interested in #11359 or 11630
210 2017-12-20 07:30:38	0|gribble|https://github.com/bitcoin/bitcoin/issues/11359 | Add a pruning high water mark to reduce the frequency of pruning events by esotericnonsense · Pull Request #11359 · bitcoin/bitcoin · GitHub
211 2017-12-20 07:31:48	0|gmaxwell|I know, you could send messages via signals and morse code,  killall -30 bitcoind ; sleep 1 ; killall -30 bitcoind ....
212 2017-12-20 07:32:06	0|gmaxwell|fanquake: OK.
213 2017-12-20 07:32:38	0|wumpus|ah yes the rumored kill -SHORTBEEP -LONGBEEP
214 2017-12-20 07:32:45	0|gmaxwell|half the reason I haven't been as active is that in the evening I'm using a computer without GH credentials on it, ... which ranks pretty highly for stupid reasons...
215 2017-12-20 07:34:45	0|wumpus|I understand trying to be careful with your gh credentials, but there's got to be a better way
216 2017-12-20 07:36:22	0|eck|perhaps called an ssh key
217 2017-12-20 07:37:29	0|phantomcircuit|eck, cant login to their website with ssh keys sir
218 2017-12-20 07:37:39	0|eck|i'll concede that point
219 2017-12-20 07:37:47	0|fanquake|wumpus does everyone inside the bitcoin org have 2FA turned on?
220 2017-12-20 07:37:55	0|echeveria|phantomcircuit: that’s what x forwarding is for.
221 2017-12-20 07:38:08	0|wumpus|fanquake: let's check, it was the case last ime I looked
222 2017-12-20 07:38:16	0|gmaxwell|this is my only host that I haven't been able to strip intel ME off of, so I'm generally trying to keep security critical things of it.
223 2017-12-20 07:39:01	0|wumpus|I have no intel devices left
224 2017-12-20 07:39:49	0|eck|what year is it from
225 2017-12-20 07:40:29	0|eck|i went through this exercise recently, only to learn that i am pretty much sol if i have any devices made in the last ten years
226 2017-12-20 07:40:41	0|wumpus|I hope I can get rid of the AMD ones too before a similar backdoor in AMD to show up
227 2017-12-20 07:41:18	0|Sentineo|what backdoor?
228 2017-12-20 07:42:20	0|wumpus|but intel's reaction to the whole ME debacle - instead of offering the option to disable it, try to make it even more difficult to disable it - was enough to dump them completely
229 2017-12-20 07:42:53	0|eck|too bad there are no credible aarch64 systems
230 2017-12-20 07:43:26	0|Sentineo|so I need to use abacus!
231 2017-12-20 07:43:43	0|wumpus|yes it's why I'm using AMD for the moment, waiting for ARM and eventually RISCV
232 2017-12-20 07:43:51	0|gmaxwell|eck: it's pretty easy to lobotomize ME out of most moderately new systems, thanks to MEcleaner
233 2017-12-20 07:44:21	0|gmaxwell|wumpus: I dunno if you saw, but the next gen of intel cpus will contain efuse based downgrade resistance for the me firmware.
234 2017-12-20 07:44:57	0|eck|i don't know much about mecleaner, but this doesn't help me use e.g. coreboot, does it?
235 2017-12-20 07:45:05	0|phantomcircuit|well that's just blatantly admitting it's a backdoor
236 2017-12-20 07:45:10	0|eck|that's the project i was looking at most recently
237 2017-12-20 07:45:20	0|gmaxwell|right now you can reflash with a spi programmer to downgrade me firmware (e.g. to undo a possible upgrade that disables the HAP bit) since the cpu has no external truth on what ME firmware is the most recent.
238 2017-12-20 07:45:20	0|wumpus|gmaxwell: yes I heard, that's what maded me so angry
239 2017-12-20 07:45:44	0|wumpus|why not give your customers the choice?
240 2017-12-20 07:45:51	0|gmaxwell|eck: coreboot alone isn't enough, e.g. you can run coreboot on a lenovo x230 but unless you run mecleaner it has the hidden second operating system still.
241 2017-12-20 07:46:25	0|eck|i have more recent hardware but since that is news to me, i'll take a second look anyway, thanks
242 2017-12-20 07:47:16	0|gmaxwell|coreboot is nice, but not as important as getting rid of ME. other than some ACPI handling stuff the bios is out of the picture once the OS is running.
243 2017-12-20 07:47:42	0|gmaxwell|ME = whole seperate quasi-pentium cpu that runs all the time in the background (even with computer suspended) and has access to everything.
244 2017-12-20 07:48:10	0|gmaxwell|separate meaning still inside the cpu package, however.
245 2017-12-20 07:48:22	0|eck|the whole point of coreboot from my pov is to know for sure that IME is disabled
246 2017-12-20 07:48:41	0|eck|otherwise how would you be sure?
247 2017-12-20 07:49:03	0|gmaxwell|eck: because you physically rewrote the flash chip and took most of the me data out of it.
248 2017-12-20 07:49:10	0|gmaxwell|which is what me cleaner does.
249 2017-12-20 07:49:44	0|gmaxwell|until me cleaner that wasn't possible for coreboot to disable ME on most hardware that had ME, the issue is on most of those systems the system will shut down after 30 minutes if ME doesn't boot.
250 2017-12-20 07:50:00	0|eck|i will have to read more about ME and coreboot and mecleaner to comment
251 2017-12-20 07:50:12	0|eck|what you said makes sense though
252 2017-12-20 07:50:18	0|gmaxwell|so the coreboot instructions basically have you avoid rewriting the ME partition so the computer will keep working.
253 2017-12-20 07:50:21	0|Sentineo|so what are the implications of not removing it for a noob? :)
254 2017-12-20 07:51:00	0|gmaxwell|Sentineo: maybe nothing, or maybe intel and anyone who controls them or compromised them or found bugs in their code has full backdoor access to the computers running it.
255 2017-12-20 07:51:00	0|wumpus|there's a parallel OS running on your CPU, running a fairly insecure software stack, network connected
256 2017-12-20 07:51:17	0|wumpus|-> you can work out the rest of the details
257 2017-12-20 07:51:47	0|Sentineo|yeah ...
258 2017-12-20 07:51:58	0|wumpus|oh yes it happens to have ring -infinite access over anything else your CPU might be doing, so any access controls in your OS mean nothing
259 2017-12-20 07:52:00	0|eck|the assumption here though is that the me requires external flash memory to run, since it's some bloated c/c++ program, right?
260 2017-12-20 07:52:08	0|Sentineo|so you were refering to arm ... e.g. running stuff on rasberry pi sounds more secure than? or I got it wrong?
261 2017-12-20 07:52:42	0|eck|what if the ME was coded directly into the silicon? or is that not likely due to its complexity?
262 2017-12-20 07:52:46	0|gmaxwell|eck: the flash on current motherboards is ~32 MB in size in total.
263 2017-12-20 07:53:21	0|fanquake|Good thing there isn't a torrent of bugs found in ME :)
264 2017-12-20 07:53:23	0|gmaxwell|eck: it's not so much of a mystery now, it runs minix. people how have jtag access to it.
265 2017-12-20 07:53:38	0|wumpus|Sentineo: RPI is a bad example because it also has a proprietary core glued to the CPU; but something like i.mx6 which can run blobless would be more secure, everything else the same
266 2017-12-20 07:53:53	0|gmaxwell|you can also run arbritary code on it now and bypass the code signing, at least if you can write to the flash.
267 2017-12-20 07:54:14	0|eck|wild
268 2017-12-20 07:54:25	0|eck|and it's all undocumented, right?
269 2017-12-20 07:54:26	0|gmaxwell|I don't think anyone has targeted it with a compiler yet, its instruction set is non-standard.
270 2017-12-20 07:54:46	0|gmaxwell|it's a 486 with some pentium features added and some legacy features dropped.
271 2017-12-20 07:54:54	0|gmaxwell|eck: right.
272 2017-12-20 07:55:10	0|eck|wait can it access the host os memory
273 2017-12-20 07:55:10	0|gmaxwell|but with jtag access people can reverse engineer things.
274 2017-12-20 07:55:12	0|Sentineo|ah insane
275 2017-12-20 07:55:14	0|eck|what memory mode is it in
276 2017-12-20 07:55:51	0|Sentineo|so doing dice for privkeys and paper wallet does not sound that a bad idea now :D
277 2017-12-20 07:56:30	0|eck|i wonder how you would synchronize between the me processor and  ring 0/-1
278 2017-12-20 07:56:36	0|gmaxwell|eck: presumably you use some kind of IO functionality to access the host memory, it's not direct mapped to the host memory.
279 2017-12-20 07:56:45	0|wumpus|it would have been fairly ok if they just allowed reprogramming it, targetting it with custom software from now on, from now on, but no, they had to clamp down on it more
280 2017-12-20 07:56:51	0|gmaxwell|which probably also avoids having to make it cache cohearent.
281 2017-12-20 07:57:37	0|eck|not that i (or anyone else) is running such code, but if there was synchronization between the kernel and some ME processor, surely you could tell from timing
282 2017-12-20 07:58:35	0|eck|i've written a bunch of ptrace stuff, and from userspace it's pretty obvious when you're being traced due to the clock slowdowns
283 2017-12-20 07:58:40	0|wumpus|and then, you're going to measure every single memory operation to catch an ME backdoor in the act?
284 2017-12-20 07:58:46	0|gmaxwell|heh
285 2017-12-20 07:58:52	0|eck|depends what the overhead is
286 2017-12-20 07:59:21	0|wumpus|I can't wait for such security theatre in operating systems </s>
287 2017-12-20 07:59:26	0|gmaxwell|of course the problem is that all it needs to do is snoop your network, which it might do for free, then when triggered push a single write into kernel memory to open up a backdoor.
288 2017-12-20 08:00:10	0|gmaxwell|and of course mystical power management on recent cpus makes timing kind of a mystery. :)
289 2017-12-20 08:00:25	0|eck|for sure
290 2017-12-20 08:01:16	0|wumpus|it's clearly not the solution, certainly not on long term, all those parameters would have to be figured out again for every new chip
291 2017-12-20 08:01:25	0|eck|on a numa system you can't even depend on time being coherent across threads on the same cpu, much less in the presence of a management engine
292 2017-12-20 08:03:17	0|wumpus|the ME will just be one of the many DMA streams going on
293 2017-12-20 08:03:58	0|eck|gmaxwell: curious if you had to deal with this kind of thing at all at xiph
294 2017-12-20 08:04:17	0|eck|one could easily imagine hardware to block certain content
295 2017-12-20 08:04:42	0|gmaxwell|intel does use ME in some windows DRM stuff, but that isn't a think that comes up for free codecs.
296 2017-12-20 08:05:02	0|phantomcircuit|gmaxwell, hdcp stuff?
297 2017-12-20 08:05:27	0|gmaxwell|no idea. I don't care because DRM and because windows. :P
298 2017-12-20 08:06:11	0|gmaxwell|apparently the SGX monotone counter stuff uses ME too, some presumably e.g. teechains is class broken now.
299 2017-12-20 08:07:07	0|wumpus|hdcp is specific to hdmi compression, but I'd assume it's used to create a 'trusted video path' (puke) between the video decoder and graphics/scanout
300 2017-12-20 08:07:15	0|wumpus|s/compression/encryption
301 2017-12-20 08:07:51	0|eck|clearly i have 0% of the knowledge in this space as you, but the adversarial attack i was thinking of would be fingerprinting decoding or *encoding* somehow, so you could figure out who decoded/encoded a video
302 2017-12-20 08:08:10	0|eck|although clearly that would be dependent on the encoder at least using hardware primitives
303 2017-12-20 08:13:46	0|wumpus|DRM is never about encoding, always about decoding
304 2017-12-20 08:18:20	0|wumpus|it's rooted in a world where every client is a consumer, and there's a few "premium" producers whose content has to be protected. But ok, this is getting off topic, sorry.
305 2017-12-20 08:18:45	0|fanquake|wumpus save it for twitter :p
306 2017-12-20 08:19:21	0|wumpus|:p
307 2017-12-20 08:38:00	0|bitcoin-git|13bitcoin/06master 14be9a13c 15MeshCollider: Add configuration/argument testing
308 2017-12-20 08:38:00	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/18a1bbad98bd...cfd99ddc3c19
309 2017-12-20 08:38:01	0|bitcoin-git|13bitcoin/06master 14cfd99dd 15Wladimir J. van der Laan: Merge #11883: Add configuration file/argument testing...
310 2017-12-20 08:38:35	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11883: Add configuration file/argument testing (06master...06201712_datadir_tests) 02https://github.com/bitcoin/bitcoin/pull/11883
311 2017-12-20 08:39:00	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11482: Use CPrivKey typedef for keydata in CKey (06master...06patch-3) 02https://github.com/bitcoin/bitcoin/pull/11482
312 2017-12-20 09:42:05	0|bitcoin-git|13bitcoin/06master 1462e7c04 15Matt Corallo: Remove dead feeest-file read code for old versions...
313 2017-12-20 09:42:05	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cfd99ddc3c19...1fb34e0d1f58
314 2017-12-20 09:42:06	0|bitcoin-git|13bitcoin/06master 141fb34e0 15Wladimir J. van der Laan: Merge #11951: Remove dead feeest-file read code for old versions...
315 2017-12-20 09:42:34	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11951: Remove dead feeest-file read code for old versions (06master...062017-12-dead-feeest-load) 02https://github.com/bitcoin/bitcoin/pull/11951
316 2017-12-20 09:42:56	0|sipa|feeest sounds like a really big party in dutch
317 2017-12-20 09:43:34	0|kallewoof|Haha, same in swedish.
318 2017-12-20 09:43:55	0|wumpus|yes I also wondered when I first saw that PR title why it was such a big celebration :)
319 2017-12-20 09:45:28	0|wumpus|although the 'dead' before it makes it a bit of a mixed feeling
320 2017-12-20 09:48:22	0|kallewoof|Maybe like the Bon festival in Japan (honor the spirits of one's ancestors).
321 2017-12-20 09:53:37	0|sipa|that even sounds good in French
322 2017-12-20 09:55:13	0|wumpus|heh
323 2017-12-20 12:43:56	0|bitcoin-git|[13bitcoin] 15laudaa opened pull request #11960: [Doc] Fix link to installation script (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11960
324 2017-12-20 12:48:02	0|wumpus|can anyone please test #11945 on macosx
325 2017-12-20 12:48:04	0|gribble|https://github.com/bitcoin/bitcoin/issues/11945 | Improve BSD compatibility of contrib/install_db4.sh by laanwj · Pull Request #11945 · bitcoin/bitcoin · GitHub
326 2017-12-20 12:48:36	0|wumpus|we replaced the bdb4 patch with a newer one, to accomodate freebsd/openbsd's clang, so need to know if this still works ok for macosx
327 2017-12-20 13:04:47	0|provoostenator|wumpus: I'll try it now
328 2017-12-20 13:06:26	0|provoostenator|Any configure flags you need me to use?
329 2017-12-20 13:07:31	0|wumpus|I'm not sure; just following the osx build guide would be best
330 2017-12-20 13:16:45	0|fanquake|wumpus I'm fairly certain it is ok, because the new patch does the same thing we do patch bd4 in depends.
331 2017-12-20 13:17:10	0|wumpus|fanquake: I've just tested on linux and gcc and it's ok at least
332 2017-12-20 13:17:41	0|fanquake|I'm just running though the basics on osx
333 2017-12-20 13:17:48	0|provoostenator|Related (?) question: does --with-incompatible-bdb still do something?
334 2017-12-20 13:17:52	0|wumpus|I should probably bite the bullet at some point and get it to work on freebsd
335 2017-12-20 13:18:05	0|wumpus|it's two lines of script or so...
336 2017-12-20 13:18:15	0|wumpus|provoostenator: yes, it makes the configure accept bdb 5+
337 2017-12-20 13:18:45	0|provoostenator|Ok, so I shoulnd't use that in this case I assume, because your changes relates to bdb 4?
338 2017-12-20 13:19:02	0|wumpus|it would be unnecessary but not do harm
339 2017-12-20 13:19:34	0|provoostenator|It actually wouldn't even do anything if you don't have berkeley-db5 installed?
340 2017-12-20 13:20:57	0|wumpus|right, it just removes the bdb 4.8 version check, if you want to point it at a different bdb installation you can use LDFLAGS="-L${BDB_PREFIX}/lib/" CPPFLAGS="-I${BDB_PREFIX}/include/"
341 2017-12-20 13:21:27	0|provoostenator|Ok, TIL...
342 2017-12-20 13:22:08	0|wumpus|the use of with/enable in our build system is quite inconsistent
343 2017-12-20 13:22:53	0|provoostenator|Yes, I also found out that it happily continues if QR reader dependencies are missing, which could cause someone to not even know that feature exists.
344 2017-12-20 13:23:01	0|wumpus|from what I remember officially --with is for specifying dependencies, and enable for features
345 2017-12-20 13:23:08	0|fanquake|11960 can go in.
346 2017-12-20 13:23:19	0|wumpus|fanquake: thanks
347 2017-12-20 13:24:21	0|wumpus|provoostenator: it's not considered a critical feature that you have to explicitly disable; it should print it in the summary though
348 2017-12-20 13:24:26	0|fanquake|wumpus are you only using clang on openbsd now?
349 2017-12-20 13:25:03	0|provoostenator|Yes, it does show in the summary.
350 2017-12-20 13:25:07	0|wumpus|fanquake: yes; I think from 6.2 on we should be encouraging people to just use the built-in clang CC=cc CXX=c++
351 2017-12-20 13:26:22	0|wumpus|fanquake: I haven't tried with any other compilers
352 2017-12-20 13:29:21	0|fanquake|wumpus Ok, that can be an update to the build instructions after 11945
353 2017-12-20 13:29:54	0|wumpus|fanquake: yes, could do that in the same PR, but I think it's somewhat orthogonal
354 2017-12-20 13:30:29	0|fanquake|It might also depend on what happens in 11921, so can wait for cory to comment there
355 2017-12-20 13:36:06	0|wumpus|I think 11921 is unncessary with 11945
356 2017-12-20 13:37:50	0|bitcoin-git|13bitcoin/06master 143d3e58e 15laudaa: [Doc] Fix link to installation script
357 2017-12-20 13:37:50	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1fb34e0d1f58...4307062ee2c2
358 2017-12-20 13:37:51	0|bitcoin-git|13bitcoin/06master 144307062 15Wladimir J. van der Laan: Merge #11960: [Doc] Fix link to installation script...
359 2017-12-20 13:38:28	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11960: [Doc] Fix link to installation script (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11960
360 2017-12-20 13:39:54	0|fanquake|wumpus Did you want to drop the gcc instructions as part of 11945 then? Might as well do the Clang switch in there.
361 2017-12-20 13:40:15	0|fanquake|clang feels like it's just tacked on the end at the moment heh
362 2017-12-20 13:40:19	0|wumpus|fanquake: I think we should keep the current doc, just add new instructions for version 6.2+
363 2017-12-20 13:40:35	0|wumpus|fanquake: people might still want to build for older openbsd, for now
364 2017-12-20 13:40:58	0|wumpus|not sure
365 2017-12-20 13:41:29	0|fanquake|I'm not even sure how many people are building on openbsd, given how often the instructions seem to be *broken*
366 2017-12-20 13:41:43	0|wumpus|great, I have it working on freebsd
367 2017-12-20 13:41:59	0|fanquake|found a new sha256 tool>
368 2017-12-20 13:42:34	0|wumpus|well it tends to get detected quite quickly when they're broken
369 2017-12-20 13:42:45	0|wumpus|bsd users don't tend to be so noisy otherwise
370 2017-12-20 13:43:46	0|fanquake|fair enough, add a 6.2+ section which is clang specific? That document is fairly short anyways.
371 2017-12-20 13:44:13	0|wumpus|yep
372 2017-12-20 13:59:56	0|Lauda|After running make check, where should the binaries be built?
373 2017-12-20 13:59:56	0|Lauda|I'm going through the build docs. After make check completed, I'm having trouble finding them
374 2017-12-20 14:01:49	0|wumpus|make builds the binaries in the build directory, which is where you invoke make. This will be src/bitcoin, src/qt/bitcoin-qt, src/test/test_bitcoin etc
375 2017-12-20 14:13:51	0|Lauda|Does that also build bitcoind by default?
376 2017-12-20 14:14:31	0|wumpus|I'm not sure. 'make check' is to run the unit tests, which don't need bitcoind
377 2017-12-20 14:15:19	0|Lauda|Alright, I'll redo make. I also wonder why 'make check' was used in the build example for Arch Linux
378 2017-12-20 14:15:22	0|Lauda|and not just make?
379 2017-12-20 14:15:38	0|wumpus|because running the tests is always recommended
380 2017-12-20 14:17:14	0|wumpus|and maybe they assume 'make check' builds the non-tests too. I really don't know if that's the case or not.
381 2017-12-20 14:18:45	0|Lauda|Well, for ARM example only 'make' is used and in the Arch one 'make check'. Just got me wondering
382 2017-12-20 14:23:53	0|wumpus|ok
383 2017-12-20 14:24:00	0|provoostenator|Note to self: actually checkout the correct branch before running make...
384 2017-12-20 14:31:36	0|Lauda|https://i.imgur.com/A4g8Erm.png
385 2017-12-20 14:31:36	0|Lauda|I take it that this warning is not expected behavior?
386 2017-12-20 14:37:32	0|wumpus|I don't remember seeing it
387 2017-12-20 14:38:14	0|wumpus|it's something in leveldb though, likely part of some inline assembly they added
388 2017-12-20 14:40:06	0|Lauda|Alright, thanks
389 2017-12-20 15:08:19	0|jouke|Hmm, fee of a sendmany with a lot of outputs also gets maxed out to some hardcoded 0.1 btc?
390 2017-12-20 15:13:11	0|instagibbs|jouke, there's a maxtxfee setting
391 2017-12-20 15:14:49	0|jouke|instagibbs: thanks
392 2017-12-20 15:15:33	0|wumpus|but yes, all transactions are checked against that
393 2017-12-20 15:52:04	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4307062ee2c2...9ab9963386ed
394 2017-12-20 15:52:05	0|bitcoin-git|13bitcoin/06master 1488411e9 15MarcoFalke: Squashed 'src/univalue/' changes from fe805ea74f..07947ff2da...
395 2017-12-20 15:52:05	0|bitcoin-git|13bitcoin/06master 14fad349c 15MarcoFalke: univalue: Bump subtree
396 2017-12-20 15:52:06	0|bitcoin-git|13bitcoin/06master 149ab9963 15Wladimir J. van der Laan: Merge #11952: [qa] univalue: Bump subtree...
397 2017-12-20 15:52:39	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11952: [qa] univalue: Bump subtree (06master...06Mf1712-univalueBump) 02https://github.com/bitcoin/bitcoin/pull/11952
398 2017-12-20 15:53:47	0|bitcoin-git|13bitcoin/06master 142862b56 15John Newbery: [tests] remove redundant univalue_tests.cpp
399 2017-12-20 15:53:47	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9ab9963386ed...d4e404a3afa8
400 2017-12-20 15:53:48	0|bitcoin-git|13bitcoin/06master 14d4e404a 15Wladimir J. van der Laan: Merge #11879: [tests] remove redundant univalue_tests.cpp...
401 2017-12-20 15:54:01	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11879: [tests] remove redundant univalue_tests.cpp (06master...06remove_univalue_test) 02https://github.com/bitcoin/bitcoin/pull/11879
402 2017-12-20 16:04:50	0|bitcoin-git|13bitcoin/06master 14f455a24 15Sjors Provoost: [net] add seed.testnet.bitcoin.sprovoost.nl to testnet DNS seeds
403 2017-12-20 16:04:50	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d4e404a3afa8...bc6676514429
404 2017-12-20 16:04:51	0|bitcoin-git|13bitcoin/06master 14bc66765 15Wladimir J. van der Laan: Merge #11917: Add testnet DNS seed:  seed.testnet.bitcoin.sprovoost.nl...
405 2017-12-20 16:05:22	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11917: Add testnet DNS seed:  seed.testnet.bitcoin.sprovoost.nl (06master...06testnet-dns-seed-sjors) 02https://github.com/bitcoin/bitcoin/pull/11917
406 2017-12-20 16:12:03	0|Lauda|wumpus was this the file that you were talking about? https://i.imgur.com/TP8jc18.png
407 2017-12-20 16:14:01	0|wumpus|well it's one of the generated executables
408 2017-12-20 16:17:23	0|Lauda|How does one compile executables for Windows on Unix as well?
409 2017-12-20 16:17:56	0|wumpus|https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md
410 2017-12-20 16:19:07	0|Lauda|On it, thanks
411 2017-12-20 17:01:11	0|bitcoin-git|[13bitcoin] 15laanwj pushed 8 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bc6676514429...79399c8cd0b6
412 2017-12-20 17:01:12	0|bitcoin-git|13bitcoin/06master 14a3603ac 15Jack Grigg: Fix potential overflows in ECDSA DER parsers
413 2017-12-20 17:01:12	0|bitcoin-git|13bitcoin/06master 14e181dbe 15Jack Grigg: Add comments
414 2017-12-20 17:01:13	0|bitcoin-git|13bitcoin/06master 14e4a1086 15Jack Grigg: Update Debian copyright list
415 2017-12-20 17:01:24	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10657: Utils: Improvements to ECDSA key-handling code (06master...06libsecp256k1-patches) 02https://github.com/bitcoin/bitcoin/pull/10657
416 2017-12-20 17:46:34	0|Lauda|is RBF supposed to be rejected if you specify a custom change output?
417 2017-12-20 17:53:06	0|Lauda|i.e. from the same wallet
418 2017-12-20 18:32:19	0|provoostenator|Regarding production DNS seeds, "// Note that of those with the service bits flag, most only support a subset of possible options": sipa does your tool support all of those out of the box or just a subset?
419 2017-12-20 18:36:45	0|sipa|provoostenator: you can configure it
420 2017-12-20 18:37:17	0|sipa|i think the default is fine
421 2017-12-20 18:38:02	0|provoostenator|Ok, I'm using the default. Should I clarify anything in the comment in that case?
422 2017-12-20 18:40:22	0|provoostenator|Also, is your script able to keep the airdrop coin nodes away? Or is that not really a problem?
423 2017-12-20 18:41:56	0|wumpus|they tend to have their own DNS seeds
424 2017-12-20 18:43:21	0|jonasschnelli|provoostenator: default filters: https://github.com/sipa/bitcoin-seeder/blob/master/main.cpp#L150
425 2017-12-20 18:43:24	0|provoostenator|Right, but how does script prevent Bitcoin Core nodes from bootstrapping with a BCash peer and then getting stuck in August 2017 if none of those peers know of any Bitcoin Core peers? Not sure what the odds of that are.
426 2017-12-20 18:43:32	0|jonasschnelli|1, 5, 9, 13...
427 2017-12-20 18:43:39	0|jonasschnelli|I guess we should add NODE_NETWORK_LIMITED there soon
428 2017-12-20 18:43:44	0|jonasschnelli|though... not sure
429 2017-12-20 18:43:58	0|wumpus|jonasschnelli: would there be any reason for nodes to search out NODE_NETWORK_LIMITED peers?
430 2017-12-20 18:44:10	0|wumpus|(I mean specifically)
431 2017-12-20 18:44:50	0|jonasschnelli|That is questionable, but maybe to improve network "health"... but yeah. maybe you don't need that
432 2017-12-20 18:45:08	0|jonasschnelli|Also,... it would have to hide out in non filtering and other filter flags..
433 2017-12-20 18:45:19	0|jonasschnelli|so,... nm, NODE_NETWORK_LIMITED needs not to be there
434 2017-12-20 18:45:28	0|wumpus|yes I understand that as argument to also connect to them, but not to seek them specifically
435 2017-12-20 18:46:09	0|jonasschnelli|indeed. Though you can't mix them with NODE_NETWORK on the seed-db... so peers lern only over getaddr LIMITED nodes
436 2017-12-20 18:46:25	0|jonasschnelli|(once this has been implemented)
437 2017-12-20 18:47:21	0|wumpus|right, true
438 2017-12-20 18:47:46	0|maaku|I've moved some discussion regarding implementation of BIPs 98, 116, and 117 to #bitcoin-mast
439 2017-12-20 18:50:12	0|bitcoin-git|[13bitcoin] 15Sjors opened pull request #11962: [net] add seed.bitcoin.sprovoost.nl to DNS seeds (06master...06dns-seed-sjors) 02https://github.com/bitcoin/bitcoin/pull/11962
440 2017-12-20 18:50:50	0|MarcoFalke|jonasschnelli: Think of the tests as a layer around bitcoin-core, not the other way round ;)
441 2017-12-20 18:51:19	0|jonasschnelli|MarcoFalke: yes. that indeed true.
442 2017-12-20 18:52:04	0|jonasschnelli|Though, I think test environments need to be practical, thats why we have almost no difficulty in regtest,.. and without a static fallback fee, regtests gets pretty unusable
443 2017-12-20 18:52:28	0|jonasschnelli|We could also inject deterministic fee estmation data
444 2017-12-20 18:53:01	0|jonasschnelli|But disabling on regtest means regtest-wallet is only useful with -fallbackfee... this leads me to think it should be there by default
445 2017-12-20 18:53:07	0|jonasschnelli|(no on testnet though)
446 2017-12-20 18:53:27	0|jonasschnelli|Not sure about others, but I use regtest quite often
447 2017-12-20 18:53:37	0|jonasschnelli|(more then mainnet *duck*)
448 2017-12-20 18:55:34	0|jonasschnelli|bloody fee spam on github,.. all during the same time of bcash pump and mempool spam.
449 2017-12-20 18:58:46	0|wumpus|at least I banned the neo-nazi with his secret society nonsense from the org today, anything more?
450 2017-12-20 18:59:27	0|jonasschnelli|No.. the rest is just normal nonblockable spam
451 2017-12-20 19:14:15	0|jonasschnelli|Is there no different way of losing tests into the test_runner.py that would not rais a git conflict all the time? Like autoloading them via readdir()?
452 2017-12-20 19:14:21	0|jonasschnelli|*loading
453 2017-12-20 19:14:49	0|wumpus|yes, that could work
454 2017-12-20 19:15:05	0|wumpus|well except for the order of execution
455 2017-12-20 19:15:26	0|wumpus|you'd have to add metadata for every test as well, in a separate file
456 2017-12-20 19:15:38	0|wumpus|so that they can be sorted by +/- size
457 2017-12-20 19:15:47	0|wumpus|eh s/size/execution time/
458 2017-12-20 19:16:01	0|jonasschnelli|or filename based
459 2017-12-20 19:16:08	0|jonasschnelli|1-flag-testname.py
460 2017-12-20 19:16:11	0|jonasschnelli|(where 1 is the oder)
461 2017-12-20 19:16:14	0|jonasschnelli|*order
462 2017-12-20 19:16:25	0|wumpus|nah
463 2017-12-20 19:16:33	0|wumpus|I'd really prefer not to encode anything into the file name
464 2017-12-20 19:17:20	0|wumpus|we don't want to be renaming tests all the time, that's awfully inconvenient if you want to execute them seprately to test something
465 2017-12-20 19:17:21	0|jonasschnelli|Or directly include the meta in the python file?
466 2017-12-20 19:17:29	0|wumpus|yes, exactly
467 2017-12-20 19:17:31	0|jonasschnelli|Yeah.. that true
468 2017-12-20 19:17:41	0|wumpus|just a comment in a certain format at the top
469 2017-12-20 19:18:17	0|jonasschnelli|Yeah.. ping MarcoFalke ^
470 2017-12-20 19:18:26	0|jonasschnelli|Let me do an issue
471 2017-12-20 19:20:32	0|sipa|or what about a test that checks every functional test is listed in test_runner.py?
472 2017-12-20 19:21:36	0|wumpus|we already have that
473 2017-12-20 19:22:28	0|sipa|oh.
474 2017-12-20 19:23:30	0|wumpus|check_script_list() in test_runner.py
475 2017-12-20 19:23:39	0|sipa|then what's the problem?
476 2017-12-20 19:23:45	0|wumpus|merge conflicts
477 2017-12-20 19:23:56	0|sipa|that seems to solve the risk of accidentally lose things in the list
478 2017-12-20 19:24:26	0|wumpus|yes, that it does, it's just that it doesn't prevent having to rebase, jonasschnelli's comment was more about avoiding the hotspot
479 2017-12-20 19:25:18	0|sipa|ah, i see
480 2017-12-20 19:25:44	0|jonasschnelli|I did at least 5 rebases the last two weeks because of the test_runner hotspot
481 2017-12-20 19:26:03	0|jonasschnelli|Not problematic,... but maybe it can be solved in a way where things get even more simple
482 2017-12-20 19:26:18	0|jonasschnelli|(just placing a test script into the right directory seems more elegant)
483 2017-12-20 19:27:24	0|wumpus|yes, I agree
484 2017-12-20 19:28:22	0|jonasschnelli|Though it would be another larger change in the test framework. Everytime I write a new test, something is new,... :)
485 2017-12-20 19:28:45	0|wumpus|lots of changes to the test framework lately
486 2017-12-20 19:36:51	0|wumpus|what did they change them into this time
487 2017-12-20 19:44:34	0|MarcoFalke|re: jonasschnelli Place them at random locations
488 2017-12-20 19:44:47	0|MarcoFalke|I don't get why everyone puts them in the last line
489 2017-12-20 19:45:09	0|MarcoFalke|They are supposed to be sorted by approximate run-time, not date of insertion
490 2017-12-20 19:45:35	0|MarcoFalke|We should add a comment in the last line to not put any tests there
491 2017-12-20 19:45:49	0|jonasschnelli|Heh.. yes. Your right,.... but would you not also prefere the auto-loading approach? Or what downsides do you see?
492 2017-12-20 19:46:57	0|MarcoFalke|Some of the files that end in ".py" are not test scripts
493 2017-12-20 19:47:07	0|sipa|jonasschnelli: how do you determine the order of auto loaded tests?
494 2017-12-20 19:47:12	0|MarcoFalke|and that
495 2017-12-20 19:47:56	0|sipa|we could move the timing information to the test files themselves, and then use that to determine the order
496 2017-12-20 19:48:04	0|jonasschnelli|sipa: with some metadata in the test script (header)
497 2017-12-20 19:48:04	0|MarcoFalke|And we'd have to write a test for the auto-loader
498 2017-12-20 19:48:10	0|sipa|in that case we could get rid of the hardcoded lists entirely
499 2017-12-20 19:48:49	0|MarcoFalke|Hmm, I am really scared of not running tests
500 2017-12-20 19:48:56	0|MarcoFalke|I.e. the autoloader skips tests
501 2017-12-20 19:49:00	0|jonasschnelli|also, if you change a test, so it will consume more time, you need to shuffle stuff...
502 2017-12-20 19:49:31	0|jonasschnelli|The script list in test_runner seems redundant info to me
503 2017-12-20 19:49:33	0|MarcoFalke|jonasschnelli: Not too important. The time is measured in the order of minutes
504 2017-12-20 19:49:54	0|jonasschnelli|But it's just a though....
505 2017-12-20 19:50:21	0|MarcoFalke|s/minutes/10s-of-seconds/
506 2017-12-20 19:52:10	0|MarcoFalke|So even if we did the autoloader, I'd only feel comfortable doing it if we hardcoded the test list or at least the number of tests that are supposed to be run.
507 2017-12-20 19:57:14	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #11965: qa: Note on test order in test_runner (06master...06Mf1712-qaTestRunnerOrder) 02https://github.com/bitcoin/bitcoin/pull/11965
508 2017-12-20 20:08:51	0|luke-jr|wumpus: yet another digit added to commit hashes, it appears
509 2017-12-20 20:10:13	0|luke-jr|maybe we should just use the full hash in the code
510 2017-12-20 20:24:38	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11918: fees: Remove fallbackfee default (06master...06Mf1712-NoFallBackFee) 02https://github.com/bitcoin/bitcoin/pull/11918
511 2017-12-20 20:28:49	0|wumpus|luke-jr: you mean in the embedded version hash? yes, I think that'd make sense
512 2017-12-20 20:47:52	0|MarcoFalke|wumpus: Any thoughts on #11517 ?
513 2017-12-20 20:47:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/11517 | Tests: Improve benchmark precision by martinus · Pull Request #11517 · bitcoin/bitcoin · GitHub
514 2017-12-20 20:48:05	0|MarcoFalke|imo, it is ready
515 2017-12-20 20:48:30	0|MarcoFalke|But I wanted to see if you have any opinion, since it is basically a re-write
516 2017-12-20 20:51:52	0|wumpus|seems it needs rebase again, but no not really have an opinion on it, if manually specifying the number of iterations works better for precious that's ok with me
517 2017-12-20 20:52:01	0|wumpus|precision*
518 2017-12-20 20:53:30	0|wumpus|not sure how the changes to check-doc.py belong in there though
519 2017-12-20 20:54:44	0|MarcoFalke|bench is also "test", I assume. Since it is a rewrite of bench, might as well fix that up
520 2017-12-20 20:55:23	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #11966: clientversion: Use full commit hash for commit-based version descriptions (06master...06ver_full_commit_hash) 02https://github.com/bitcoin/bitcoin/pull/11966
521 2017-12-20 20:57:34	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #11967: Add script to test the dns seeds (06master...062017/12/seed_test) 02https://github.com/bitcoin/bitcoin/pull/11967
522 2017-12-20 22:40:10	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/79399c8cd0b6...604e08c83cf5
523 2017-12-20 22:40:11	0|bitcoin-git|13bitcoin/06master 14aac6b3f 15MeshCollider: Update files.md for new wallets/ subdirectory
524 2017-12-20 22:40:11	0|bitcoin-git|13bitcoin/06master 14b673429 15MeshCollider: Cleanups for walletdir PR
525 2017-12-20 22:40:12	0|bitcoin-git|13bitcoin/06master 14604e08c 15MarcoFalke: Merge #11726: Cleanups + nit fixes for walletdir PR...
526 2017-12-20 22:40:39	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11726: Cleanups + nit fixes for walletdir PR (06master...06201711_walletdir) 02https://github.com/bitcoin/bitcoin/pull/11726
527 2017-12-20 22:59:26	0|cfields|gmaxwell: just to clarify, all that's needed upfront for the threshold signing for apple codesigning is a properly signed csr with the (not-yet-existing) new pubkey shoved in, right?
528 2017-12-20 23:00:06	0|cfields|obviously the pubkey will be shoved in, then the signature generated as a second step
529 2017-12-20 23:01:34	0|cfields|if so, looks straightforward, just need to figure out how the digest is calculated
530 2017-12-20 23:24:06	0|bitcoin-git|[13bitcoin] 15Raizen opened pull request #11968: Update consensus.h (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11968
531 2017-12-20 23:26:44	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11968: Update consensus.h (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11968