< kallewoof>
A full node of mine is banning peers left and right and I'm seeing a ton of "ERROR: non-continuous headers sequence". Running master, switching to 0.15 to see if it goes away.
< wumpus>
kallewoof: weird! I've never seen that error
< sdaftuar>
kallewoof: if you have debug logs you can post somewhere, i'd be interested in investigating
< sdaftuar>
wumpus: kallewoof: i think i've seen it before with clock issues and the 2 hour rule on testnet, but don't think i've ever seen it on mainnet
< bitcoin-git>
[bitcoin] Sjors opened pull request #12216: scripted-diff: prefix [address|change]type parameters with 'default' (master...2018/01/defaultaddresstype) https://github.com/bitcoin/bitcoin/pull/12216
< provoostenator>
^ I'm lazily relying on Travs to check the scripted diff, because it uses sed in an OSX / BSD unfriendly way.
< provoostenator>
Oh great, OSX requires sed -i '' 's/changetype/defaultchangetype/g' whereas linux doesn't allow that.
< wumpus>
isn't that the other way around? I'm fairly sure linux has sed -i but various BSDs have not
< provoostenator>
OSX requires an empty string as the first argument.
< provoostenator>
(before the actual /s)
< wumpus>
but yes writing portable shellscript is frustrating, remebering the many ways we have to use to do a basic thing like sha256 verification in the bdb install script
< bitcoin-git>
bitcoin/master fa1e69e MarcoFalke: qa: Sync with validationinterface queue in sync_mempools
< bitcoin-git>
bitcoin/master 898f560 Wladimir J. van der Laan: Merge #12206: qa: Sync with validationinterface queue in sync_mempools...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12206: qa: Sync with validationinterface queue in sync_mempools (master...Mf1801-qaWalletMempoolAsync) https://github.com/bitcoin/bitcoin/pull/12206
< Tport>
hello
< Tport>
where are API of bitcoin network?
< wumpus>
test 97 of p2p-fullblocktest.py is consistently failing here, weird
< gmaxwell>
I feel dejavu at that.
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #12217: qa: Add missing syncwithvalidationinterfacequeue to tests (master...Mf1801-qaWalletMempoolAsyncTake2) https://github.com/bitcoin/bitcoin/pull/12217
< Tport>
is anyone can send me 0.001 btc to test?
< Tport>
0.005 sorry
< wumpus>
Tport: testnet?
< Tport>
no, real
< wumpus>
go away, no begging here
< Tport>
i'am developing crypto stock exchange, i need to able to send blocks to differents puls, what is the right way?
< wumpus>
take it to #bitcoin please
< Tport>
#bitcoin channel ?
< wumpus>
yes
< wumpus>
hrm on another host, p2p-fullblocktest.py works fine
< MarcoFalke>
ups. My znc shut down and I lost the backscroll of last week or so.
< wumpus>
I'll pastebin it
< MarcoFalke>
wumpus: I will use botbot
< MarcoFalke>
.me
< wumpus>
ok
< MarcoFalke>
I was wondering if syncwithvalidationinterfacequeue should be a not-hidden rpc. I could imagine some user does this:
< MarcoFalke>
wallet.listunspent(); create and sign raw tx; sendrawtx; wallet.some_rpc_that_is_not_in_sync
< MarcoFalke>
()
< wumpus>
maybe, but not for 0.16, I'm not convinced having to explicitly call a sync call is a good idea for end users
< wumpus>
seems to have a lot of foot-shooting potential, it's fine for fixing intermittent test failures for now, but I don't like it much as API
< MarcoFalke>
Then, maybe sendraw should do that internally
< wumpus>
MarcoFalke: it does
< MarcoFalke>
oh, then it is fine, I think.
< wumpus>
it doesn't call SyncWithValidationInterfaceQueue, but does the same thing manually
< wumpus>
(not sure why it doesn't just use that call)
< kallewoof>
wumpus: for some reason my debug.log is empty, but i have a screen with -printtoconsole.
< wumpus>
printtoconsole doesn't write to debug.log
< wumpus>
kallewoof: please use a pastebin for lots of text, don't paste all of that into my PM
< wumpus>
it keeps putting up notifications here now :/
< kallewoof>
Sorry!
< wumpus>
master doesn't log version messages anymore for newly connected nodes?
< wumpus>
that's kind of annoying, trying to correlate MISBEHAVING peer=X to connections, but they're not logged anymore
< wumpus>
when did this change?
< gmaxwell>
FWIW, misbehaving, there are a lot of "bitcoin gold" nodes causing misbehaving messages.
< wumpus>
is that possibly the "ERROR: non-continuous headers sequence"?
< gmaxwell>
Yes.
< gmaxwell>
Thats it.
< wumpus>
kallewoof: ^^
< gmaxwell>
I dunno about the logging change, I don't recall it changing but I do recall discussing it.
< wumpus>
should also stop logging MISBEHAVING and other network things then
< gmaxwell>
(The reason to not log it is because logging any text from third parties is a potential attack, nussance spam vector.)
< wumpus>
it makes no sense to log those, with peer numbers, without being able to correlate them
< gmaxwell>
if they're still connected you can go look at the peer info.
< wumpus>
no this is for post-mortem analysis
< wumpus>
I've banned them long time ago
< wumpus>
(automatically)
< wumpus>
well this is also a nuisance vector like this :(
< gmaxwell>
right but the misbehaving log entries still happen before the banning.
< gmaxwell>
There were some incidents in the past with people connecting in a tight loop with their version strings set to webservices addresses and what not.... but I still don't remember the behavior changing.
< wumpus>
ok I understand that change then, but then these should also move to ::NET category
< wumpus>
maybe Misbehaving() should take a message so that it can at leaswt be logged on the same line
< adiabat>
I get lots of that kind of thing in the log; non-continuous headers sequence, also bad-diffbits, incorrect proof of work (code 16)
< adiabat>
the latter seems to be from "/WorldBitcoin:0.16.1/"... whatever that is
< sdaftuar>
gmaxwell: i got around to doing a little investigation, looks like there was some sigops attack stuff happening back in november 2015, and i appear to have data from back then
< sdaftuar>
so presumably i should have a way to simulate and evaluate alternate options if you have something to try
< bitcoin-git>
[bitcoin] laanwj opened pull request #12218: net: Move misbehaving logging to net logging category (master...2018_01_misbehaving_logging) https://github.com/bitcoin/bitcoin/pull/12218
< wumpus>
argh, running with debug=net gives me way too much logging output, I wish there was a low-traffic net category
< wumpus>
which just logs the stuff that used to be logged unconditionally
< wumpus>
I don't want every single message or requested transaction :/
< jnewbery>
in general, log levels would be nice, and the ability to set different levels for different catagories (rather than just on/off)
< wumpus>
yeah...
< wumpus>
this really makes net logging unusable for me :/
< jnewbery>
wumpus, for your failing p2p-fullblocktest: running master? running with --enable-debug? Which line in p2p-fullblocktest is failing (you should have an INFO log like 2017-12-12 12:46:23.112000 TestFramework.comptool (INFO): Running test 99: test/functional/p2p-fullblocktest.py line 1283
< wumpus>
hm I don't actually know if I'm running with --enable-debug
< instagibbs>
almost #bitcoin but not quite: in master is there any way to back out legacy addresses from (p2sh)-p2wpkh addresses from -cli or elsewhere?
< wumpus>
(I did enable debug to test that, it might still be on, that'd explain something!)
< instagibbs>
aside from self-computing using pubkey of course :)
< wumpus>
jnewbery: yep, I'm running debug build, will try to rebuild in release mode
< wumpus>
instagibbs: I don't know
< wumpus>
but let me check first what line the error happens
< wumpus>
"OSError: [Errno 28] No space left on device" oops
< wumpus>
hehe /tmp was 30GB, lots of abandoned test files after failed tests
< provoostenator>
Can we get binaries for Ubuntu 18.04 bionic?
< wumpus>
provoostenator: I don't understand what you mean
< achow101>
according to rusty, they're called sipas
< wumpus>
lol oh no, not more things for 0.16.0, do we ever want to release this
< gmaxwell>
booyah: weight isn't directly comparible to the fee units people have gotten used to.
< meshcollider>
booyah: using weight means factor of 4 difference in the actual number which will confuse people I think
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #12221: RFC: Rename -walletdir option to -walletsdir (scripted-diff) (master...pr/wdren) https://github.com/bitcoin/bitcoin/pull/12221
< gmaxwell>
wallet'sdir ?
< gmaxwell>
:P
< wumpus>
noooo
< kanzure>
multiwalletdir?
< wumpus>
just stick to walletdir, don't add a s in there please
< gmaxwell>
ack
< wumpus>
I'll forget that every time
< phantomcircuit>
shouldn't the change script type match the payment type for sendtoaddress ?
< phantomcircuit>
regardless of whether it's segwit or not
< wumpus>
again, not the entire documentation of an option needs to be in the option name
< gmaxwell>
phantomcircuit: 11:13:52 < sipa> phantomcircuit: there's a PR for that
< wumpus>
keeping option names short in general is good
< phantomcircuit>
ok
< kanzure>
options should be replaced by hexadecimal identifiers, so that documentation must be consulted?
< phantomcircuit>
(got disconnected didn't think that went through)
< * kanzure>
hides
< sipa>
kanzure: double-SHA256 of the english description of the option, so that you show you've actually read the documentation
< * sipa>
hides more
< gmaxwell>
phantomcircuit: to at least a limited extent, if the wallet is allowed to use segwit (not legacy mode), then it'll toggle between native segwit and p2sh based on the outputs.
< jcorgan>
bech32 would be how the hipsters would do it
< gmaxwell>
phantomcircuit: I'd like to see that PR get merged because it should increase native usage a bunch.
< wumpus>
do we need 32948 PRs that just rename options
< morcos>
wumpus: Thirty Two Thousand Nine Hundred Forty Eight Pull Requests?
< wumpus>
morcos: yes
< meshcollider>
More pull requests = more active development though right ;)
< gmaxwell>
wumpus: well there are many more possible renamings than that, so we have a long way to go. :P
< booyah>
wumpus: we do not? (:
< jtimon>
wumpus: right, as long as names are clear, the shoreter the better
< jtimon>
s/shoreter/shorter/
< meshcollider>
Let's just start using -a, -b, -c ....
< jtimon>
meshcollider: you forgot the "as long as they are clear" part :p
< wumpus>
any other topics?
< sipa>
let's get back to work!
< meshcollider>
And more update about signing certs?
< jonasschnelli>
cfields
< meshcollider>
Any*
< jonasschnelli>
Last state is that we are going to sign 0.16 with a single person RSA
< MarcoFalke>
I think only what is tagged 0.16 is priority right now
< MarcoFalke>
We didn't do the priority prs thing
< wumpus>
yes, high priority for review is the 0.16 milestone list right now
< wumpus>
we'll start using the project again after 0.16 is branched
< MarcoFalke>
end meeting?
< jtimon>
MarcoFalke: ok, perhaps it can be priority review but not for 0.16 or priority review but only after 0.16 is forked or something, I don't know
< MarcoFalke>
jtimon: I reviewed it. If other people like it they will come by, I guess.
< wumpus>
jtimon: I've added it to the project anyhow
< MarcoFalke>
They are just tagged for 0.16. I think some should be closed without merge
< jtimon>
MarcoFalke: thanks, I was just testing waters and as said "microtopic", I can always rebase this tiny thing for my purposes, it's just always good to get the thing you need in if you can, but no big deal at all
< wumpus>
MarcoFalke: so they're not all blockers for 0.16?
< jtimon>
sorry, guys, I'm just impacient, but I wasn't impacient enought to fully review the already merged sw wallet support, so I don't feel I can ask for anything (also as always)
< gmaxwell>
So in the unlikely event that someone can't contribute to making 0.16 better, I think we're still better off with them sitting on their hands rather than doing anything that would make 0.16 take longer or be less good.
< wumpus>
jtimon: exactly, if you want to help hurry the release along, help testing and reviewing the PRs that are left
< wumpus>
jtimon: yes, normally we work according to a schedule, this time it's a bit more ad-hoc, on purpose, we won't make a habit out of it
< meshcollider>
It's annoying that the minutes now include every issue that was mentioned in the meeting including repeats...
< instagibbs>
sounds like a job for blockchain
< jtimon>
I know, I think this is very good, I will always ask for even better, sorry
< gmaxwell>
phantomcircuit: on change address matching, our power to do that is kinda limited: If the output type is p2sh or p2wsh we can't actually tell whats in it, and our usage may look nothing like it. And also we're not about to use p2pkh on a wallet that is otherwise segwit, just because the payee uses it... since the fee impact to the user would be non-negigible. (though perhaps it would be reason
< gmaxwell>
able to allow that behavior to be configured)
< gmaxwell>
phantomcircuit: what the open PR does, IIRC is if your wallet is configured to use p2sh-embedded-segwit (e.g. the default in master), it will use native segwit for the change if any of the requested outputs are native segwit.
< sipa>
also, once native is common on the network for payments (= many transactions exist which just have a single native segwit output), it may make sense to change the default to producing bech32 change regardless of payment destination, as it's not a privacy leak anymore
< gmaxwell>
and I assume that once BC1 addresses are accepted almost everywhere, we'll change the default to native, and probably keep using native even if the output type is p2sh.
< gmaxwell>
You could argue that there is some advantage to matching, but I think its washed out by the high probablity that the underlying p2sh script does not match.
< gmaxwell>
and the tx fee savings of native.
< jtimon>
wumpus: we haven't forked .16 yet, which imo is generally good until the 0.16 milestone only has 2 or 3 prs left, I just hate duplicating prs and also talling people (specially myelf) to wait until that happens. I'm certain you guys have done what I think it's best: merge prs or move for later in that list before forking. sorry, I'm being reiterative
< wumpus>
jonasschnelli: I would have been ok with relative paths if they meant 'relative to datadir' as other relative paths in our options, but relative to current directory isn't really acceptable, that's simply a recipe for confusion, especially if provided in bitcoin.conf
< wumpus>
but forbidding relative paths for the walletdir is fine too
< jonasschnelli>
Yes. I'd say we should forbid relative path for the wallet dir.
< jonasschnelli>
(just said not in 12166)
< ryanofsky>
datadir-relative paths make sense to me too, but we can always add that later if relative paths disallowed now
< wumpus>
yyes, agreed ryanofsky
< jonasschnelli>
+1
< wumpus>
jonasschnelli: looks like your mainnet DNS seed is malfunctioning
< jonasschnelli>
damit...
< jonasschnelli>
let me check
< jonasschnelli>
hmm... looks good.
< jonasschnelli>
wumpus: what issue did you got on your side?
< jonasschnelli>
Getting successful requests/responses as well
< wumpus>
jonasschnelli: seems to work again now
< wumpus>
just a few minutes ago, and earlier today it was not
< jonasschnelli>
hmm... maybe a servercenter issue? logs are looking good.
< * jonasschnelli>
new project for 2018, server center in home cellar, 1Gbit sym. uplink required. :)