< bitcoin-git>
bitcoin/master c4af738 Matt Corallo: Fix ignoring tx data requests when fPauseSend is set on a peer...
< bitcoin-git>
bitcoin/master a8cbbdb Wladimir J. van der Laan: Merge #12392: Fix ignoring tx data requests when fPauseSend is set on a peer...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12392: Fix ignoring tx data requests when fPauseSend is set on a peer (master...2018-02-fix-fpausesend-getdata-resp) https://github.com/bitcoin/bitcoin/pull/12392
< jonasschnelli>
rc4?
< wumpus>
maybe...
< wumpus>
might be too soon
< jonasschnelli>
maybe wait for other report, right.
< jonasschnelli>
*reports
< wumpus>
if you release too many rcs in short succession the number of testers will likely drop; I've already seen the first "I'll test next weekend when rc n+1 is out"
< wumpus>
so let's keep it to 1 per week
< wumpus>
going to do the backports already so people on the 0.16 branch can test
< jonasschnelli>
Makes sense.
< gmaxwell>
wumpus: though perhaps the things that would be in rc3 should ... nevermind you got it. :P
< * gmaxwell>
will test as soon as the backports are merged.
< gmaxwell>
Randolf: it has pending requested changes by reviewers.
< wumpus>
documentation is high priority unless. yeah, this is only typos
< Randolf>
gmaxwell: Okay. Is there a place where one can see what's in the "pending requested changes by reviewers" list? Or is the fact that they're open already implying that?
< gmaxwell>
Randolf: look at the last comments on it.
< gmaxwell>
oh I misread, sorry!
< Randolf>
I see "utACK" from luke-jr.
< gmaxwell>
(I thought the last comment was asking to remove that change, and I saw no commits after it)
< Randolf>
My curiosity on this is motivated by my desire to gain a better understanding of how this all works.
< Randolf>
(So far, the process overall seems to be well organized and efficient.)
< wumpus>
Randolf: cool, someone finally agrees with me for once, mind if I save the quote? :)
< Sentineo>
:D
< Randolf>
wumpus: Yes, I have no objections to being quoted. (My full name is Randolf Richardson.)
< wumpus>
Randolf: woohoo!
< Randolf>
wumpus: I'm a big fan of writing documentation before coding. I do this with all the software that I write.
< Randolf>
wumpus: It sure makes maintenance easier later on.
< wumpus>
Randolf: yup; it's good to have a background idea why something was done; and the most important thing is correct documentation, comments that are deceiving and don't match the code are worse than having no comments at all
< Randolf>
I like comments in code too. Sometimes they are overdone though, so I prefer to have a mixture of per-line comments (for specific things that need it) and an introductory set prior to a number of instructions / lines of code.
< wumpus>
I think what is important about code comments is that they explain reasoning, not directly what the code does which is obvious to everyone with knowledge of the programming language
< promag>
is it valid or not to have the on scriptpubkey duplicated?
< wumpus>
provoostenator: that's a good thing, yes :)
< promag>
*the same
< gmaxwell>
the same scriptpubkey duplicated where?
< gmaxwell>
promag: are you asking if a transaction can have multiple outputs using the same scriptpubkey?
< promag>
yes, sorry if it was't clear
< gmaxwell>
If so, thats valid in the consensus rules, though bitcoin core's wallet (and I assume most other wallets) won't produce it.
< gmaxwell>
(e.g. if you do a sendmany with repeated outputs it just merges them)
< murrayn>
sipa, I get that. But where's the bottleneck? I could see if one cpu was pegged. Or disk IO. But nothing seems to be happening. It's just slow.
< echeveria>
2018-02-12 11:06:21 version handshake timeout from 476
< echeveria>
2018-02-12 11:06:24 version handshake timeout from 477
< echeveria>
that's fun.
< echeveria>
it's in my log a bunch too but I've never been able to work out a pattern in it.
< sipa>
murrayn: you may want to run with -debug=bench of you want to figure out what it's spending time on
< sipa>
but it may just be shitty peers
< sipa>
that don't give you blocks fast enough for you to process
< murrayn>
well i'm afraid to start over!
< sipa>
it won't
< murrayn>
"only" 1 year 16 weeks behind
< sipa>
if you shutdown cleanly it will continue where it left off
< murrayn>
ok sipa i will try
< gmaxwell>
These logs look pretty normal.
< gmaxwell>
other than it being a bit slow.
< murrayn>
just to add some background this is running with -reindex-chainstate because i already had all the blocks downloaded
< sipa>
oh
< gmaxwell>
see now all these peer theories go out the window.
< sipa>
well, then it's not due to slow peers
< murrayn>
no
< sipa>
but in any case, don't run with -reindex-chainstate the second time or it will start over again
< murrayn>
my initial sync took 10 days which i thought was crazy
< sipa>
but you can shutdown and it will continue the reindex
< gmaxwell>
murrayn: what OS and what version of the software is this?
< murrayn>
win7, 0.15.1
< gmaxwell>
some anti-virus can absurdly slow down sync.
< murrayn>
n/a
< gmaxwell>
wumpus: why are you running -reindex-chainstate?
< murrayn>
gmaxwell, do you mean me?
< gmaxwell>
lol yes
< murrayn>
ok
< murrayn>
i moved the datadir to a new disk
< gmaxwell>
would it happen to be a USB hard drive?
< murrayn>
and when i restarted bitcoin-qt it did it's thing
< murrayn>
gmaxwell, no
< phantomcircuit>
murrayn, that looks like io issues
< phantomcircuit>
there's 2-3 seconds between blocks
< phantomcircuit>
it's not bursty
< murrayn>
i would be glad to see 2-3s/block
< murrayn>
phantomcircuit, it's just not IO. these aren't slow drives
< murrayn>
i would hear them!
< bitcoin-git>
[bitcoin] promag opened pull request #12415: Interrupt loading thread after shutdown request (master...2018-02-shutdown) https://github.com/bitcoin/bitcoin/pull/12415
< gmaxwell>
hear them?
< murrayn>
i do see memory use climb up to 2G+, but then it drops down and starts the cycle again
< * gmaxwell>
waits to hear that he's using a shingled spinning disk...
< murrayn>
it's under 1G now
< gmaxwell>
murrayn: yes when the cache fills it flushes.
< murrayn>
yeah, makes sense
< gmaxwell>
The name cache is largely a misnomer, the main useful thing the cache does during sync is act as a buffer to prevent spent outputs from ever hitting the database.
< gmaxwell>
it caches too, but that function doesn't do much for performance.
< gmaxwell>
(during sync)
< murrayn>
ok, well i'm using -dbcache=2048
< murrayn>
just out of curiosity, when is the last time any of you guys in this conversation started a new datadir
< murrayn>
i'm willing to believe it's some issue with the windows build, and willing to try to track it down.
< gmaxwell>
murrayn: several times a month.
< murrayn>
ok, thought so
< gmaxwell>
murrayn: it's not an issue with the 'windows build' people have reported couple hour syncs in windows with 0.15.x
< murrayn>
gmaxwell, from the network?
< gmaxwell>
murrayn: yes, and reindexes.
< murrayn>
well in any case i would like to help track it down. from what I read I'm not alone.
< gmaxwell>
in your case either you finished syncing from blocks on disk and started pulling from the network and your slower due to peers/network.. or your IO is just super high latency on your system.
< gmaxwell>
murrayn: sipa asked you earlier to turn up bench debugging.
< gmaxwell>
murrayn: you can turn them on without restarting dunno why he didn't suggest that.
< murrayn>
gmaxwell, yeah but i don't want to restart and lose over two days of "progress"
< murrayn>
oh ok
< gmaxwell>
you won't lose progress.
< gmaxwell>
regardless, it'll continue from where it is.
< gmaxwell>
use the logging rpc/cli command to enable bench and net
< murrayn>
can you give me a tldr?
< murrayn>
the command
< wumpus>
I think it's time to move this to #bitcoin
< gmaxwell>
murrayn: you're using the gui interface? bring up the debug console and run logging '["bench","net"]'
< bitcoin-git>
bitcoin/master 91986ed Karel Bilek: scripted-diff: Use UniValue.pushKV instead of push_back(Pair())...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #12193: RPC: Consistently use UniValue.pushKV instead of push_back(Pair()) (karel-3d) (master...Mf1801-univalueDeprecatedPair) https://github.com/bitcoin/bitcoin/pull/12193
< bitcoin-git>
[bitcoin] practicalswift opened pull request #12416: Fix Windows build errors introduced in #10498 (master...fix-windows-build) https://github.com/bitcoin/bitcoin/pull/12416
< instagibbs>
is someone generating hashes of issues/prs somewhere?
< instagibbs>
wumpus, oh i see you linked, nevermind
< wumpus>
yes not so much hashes as a full mirror of information available through the API, though of course you can use it to compute hashes: https://github.com/zw/bitcoin-gh-meta
< qttmyth88>
Hello, Is there a precaution to sending a request through bitcoin core. What happens if a malware classified me as a fraud because my name doesn't show as the name on the internet provider. Is there away to remove me off that alert?
< provoostenator>
How is change_type in coincontrol used? There's no UI for it afaik, but maybe an RPC command?
< provoostenator>
Or is coincontrol.h alwasys used even if the user turns off "Enable coin control features"?
< sipa>
yes, it's just the interface to pass information to the coin selection algorithm
< polpol>
i heard that after 0.16.0 segwit will be used "by default" is that correct?
< sipa>
yes
< polpol>
that means that segwit usage will be 100% or not necessarily?
< sipa>
no, people may be using wallet software other than bitcoin core
< sipa>
or may choose to turn it off
< sipa>
or may continue to use addresses they created before
< polpol>
got it, thank you sipa
< sipa>
or may keep spending coins sent to earlier addresses
< michagogo>
Does anyone here have any experience in working with Ubuntu packages (backports etc.)?
< instagibbs>
provoostenator, yeah coin control is an overloaded term imo. consumers see it as that qt window, Core contributors see it as what sipa said
< provoostenator>
Is there a good reason not to just remove that checbox and turn it on by default?
< sipa>
which checkbox?
< provoostenator>
There's a "Enable Coin Control Features" checkbox in the QT settings.Maybe move Coin Control Features to the bottom of the Send screen, below fees. As long as the basic stuff is at the top, it shouldn't be too intimiating.
< provoostenator>
And some sort of Show / Hide toggle in the send screen itself make more sense to me in general.
< sipa>
define basic stuff
< provoostenator>
Basic stuff: how much, to which address
< sipa>
the idea is that most users don't know and shouldn't care about things like coins, inputs, outputs, groupings, ...
< provoostenator>
(and label / note)
< provoostenator>
The Coin Control Feature at the moment are only Input selection and a custom change address. They can be hidden by default, but I don't need you need a setting to reveal them.
< provoostenator>
E.g. there could be Coin Control button next to Add Recipient at the bottom of the screen to toggle that section.
< provoostenator>
ryanofsky or someone else: re #11625, I have no idea how to use gdb other than "gdb src/qt/test/test_bitcoin-qt"
< provoostenator>
And do I need to use any special configure flags?
< michagogo>
Hm
< michagogo>
I tried to see if mingw-w64 was easily backportable
< michagogo>
And it's not really working, something about dependencies
< michagogo>
For all I know it's easy to fix, but I don't actually know ~anything about Ubuntu packaging, so I have no idea how to do more than run the `backportpackage` command :-/
< cfields>
sipa: 1day-ago pong.
< instagibbs>
fAllowOtherInputs comment seems to be off. "//! If false, allows unselected inputs, but requires all selected inputs be used". But AvailableCoins immediately filters things not on the selected list when list is non-zero
< instagibbs>
am I understanding it right
< instagibbs>
SelectCoins allows you to use other inputs, but those inputs will never be fed in the normal Available->Select flow
< provoostenator>
Gotta love Stack Overflow... "Here's one million ways to fix gdb on OSX...." "Oh by the way, you can use lldb"
< n1bor>
@murrayn how much RAM do you have? I have seen this sort of performance with 4Gig or less of RAM. Put in 8-12 Gig and same machine was 10x faster.
< n1bor>
ibd hate to be short of RAM. I think the filesystem cache needs it for leveldb reads?
< BlueMatt>
#12367 only fixed the issue for non-reindex cases (ie where LoadChainTip gets called)...any other cases will simply happily initialize pcoinsTip on top of an empty chainstate and then expect to have genesis loaded in the ThreadImport
< BlueMatt>
would rather be smarter and not call FlushStateToDisk somehow
< cfields>
BlueMatt: yes, I don't like that either. It was really only intended to jump of discussion about where to fix it for real.
< cfields>
*jump off
< BlueMatt>
I mean looking at the issue I dont really see a way to fix it that I like to begin with :(
< cfields>
same, hence the punt :p
< BlueMatt>
but should slip it into the next rc :(
< BlueMatt>
well I liked my earlier fix...that didnt actually fix it :/
< BlueMatt>
I mean the other obvious option is to make it explicit - have some static in validation.cpp/CChainState that just means "ive gotten as far as loading the genesis block, I can flush now"
< cfields>
right
< cfields>
and don't we already have that, in some form?
< BlueMatt>
not afaik.....I mean we just explicitly refuse to finish loading until we've gotten that far
< BlueMatt>
Ive gotta run, but I'd say just do something in CChainState that gets set to true the first time we do a DisconnectBlock or ConnectBlock, and refuse to flush until then?
< BlueMatt>
should fix the bug without hiding a hack in utxo flushing
< cfields>
fHaveGenesis... ?
< BlueMatt>
fHaveLoadedGenesis
< BlueMatt>
sure
< BlueMatt>
set either in LoadChainTip
< BlueMatt>
or ConnectBlock
< BlueMatt>
I think
< cfields>
no i mean, look in init.cpp
< BlueMatt>
yea, I know
< BlueMatt>
it feels cleaner to duplicate it inside CChainState
< BlueMatt>
so that its clearly a validation thing
< BlueMatt>
instead of yet more global pollution
< BlueMatt>
fHaveGenesis can continue to sit in init as a block-on-me-before-continuing
< BlueMatt>
@eklitzke gets the credit for discovery, btw