1 2018-02-03 01:36:22	0|bitcoin-git|[13bitcoin] 15RvMp opened pull request #12341: Correction in choice of words (06master...06201802030229-qt-dutch-lang-fix) 02https://github.com/bitcoin/bitcoin/pull/12341
  2 2018-02-03 01:52:38	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #12341: Correction in choice of words in QT (dutch) (06master...06201802030229-qt-dutch-lang-fix) 02https://github.com/bitcoin/bitcoin/pull/12341
  3 2018-02-03 05:59:09	0|phantomcircuit|does the validateaddress rpc work with segwit addresses?
  4 2018-02-03 05:59:33	0|gmaxwell|you mean bc1 addresses? it should. lemme se...
  5 2018-02-03 06:00:37	0|sipa|absolutely
  6 2018-02-03 06:00:46	0|sipa|it also works with p2sh-p2wpkh addresses
  7 2018-02-03 06:01:24	0|sipa|(and will look through the P2SH and give you the pubkey etc)
  8 2018-02-03 06:01:25	0|gmaxwell|yes, it does.
  9 2018-02-03 06:03:42	0|phantomcircuit|alrighty
 10 2018-02-03 06:03:46	0|phantomcircuit|guess i cant type
 11 2018-02-03 06:06:20	0|gmaxwell|or you're trying code prior to 0.16rc?
 12 2018-02-03 06:08:55	0|jarthur|Hey. gmax mentioned sipa's SHA-NI branch to me the other day. Is that the latest go at bringing those instructions in?
 13 2018-02-03 06:14:10	0|gmaxwell|I think that branch is just lacking build system integration.
 14 2018-02-03 06:39:38	0|windsok|I'm running 0.16rc2, normally my debug.log is full of messages of other nodes connecting to my node. With 0.16 i'm not seeing that, and i'm seeing lots of messages like "version handshake timeout from 1113". Maybe it's nothing, but thought i'd mention it. I can open an issue if someone think's it's worth investigating
 15 2018-02-03 06:41:46	0|gmaxwell|windsok: do you have any connections at all?
 16 2018-02-03 06:41:54	0|gmaxwell|some amount of version handshake timeouts are normal.
 17 2018-02-03 06:41:58	0|windsok|yes, I'm receiving blocks
 18 2018-02-03 06:43:08	0|windsok|getnetworkinfo shows 29 connections
 19 2018-02-03 06:44:26	0|windsok|just find it weird i'm not seeing the normal connection messages. Normally I see those spy nodes connecting at least every few minutes
 20 2018-02-03 06:44:33	0|gmaxwell|e.g. A node here I have got 764 handshake timeouts on 2017-11-23 (on obviously much older code)
 21 2018-02-03 06:45:36	0|gmaxwell|and 912 a day ago.
 22 2018-02-03 06:47:01	0|gmaxwell|grep  'receive version' debug.log  ? do you see any at all?
 23 2018-02-03 06:47:05	0|gmaxwell|I see spy things
 24 2018-02-03 06:48:26	0|windsok|no receive version messages since I upgraded
 25 2018-02-03 06:48:41	0|gmaxwell|oh hm. logging change then.
 26 2018-02-03 06:48:45	0|gmaxwell|what debug level are you?
 27 2018-02-03 06:49:03	0|windsok|whatever the default is
 28 2018-02-03 06:49:11	0|gmaxwell|ah!
 29 2018-02-03 06:49:43	0|gmaxwell|#11583
 30 2018-02-03 06:49:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/11583 | Do not make it trivial for inbound peers to generate log entries by TheBlueMatt · Pull Request #11583 · bitcoin/bitcoin · GitHub
 31 2018-02-03 06:50:24	0|gmaxwell|though derp, BlueMatt the version handshake timeout should have gotten covered under that I think!
 32 2018-02-03 06:54:36	0|windsok|ah, so it should be logging those at default level? or you now need debug logging to see them?
 33 2018-02-03 06:55:01	0|gmaxwell|you need debug level to see them now.
 34 2018-02-03 06:55:19	0|gmaxwell|the goal of the change was to prevent peers from spamming your logs
 35 2018-02-03 06:57:19	0|windsok|cool, i'll turn debug logging on and check they are back
 36 2018-02-03 06:58:10	0|windsok|weirdly, I like to watch those logs sometimes, to see what random nodes are connecting to me
 37 2018-02-03 06:58:26	0|Randolf|That's good.
 38 2018-02-03 06:59:02	0|Randolf|That way the log files, by default, are more focused on the more important things, and are smaller (easier to grep, etc.).
 39 2018-02-03 07:03:02	0|windsok|yeah i see them with debug=net. crapton of logging with that on though hah
 40 2018-02-03 07:04:51	0|gmaxwell|you can turn logging levels on and off using the logging rpc.
 41 2018-02-03 07:10:25	0|Randolf|It's reasonable to assume that an administrator who selects a more detailed logging level will be expecting more logging activity.  A default logging level that leaves out unnecessary entries such as things that can appear as spam is a good choice.
 42 2018-02-03 07:56:00	0|dafuq|could i get a pointer to where in the src the code for DLing the blk*.dat is located?
 43 2018-02-03 07:58:59	0|ossifrage|I'd include "version handshake timeout from " in the list of trivial for a peer to generate a log entry
 44 2018-02-03 08:01:54	0|ossifrage|37% of the log default log entries for a node that has been up for ~24hrs was "version handshake timeout..."
 45 2018-02-03 08:05:53	0|gmaxwell|ossifrage: that was my comment to bluematt above.
 46 2018-02-03 08:06:06	0|gmaxwell|ossifrage: care to go make the pull request yourself? it'll be easy.
 47 2018-02-03 08:24:05	0|ossifrage|gmaxwell, I'm somewhat curious who all those connections are coming from? Does the connecting side need to send any data to get that message?
 48 2018-02-03 08:24:26	0|gmaxwell|nope
 49 2018-02-03 08:24:41	0|ossifrage|gmaxwell, ah, so it could just be port scanners
 50 2018-02-03 08:24:45	0|gmaxwell|yep
 51 2018-02-03 08:31:18	0|ossifrage|Ouch, a one line change to src/net.cpp and a shitload of stuff needs to be recompiled :-(
 52 2018-02-03 08:35:57	0|gmaxwell|it's just relinking the different commands that use net.cpp
 53 2018-02-03 08:39:32	0|windsok|socket recv error Connection reset by peer (104)
 54 2018-02-03 08:39:32	0|windsok|socket recv error Connection timed out (110)
 55 2018-02-03 08:39:38	0|windsok|those are also very common messages in my logs
 56 2018-02-03 08:54:04	0|ossifrage|another common one is "ERROR: non-continuous headers sequence" (some brain damaged fork coin)
 57 2018-02-03 08:54:27	0|gmaxwell|that one is especially unfortunate because it displays the word ERROR
 58 2018-02-03 08:54:55	0|gmaxwell|some small fraction of users will commit electronic suicide if they see error messages in their logs.
 59 2018-02-03 08:55:06	0|gmaxwell|(e.g. delete their wallets trying to make it stop)
 60 2018-02-03 08:55:16	0|ossifrage|Maybe there should be a different term for things that will get you banned (instead of ERROR)
 61 2018-02-03 08:56:05	0|gmaxwell|Mostly "ERROR" was previously elimiated from that stuff, I think that one just got missed.
 62 2018-02-03 08:56:13	0|ossifrage|Or combine the Misbehaving line with the reason for the misbehaving?
 63 2018-02-03 08:57:40	0|ossifrage|gmaxwell, that trivial change requires forking (and recompiling from scratch for sanity) just to make github happy
 64 2018-02-03 09:01:18	0|ossifrage|Would "Misbehaving: non-continuous headers sequence" be better?
 65 2018-02-03 09:01:39	0|gmaxwell|It think it would be if it were straight forward to do that.
 66 2018-02-03 09:02:13	0|gmaxwell|and that should also be a NET log entrie, under the 11583  logic I think?
 67 2018-02-03 09:03:40	0|ossifrage|Ah, yeah that comes back as an error("...")
 68 2018-02-03 09:15:05	0|bitcoin-git|[13bitcoin] 15clemtaylor opened pull request #12342: Extend #11583 to include "version handshake timeout" message (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/12342
 69 2018-02-03 09:20:35	0|ossifrage|In my local copy I have an command line option to specify the upload time frame: "-maxuploadtimeframe". I set this to 1hr vs the default of 24hrs to help smooth out the bandwidth usage for old blocks
 70 2018-02-03 16:33:40	0|bitcoin-git|[13bitcoin] 15Rutkouski opened pull request #12345:  Asymmetric encryption stubs. (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/12345
 71 2018-02-03 19:42:10	0|gmaxwell|sipa: close #12345  (so sad that a cool number was wasted on shitty PR spam)
 72 2018-02-03 19:42:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/12345 | Asymmetric encryption stubs. by Rutkouski · Pull Request #12345 · bitcoin/bitcoin · GitHub
 73 2018-02-03 19:49:19	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #12345:  Asymmetric encryption stubs. (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/12345
 74 2018-02-03 20:06:30	0|BlueMatt|gmaxwell: seems reasonable, though thats at least hard to fill up your disk with, cause you can only do it 120 at a time
 75 2018-02-03 20:12:45	0|gmaxwell|BlueMatt: I don't see how thats any different from version handshakes. :)
 76 2018-02-03 20:12:58	0|gmaxwell|ah because there is a timeout
 77 2018-02-03 20:13:05	0|BlueMatt|yea...that :p
 78 2018-02-03 20:13:09	0|gmaxwell|well still flooding logs with uninteresting stuff,...
 79 2018-02-03 20:13:14	0|BlueMatt|true
 80 2018-02-03 20:13:28	0|BlueMatt|i mean doesnt meet the "dont let them fill your disk" criteria, but does meet the "this is useless" criteria
 81 2018-02-03 20:24:17	0|rhavar|Anyone interested in coin selection?
 82 2018-02-03 20:24:47	0|rhavar|I just took 3 or 4 months of work on it, and exposed it over a JSON api if anyone wants to screw around: coinsayer.com
 83 2018-02-03 20:27:13	0|rhavar|It should be pretty useful for testing stuff, like making sure the BnB algo doesn't miss any cases
 84 2018-02-03 20:28:11	0|Murch|cool
 85 2018-02-03 20:28:17	0|Murch|What does it consider?
 86 2018-02-03 20:28:42	0|rhavar|take a look at the problem.json thing
 87 2018-02-03 20:29:04	0|rhavar|It's most optimized for a service though, esp one that has more incoming transactions than out going
 88 2018-02-03 20:29:52	0|rhavar|But it takes as an argument the estimated future cost of transactions (consolidationFee)   so it works very well in general
 89 2018-02-03 20:32:47	0|Murch|sorry, I meant what strategy you came up with to make the perfect transactions. ;)
 90 2018-02-03 20:32:48	0|rhavar|I need to fully document it, but it supports some stuff that I don't think have been implemented before. Like mandatory conflict sets  (for instance if you want to bip125 transactions) and the concept of optional outputs  (e.g. if you're a service and have a bunch of queued withdrawals, you don't necessarily need to send them all )
 91 2018-02-03 20:33:01	0|Murch|Ah nice.
 92 2018-02-03 20:33:37	0|rhavar|And it scales pretty well, has no problems with >10k+ inputs and stuff
 93 2018-02-03 20:34:29	0|rhavar|There might be some minor bugs (i literally just refactored it all to expose it as a service) but the core algorithm has been used extremely successfully in production for months (and leads to easily >50% fee savings over core's  selection algo)
 94 2018-02-03 20:36:14	0|rhavar|oh yeah, and it has pretty amazing privacy benefits. it basically totally destroys all the current clustering analytic companies lol
 95 2018-02-03 20:36:43	0|rhavar|(basically by avoiding change, or having change outputs that are unpredictable ..  it makes clustering very ineffective)
 96 2018-02-03 20:37:25	0|rhavar|(That is assuming you don't reuse addresses though, as that will make it far easier to cluster)
 97 2018-02-03 20:38:18	0|Murch|Sounds interesting
 98 2018-02-03 20:39:13	0|Murch|Although no address reuse is a bit a strong assumption, as others can just send to your address again at their leisure
 99 2018-02-03 20:39:35	0|rhavar|yeah, i have witnessed that
100 2018-02-03 20:39:36	0|Murch|I'm hoping that we generally see a stronger move to avoiding change soon ;)
101 2018-02-03 20:39:50	0|rhavar|i think i created some issues on the bitcoin repo to deal with that
102 2018-02-03 20:40:01	0|rhavar|But if you're doing it manually, you can manually expire addresses
103 2018-02-03 20:40:15	0|rhavar|which makes the dusting attacks useless
104 2018-02-03 20:40:26	0|Murch|yeah, makes sense
105 2018-02-03 20:43:12	0|rhavar|but in general this coin selection handles dusting a lot better anyway, because it never spends uneconomical coins. And from what I can tell, to save money all the deanonymizing dust is sent with tiny amounts that never really make sense to spend anyway
106 2018-02-03 21:02:09	0|Murch|yeah, opinions vary a bit here, but Bitcoin Core should probably be more selective in spending uneconomic unspents.
107 2018-02-03 21:03:45	0|rhavar|the current behavior is pretty indefensible, last year i saw an attack against a major casino where they created transactions with a lot of output targetting deposit addresses. Then withdraw the money
108 2018-02-03 21:04:02	0|rhavar|and then core's coin selection picks those outputs, and burns mega amounts of money
109 2018-02-03 21:04:28	0|rhavar|you can basically cost someone like ~30x the cost to send the transaction, the cost to clean it up
110 2018-02-03 21:04:49	0|rhavar|so if nothing else, it's a massive DoS vector
111 2018-02-03 23:13:40	0|quer_|Is there a website/tool where I can do the math for: Which minimal input amount (Sat) is feasible with fee (Sat/Byte) and tx size (tx type, input/output count, etc.) ? So I know when I should consolidate my dust?
112 2018-02-03 23:16:06	0|windsok|rhavar: sounds very cool. Is the code open?
113 2018-02-03 23:17:23	0|GAit|is support for 32 bit builds here to stay or going away in a few releases? i recall some PR or issue discussion but can't find it
114 2018-02-03 23:36:16	0|meshcollider|GAit: perhaps you're thinking of #9989 or something?
115 2018-02-03 23:36:18	0|gribble|https://github.com/bitcoin/bitcoin/issues/9989 | [Doc] Removing references to Windows 32 bit from README by NicolasDorier · Pull Request #9989 · bitcoin/bitcoin · GitHub
116 2018-02-03 23:37:52	0|meshcollider|I don't think there's any plan to remove 32 bit support any time soon at least
117 2018-02-03 23:57:55	0|rhavar|windsok: not really, it's not really something that is suitable for upstreaming at all due to it's reliance on constraint solvers
118 2018-02-03 23:58:09	0|rhavar|just useful to test against, and make sure you're not missing anything obvious