< midnightmagic>
owowo: I have an XU4 with 8 cores! It's pretty quick for a little credit-card-area sbc.
< owowo>
tulip, why not?
< sipa>
sbc?
< gmaxwell>
owowo: because they 'little' cores are power efficient but not fast, you normally don't use all 8 at one time.
< tulip>
it's unclear if the a83t in that Single Board Computer is actually big.LITTLE.
< luke-jr>
regardless, POWER8 would still be better :p
< tulip>
ok, I stand corrected, it does actually have 8*a7 cores. in *general* 8 core ARM SoC have been big.LITTLE, which have 4 high power and 4 low power cores with different instruction sets.
< owowo>
but it works :D
< owowo>
and the HDD works too, though it crashed with the computer from about 1.6 meters.
< owowo>
about 5 years ago ;)
< BlueMatt>
gmaxwell: ok, done
< phantomcircuit>
gmaxwell: i restarted a node at ~tip of master
< phantomcircuit>
a huge number of inbound connections claim to be 0.13.1
< phantomcircuit>
which seems a bit fast
< gmaxwell>
phantomcircuit: preferential peering.
< sipa>
i see a large number of /BTCC:0.13.1/ with 00000001 service bits
< gmaxwell>
oh fake nodes, fake nodes.
< gmaxwell>
I think all of those ended up on my banlist previously for being fake and connecting to everyone.
< aj>
"fake nodes, fake nodes, what you gonna do, what you gonna do when they connect to you?" o/ o/
< achow101>
all those nodes are aws nodes too
< sipa>
yeah i think they're on my banlist
< BlueMatt>
gmaxwell: lol
< BlueMatt>
didnt realize the btcc things were that fake
< achow101>
the one with the chinese ip is probably the real one. The rest are all aws nodes which seems a little suspicious
< shangzhou>
I have upgraded my node to 0.13.1
< shangzhou>
From China Suzhou
< achow101>
gmaxwell: for the alert key retirement, what about testnet's key?
< phantomcircuit>
achow101: is there even a separate key
< midnightmagic>
to.. uh. Whomever? Do you want me to open a new PR re: functional 0.13.1rc3 gitian sig update, or just update the pre-existing one.. or? I've rebuult (in total) the rc3 gitians and actually done a gverify on them against the others available now.
< midnightmagic>
Well. I'll open a new one. Seems github makes that easier.
< tulip>
rebroad: the peer in your issue about "already received" is one with a /ViaBTC/ subversion. in a misguided attempt to improve their stale block rate (which they do have, though their pool reports a false "0") they wrote a piece of software which hammers out blocks to peers that don't request it, burning bandwidth in the process.
< phantomcircuit>
uh
< phantomcircuit>
so im not exactly 100% on c++ inheritance stuff
< phantomcircuit>
but i feel like this should work
< gmaxwell>
tulip: I've encountered a number of other nodes doing that, wastes a lot of bandwidth. now that we have BIP152 deployed, we should look to banning peers that send unsolicited full blocks.
< gmaxwell>
perhaps unsolicited CB too (e.g. when they weren't selected to be high bandwidth peers)... though thats less awful.
< phantomcircuit>
gmaxwell: any ideas
< aj>
phantomcircuit: you're trying to access a protected member in an instance of the /base/ class
< aj>
phantomcircuit: if it were an instance of the child class you could do it
< phantomcircuit>
aj: right so i have to actually replace the CWallet object with a CWalletAccountingTests object
< aj>
phantomcircuit: or you could declare CWalletAccounttests a friend class? i don't see any other ways...
< phantomcircuit>
hmm
< phantomcircuit>
now i need to find where pwalletMain is intialized during testing
< aj>
wallet/test/wallet_test_fixture.cpp?
< aj>
but you might be able to use reinterpret_cast in a way that's not too horrific
< phantomcircuit>
the problem is more so that pwalletMain is a thing i guess
< Bi_>
Hi. Can someone please help me to understand one of the unit tests / script_tests
< Bi_>
Its then one
< Bi_>
that is called "Basic P2WSH"
< Bi_>
My main question is: is the script expected to fail or pass?
< Bi_>
Because in script_tests.json file I see "OK" for this test vector. But looking how the script gets executed (from script_tests.cpp) I see it actually failing. But the test itself is passing, like it was expecting the script to fail
< phantomcircuit>
Bi_: there are tests which pass when the test fails intentionally
< Bi_>
phantomcircuit, yes I know it
< Bi_>
Bus is this such a one?
< phantomcircuit>
no idea
< phantomcircuit>
it should say
< Bi_>
Well, in the jason file it says "OK" - so I'd assume it's expecting OK from the script function
< Bi_>
But that's not what I see it getting from the script function
< GitHub64>
[bitcoin] laanwj opened pull request #9036: wallet: Change default confirm target from 2 to 6 (master...2016_10_txconfirmtarget) https://github.com/bitcoin/bitcoin/pull/9036
< tinkerbell11_>
lots of places shouting about november 15th startdate for checking flags.. but dates are meaningless.. anyone know the first blockheight where checking will begin??
< tinkerbell11_>
eg 440,000?
< aj>
probably block 441504 would be the first block where the 95% test could theoretically pass; so around dec 3rd for earliest conceivable lockedin?
<@wumpus>
jonasschnelli: do you know why do we still change payTxFee globally in the GUI when there's a perfectly usable fOverrideFeeRate in coincontrol?
<@wumpus>
seems like an unnecessary source of potential conflicts
<@wumpus>
btcdrak: great!
< aj>
wumpus: fwiw bitcoin 0.13.1 is in debian unstable now too.
<@wumpus>
aj: okay
< timothy>
archlinux too
< btcdrak>
Viva la revolución!
< BlueMatt>
wtf is pnodeLocalHost?
< BlueMatt>
looks like we maintain a persistent connection to ourselves?
< BlueMatt>
oops, heh, cut off the explination text
< BlueMatt>
anyway, left axis is ms from first-recv to which the 1st, 2nd, 3rd, etc node received the block...so T1-T4 (the bottom 4 lines) are pretty noisy because it depends on where things entered the network....T5 is super flat, meaning the network is highly reliable in terms of time take to transmit around the globe
< sipa>
it's an exponential scale
< BlueMatt>
note log scale, but its still super flat ignoring that...just under 180ms almost always, with peaks reaching 190/195
< sipa>
ok
< aj>
BlueMatt: which lines correspond to the right hand axis?
< BlueMatt>
honestly i have nfc wtf the right axis is, none of the lines correspond to it
< BlueMatt>
would have to go read the source
< aj>
haha, awesome
< cfields_>
BlueMatt: yea, we do. I've never gotten around to asking why, kept assuming i'd bump into the reason. Still haven't though.
< BlueMatt>
wtf....
< cfields_>
BlueMatt: i've always assumed the intent was to be able to query our own node state in the same place as the others
< BlueMatt>
that sounds like some satoshi-era bullshit right there :p
< cfields_>
BlueMatt: well it's completely made up, just my best guess :)
< cfields_>
but yes, let's kill it
< cfields_>
BlueMatt: i'll nuke it after the PR that changes message sending around? Otherwise killing it would stomp on that i believe
< BlueMatt>
yes, agreed, no rush there
< BlueMatt>
reviewing that one now :)
< BlueMatt>
(thats why i saw it)
< cfields_>
figured
< cfields_>
BlueMatt: need to double-check all accounting to make sure it doesn't +1 something important
< phantomcircuit>
that isn't used internally in CWallet or CWalletDB is it?
< phantomcircuit>
(also yes)
< phantomcircuit>
i went to wrap CWallet in a class for the tests so i can make a bunch of methods protected and ran into pwalletMain being global for tests and normal use
< BlueMatt>
it shouldnt be? is it really?
< phantomcircuit>
BlueMatt: yeah...
< phantomcircuit>
wallet.h
< BlueMatt>
thats not "used", just defined
< BlueMatt>
move the definition?
< phantomcircuit>
it's used in accounting_tests.cpp
< phantomcircuit>
and is initialized in wallet_test_fixture.cpp
< phantomcircuit>
afaict those are the only things which even use the CDB::MakeMock stuff
<@wumpus>
I think it ends up there if things are missing in the block index
< BlueMatt>
cfields_: ok, reviewed 8708
< BlueMatt>
gmaxwell: heh, ok
< gmaxwell>
BlueMatt: did you see my comment from last night that perhaps we should be banning peers that send us an unsolicited block message now that we have compact blocks? (perhaps also unsolicited CB when that peer is not requested for HB mode, but I think thats less important)... there are a number of peers on the network which 'helpfully' send blocks without asking, causing some n-fold bandwidth inc
< gmaxwell>
rease (esp for blocks only nodes).
< BlueMatt>
gmaxwell: i did not, but I'm not against it particularly
< BlueMatt>
I'd like to nominate https://github.com/bitcoin/bitcoin/pull/9026 (well, a variant of it, because that is gonna end up adapting to some reorgs that are in-progress) for 0.13.2
< gmaxwell>
With 9026 will peers still get banned if the block fails the stateless checks (e.g. bad pow)?
< BlueMatt>
i think that is the intention?
< gmaxwell>
k
< BlueMatt>
not with the current implementation, i think, but could be done
< BlueMatt>
and i think maybe should
< BlueMatt>
anyway, i think sdaftuar might be waiting for #8969 and the commits i posted based on it yesterday to tweak it, since it simplifies it
< cfields_>
BlueMatt: i agree with your nits about locking, so I whipped up the changes in the branch above. I didn't want that PR to creep on forever though, so I was going to add them as a next step. Would you be more comfortable if i tacked them on?
< BlueMatt>
cfields_: that looks sane to me? though i havent audited where we have those strange threading bugs
< cfields_>
BlueMatt: well if they're const, they can't be racy. No need to make things atomic if they can't change.
< BlueMatt>
indeed
< cfields_>
ok, I'll add them to the PR. Thanks for the review.
< BlueMatt>
cfields_: I'd be ok if they're next-step, i think, though i didnt bother to audit if they were possibly correct, it just looked very wrong and i gave up and pointed it out
< BlueMatt>
i dont think you need to
< BlueMatt>
i agree I'd prefer to move the pr forward
< BlueMatt>
i can go audit more fully to figure out if there are any actual bugs introduced
< cfields_>
ok. Well, you can take the branch above as proof that they don't change :)
< cfields_>
BlueMatt: ok, yes, that'd be easier. I was wanting to get gmaxwell/sipa's opinion on deterministic siphash for node nonce first anyway.
< Victorsueca>
gmaxwell: wouldn't that potentially lead to a split network with the nodes that ban peers that send unsolicited blocks on one side and the peers that don't know they're not supposed to send unsolicited blocks on the other?
< BlueMatt>
cfields_: heh, thanks for pointing out that nVersion is already const - your SetVersion violates C++ spec :p
< cfields_>
BlueMatt: same hack we use for serializing tx/block, so i figured i could get away with it :)
< BlueMatt>
cfields_: sipa has open prs to fix it for tx/block :p
< BlueMatt>
soo....no
< BlueMatt>
:p
< cfields_>
BlueMatt: must exist non-const? I'm going to have to call you on that. Going to either learn something or look like an idiot :)
< BlueMatt>
cfields_: i dont recall the exact wording, it either must exist somewhere as non-const reference (so possibly the constructor is enough), or it must exist afterwards as non-const
< BlueMatt>
I'm sure there is something like this in the spec, just not sure if the setting in the constructor qualifies
< BlueMatt>
sipa: might recall better than I
< cfields_>
BlueMatt: thanks, on phone, will take a look in a sec
< BlueMatt>
cfields_: stack overflow, as well as how i read the notes section on cppreference, indicate this is undefined...so folks are stating it clearly as anything defined with const cannot be const_cast'ed, cppreference says "Modifying a const object through a non-const access path...results in undefined behavior"
< jtimon>
I thought that was done globally for the tests in test_bitcoin.cpp, but let me try
< BlueMatt>
oh, in tests? dunno
< jtimon>
oh, I need to do the BOOST_FIXTURE_TEST_SUITE thing if I want to reuse that ECC_Start, if I do my own it seems to cause conflicts with the other call
< jtimon>
thanks a lot!
< sipa>
BlueMatt: correct... though i'm sure we already violate that elsewhere
< sipa>
BlueMatt: in particular in CTransaction, which i have a PR for to fix
< BlueMatt>
sipa: still, best not to introduce more :p
< sipa>
agree.
< * BlueMatt>
is available to trade reviews
< BlueMatt>
still trying to get 8969 in
< BlueMatt>
:p
< sipa>
BlueMatt: can you have a look at 8580?
< cfields_>
BlueMatt: i'll look through again and ack in a min
< BlueMatt>
sipa: lol, needs rebase again :p
< BlueMatt>
but I can look, is that your preferred version?
< sipa>
BlueMatt: i expect the rebase to be trivial
< cfields_>
BlueMatt: mm, how can you move a class with a const member, then? I assumed a const_cast there was correct. Looks like I need to read up.
< BlueMatt>
sipa: k, will look
< BlueMatt>
cfields_: move doesnt specify that the originating object must be invalidated, only that it may be and any future access is undefined?
< cfields_>
BlueMatt: yes, but the target object's const member must be re-assigned
< BlueMatt>
cfields_: hmm? I may be missing what you're referring to with move here
< cfields_>
BlueMatt: nm, not relevant.
< cfields_>
BlueMatt: i'll just give nVersion a const accessor and leave the assert in Set(). I just hope there aren't a million users of pnode->nSendVersion
< cfields_>
*i'll just give nSendVersion.
< BlueMatt>
make it private?
< cfields_>
yea
< cfields_>
oh wait, it already is. that was easy :)
< BlueMatt>
heh
< sipa>
BlueMatt: move must bring the moved-from object in a valid, but not further soecified state
< sipa>
BlueMatt: it *is* allowed to reuse a moved from object if you first use a call that fixes all its observable behaviour again
< BlueMatt>
sipa: yea, thats what i said?
< sipa>
ah, i didn't read the whole conversation
< BlueMatt>
hum, yea, i cant claim to be a C++11 person yet
< sipa>
cfields_: you cannot move an object with a const member
< BlueMatt>
you cant?
< sipa>
well, you can if you fon't modify the source
< BlueMatt>
well, yes, that was my comment
< sipa>
but that would make it a copy
< BlueMatt>
only for that member
< sipa>
right
< sipa>
seems i'm not fully awake yet
< cfields_>
sipa: yes, I see that now. I've always just setup a move operator that does a const_cast and changes. In some places that makes perfect sense. Seems it's not actually to spec, though.
< cfields_>
(again, like our current tx serializers)
< sipa>
cfields_: see 8580 :)
< cfields_>
heh, right
< BlueMatt>
bbl, lunch
< sipa>
there is an annoying confusion between observably constant and representation constness in c++
< cfields_>
i suppose i should review/ack that too, then. adding it to the list.
< cfields_>
sipa: mind explaining the distinction?
< BlueMatt>
sipa: can a constructor call a function which then const_casts?
< BlueMatt>
anyway, does it look like 8043 for you?
< ArtGravity>
I am on Unity
< ArtGravity>
my icon appears where the B in Bitcoin Core is in the image on 8043
< ArtGravity>
In the top left of the screen
< BlueMatt>
I'm not farmiliar with unity...is that the equivalent of the screenshot in 8043?
< ArtGravity>
I'm not having the missing menu problem
< ArtGravity>
Same desktop environment as in the 8043 screenshot
< ArtGravity>
different symptoms
< BlueMatt>
wait, so whats the bug? that you dont get the file, settings, etc menus?
< ArtGravity>
Tray icon appears in upper left of screen instead of in notification area
< BlueMatt>
cfields_: welp, looks like the ppa is gonna switch back to qt4
< cfields_>
BlueMatt: ?
< ArtGravity>
menus that should appear in the top menu bar of unity are missing
< BlueMatt>
ArtGravity: I really dont know what that means...screenshot? I have no idea where its /supposed/ to show up :p
< BlueMatt>
cfields_: 0.13.1 was the first release with qt5, and if there are bugs gotta go back
< ArtGravity>
in the 8043 screenshot, where it says Bitcoin Core - Wallet at the top left of the screen is where it should have the usual menus
< ArtGravity>
like File, Edit, View, Help, etc
< BlueMatt>
and what does it have there?
< BlueMatt>
the logo
< BlueMatt>
but the menus are in the window, i assume?
< BlueMatt>
ie not missing
< ArtGravity>
Just the logo covering the "Bit" in Bitcoin Core
< ArtGravity>
No menus
< cfields_>
BlueMatt: Ah yea, 0.13 -> 0.13.1 definitely shouldn't switch qt4 -> qt5. I didn't realize 0.13 used qt4.
< BlueMatt>
ArtGravity: anyway, can you file an issue on github?
< ArtGravity>
Yes
< BlueMatt>
ArtGravity: thanks
< BlueMatt>
probably with screenshot
< ArtGravity>
NP
< BlueMatt>
cfields_: well the only way to switch was dropping precise, which i did in 0.13, but only after uploading for others
< BlueMatt>
so this was the first opportunity
< luke-jr>
cfields_: PPA, not gitian binaries
< ArtGravity>
I do have appmenu-qt5 installed
< BlueMatt>
ArtGravity: hmm, try without?
< BlueMatt>
if it works without thats an easier fix
< ArtGravity>
I can try removing that first and see what happens
< BlueMatt>
thanks
< cfields_>
BlueMatt: mm, even if it does work, that's definitely an unexpected change imo
< BlueMatt>
cfields_: it /should/ just be a library change, not anything a user would see
< ArtGravity>
I remember this happening before and doing something to fix it
< cfields_>
BlueMatt: eh? guis and integration are vastly different between qt4 and qt5
< ArtGravity>
My Dogecoin had the problem too
< cfields_>
bbl
< ArtGravity>
w/o appmenu-qt5 I get the menu in the app instead of integrated into Unity
< ArtGravity>
The tray icon still appears in the wrong location
< BlueMatt>
arg, ok, thanks
< BlueMatt>
can you file an issue?
< ArtGravity>
Sure
< BlueMatt>
sipa: ok, you owe me review :p
< sipa>
BlueMatt: this is true.
< sipa>
BlueMatt: the whole reason for needing the stream::Construct<T>() rather than T(Steam&) is nVersion and nType
< sipa>
BlueMatt: the stream determines the value of those
< sipa>
i've argued before that we need to get rid of the nVersion and nType being passed around everywhere, and instead just make them accessors on the stream
< BlueMatt>
sipa: then please do :p
< sipa>
please review 8468 then :)
< BlueMatt>
sipa: I meant just for CTransaction initially
< sipa>
BlueMatt: bleh
< BlueMatt>
sipa: its incredibly shitty to have the Construct<T> stuff there, especially given the random hacks and tons of assert(false) functions
< sipa>
BlueMatt: i agree
< BlueMatt>
so break the shitty api :p
< * sipa>
breaks it thoroughly
< BlueMatt>
it deserved it
< Victorsueca>
lol
< GitHub166>
[bitcoin] EthanHeilman opened pull request #9037: net: Add test-before-evict discipline to addrman (master...test-before-evict) https://github.com/bitcoin/bitcoin/pull/9037