< bitcoin-git>
[bitcoin] fanquake closed pull request #12341: Correction in choice of words in QT (dutch) (master...201802030229-qt-dutch-lang-fix) https://github.com/bitcoin/bitcoin/pull/12341
< phantomcircuit>
does the validateaddress rpc work with segwit addresses?
< gmaxwell>
you mean bc1 addresses? it should. lemme se...
< sipa>
absolutely
< sipa>
it also works with p2sh-p2wpkh addresses
< sipa>
(and will look through the P2SH and give you the pubkey etc)
< gmaxwell>
yes, it does.
< phantomcircuit>
alrighty
< phantomcircuit>
guess i cant type
< gmaxwell>
or you're trying code prior to 0.16rc?
< jarthur>
Hey. gmax mentioned sipa's SHA-NI branch to me the other day. Is that the latest go at bringing those instructions in?
< gmaxwell>
I think that branch is just lacking build system integration.
< 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
< gmaxwell>
windsok: do you have any connections at all?
< gmaxwell>
some amount of version handshake timeouts are normal.
< windsok>
yes, I'm receiving blocks
< windsok>
getnetworkinfo shows 29 connections
< 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
< gmaxwell>
e.g. A node here I have got 764 handshake timeouts on 2017-11-23 (on obviously much older code)
< gmaxwell>
and 912 a day ago.
< gmaxwell>
grep 'receive version' debug.log ? do you see any at all?
< gmaxwell>
I see spy things
< windsok>
no receive version messages since I upgraded
< gmaxwell>
oh hm. logging change then.
< gmaxwell>
what debug level are you?
< windsok>
whatever the default is
< gmaxwell>
ah!
< gmaxwell>
#11583
< 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
< gmaxwell>
though derp, BlueMatt the version handshake timeout should have gotten covered under that I think!
< windsok>
ah, so it should be logging those at default level? or you now need debug logging to see them?
< gmaxwell>
you need debug level to see them now.
< gmaxwell>
the goal of the change was to prevent peers from spamming your logs
< windsok>
cool, i'll turn debug logging on and check they are back
< windsok>
weirdly, I like to watch those logs sometimes, to see what random nodes are connecting to me
< Randolf>
That's good.
< Randolf>
That way the log files, by default, are more focused on the more important things, and are smaller (easier to grep, etc.).
< windsok>
yeah i see them with debug=net. crapton of logging with that on though hah
< gmaxwell>
you can turn logging levels on and off using the logging rpc.
< 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.
< dafuq>
could i get a pointer to where in the src the code for DLing the blk*.dat is located?
< ossifrage>
I'd include "version handshake timeout from " in the list of trivial for a peer to generate a log entry
< ossifrage>
37% of the log default log entries for a node that has been up for ~24hrs was "version handshake timeout..."
< gmaxwell>
ossifrage: that was my comment to bluematt above.
< gmaxwell>
ossifrage: care to go make the pull request yourself? it'll be easy.
< 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?
< gmaxwell>
nope
< ossifrage>
gmaxwell, ah, so it could just be port scanners
< gmaxwell>
yep
< ossifrage>
Ouch, a one line change to src/net.cpp and a shitload of stuff needs to be recompiled :-(
< gmaxwell>
it's just relinking the different commands that use net.cpp
< windsok>
socket recv error Connection reset by peer (104)
< windsok>
socket recv error Connection timed out (110)
< windsok>
those are also very common messages in my logs
< ossifrage>
another common one is "ERROR: non-continuous headers sequence" (some brain damaged fork coin)
< gmaxwell>
that one is especially unfortunate because it displays the word ERROR
< gmaxwell>
some small fraction of users will commit electronic suicide if they see error messages in their logs.
< gmaxwell>
(e.g. delete their wallets trying to make it stop)
< ossifrage>
Maybe there should be a different term for things that will get you banned (instead of ERROR)
< gmaxwell>
Mostly "ERROR" was previously elimiated from that stuff, I think that one just got missed.
< ossifrage>
Or combine the Misbehaving line with the reason for the misbehaving?
< ossifrage>
gmaxwell, that trivial change requires forking (and recompiling from scratch for sanity) just to make github happy
< ossifrage>
Would "Misbehaving: non-continuous headers sequence" be better?
< gmaxwell>
It think it would be if it were straight forward to do that.
< gmaxwell>
and that should also be a NET log entrie, under the 11583 logic I think?
< ossifrage>
Ah, yeah that comes back as an error("...")
< bitcoin-git>
[bitcoin] clemtaylor opened pull request #12342: Extend #11583 to include "version handshake timeout" message (master...master) https://github.com/bitcoin/bitcoin/pull/12342
< 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
< 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
< gmaxwell>
BlueMatt: I don't see how thats any different from version handshakes. :)
< gmaxwell>
ah because there is a timeout
< BlueMatt>
yea...that :p
< gmaxwell>
well still flooding logs with uninteresting stuff,...
< BlueMatt>
true
< BlueMatt>
i mean doesnt meet the "dont let them fill your disk" criteria, but does meet the "this is useless" criteria
< rhavar>
Anyone interested in coin selection?
< 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
< rhavar>
It should be pretty useful for testing stuff, like making sure the BnB algo doesn't miss any cases
< Murch>
cool
< Murch>
What does it consider?
< rhavar>
take a look at the problem.json thing
< rhavar>
It's most optimized for a service though, esp one that has more incoming transactions than out going
< rhavar>
But it takes as an argument the estimated future cost of transactions (consolidationFee) so it works very well in general
< Murch>
sorry, I meant what strategy you came up with to make the perfect transactions. ;)
< 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 )
< Murch>
Ah nice.
< rhavar>
And it scales pretty well, has no problems with >10k+ inputs and stuff
< 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)
< rhavar>
oh yeah, and it has pretty amazing privacy benefits. it basically totally destroys all the current clustering analytic companies lol
< rhavar>
(basically by avoiding change, or having change outputs that are unpredictable .. it makes clustering very ineffective)
< rhavar>
(That is assuming you don't reuse addresses though, as that will make it far easier to cluster)
< Murch>
Sounds interesting
< Murch>
Although no address reuse is a bit a strong assumption, as others can just send to your address again at their leisure
< rhavar>
yeah, i have witnessed that
< Murch>
I'm hoping that we generally see a stronger move to avoiding change soon ;)
< rhavar>
i think i created some issues on the bitcoin repo to deal with that
< rhavar>
But if you're doing it manually, you can manually expire addresses
< rhavar>
which makes the dusting attacks useless
< Murch>
yeah, makes sense
< 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
< Murch>
yeah, opinions vary a bit here, but Bitcoin Core should probably be more selective in spending uneconomic unspents.
< 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
< rhavar>
and then core's coin selection picks those outputs, and burns mega amounts of money
< rhavar>
you can basically cost someone like ~30x the cost to send the transaction, the cost to clean it up
< rhavar>
so if nothing else, it's a massive DoS vector
< 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?
< windsok>
rhavar: sounds very cool. Is the code open?
< 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
< meshcollider>
GAit: perhaps you're thinking of #9989 or something?