< * paveljanik>
have just discovered -p y argument to test_bitcoin 8) Whoa ;-)
< jonasschnelli>
paveljanik: what is the reason to use -P?
< paveljanik>
jonasschnelli, no reason, I was looking for something like --verbose and found this 8)
< paveljanik>
it brought me 20 years back ;-)
< paveljanik>
but it is nice :-))
< instagibbs>
what does it do?
< tErik_mc>
Hi, i'm running two bitcoin-qt.exe with two different bitcoin.conf files & two different folders (…\Roaming\Bitcoin1\ & …\Roaming\Bitcoin2\) by supplying -conf & -datadir via commandline. in 1st conf i have specified 3 eligius miner ip-address as "addnode" lines, in 2nd conf file i have specified the same addnodes as 1st conf, and in 2nd conf i have also added these extra lines: connect=127.0.0.1:8333 connect=192.168.10.120:8333.
< tErik_mc>
It seems, 2nd bitcoin-qt process is connecting with the 1st bitcoin-qt process, and to eligius node, but 1st one still not able create any TCP out to 5 other nodes !!! whats wrong ?
< tErik_mc>
In 1st bitcoin-qt.exe process, i have enabled RPC, specified rpc user+pass, and port 8332, but inside network-tools i do not see 1st bitcoin-qt.exe process is listening on 8332, but it is listening on 8333 though.
< tErik_mc>
Wow, great, finally now, after a long period, the 1st instance has finally connected with other 8 nodes (but eligius is not 1 of them though) :) so it was still doing something in the background, i guess.
< tErik_mc>
As the 1st bitcoin-qt is "primary" for me, so for any other secondary bitcoin-qt under my subnet/router, am i suppose to connect secondaries with the 1st one by using the "connect" options ?
< sipa>
use -addnode
< sipa>
-connect prevents connecting to anything but what you specify
< sipa>
-addnode just forces a connection, but still lets the normal node discovery used for other connection slots
< tErik_mc>
ah i see. thats why 2nd/secondary has connected only with the 1st one, and with the eligius, but nothing else.
< tErik_mc>
I see, so when i will start another node in the 3rd computer which has ip-address 192.168.10.130, then in that 3rd one's conf, i will specify "addnode=192.168.10.120" # primary-node. only primary node has port-forwarding from router to 192.168.10.120.
< tErik_mc>
THANKS^∞, sipa.
< tErik_mc>
i am specifying, localloop & port "addnode=127.0.0.1:8333" in bitcoin.conf for 2nd/secondary bitcoin-qt.exe , instead of 192.168.10.120 lan ip address.
< sipa>
tErik_mc: this channel is not really for support
< sipa>
you're better off on the forums, on documentation sites, or stackexchange
< tErik_mc>
On the other hand, i am keeping the 2nd/secondary instances with "connect=primary-bitcoin-core-ip-adrs" option, so that they can only use the local primary Bitcoin-Core Node as their main source node, in that way less data will be downloaded by the secondary instances, right ?
< sipa>
tErik_mc: i'm sorry, but this is not the right place to keep asking questions about basic usage
< tErik_mc>
For 3rd computer under my subnet, i will specify my side primary node's lan ip-address in "connect", (instead of local-loop).
< tErik_mc>
Thanks again, i will head to forums, stackexchange, doc sites for support . i really appreciate everyone's instant kind support here. it was v.helpful for me, that all of you helped me to start, i think now i can grasp the words used by others . if too complex then i will bug you guys again.
< tErik_mc>
Once i become more used to with its ops/usage, then i will try to read & understand the codes.
< phantomcircuit>
jtimon, my interest with CBlockchain is to cleanup the bitcoind codebase
< phantomcircuit>
it is indeed a very different thing than libconsensus attempts to achieve
< sipa>
phantomcircuit: cleanup is a nice goal, but i fear that multiple people pulling in different direction will make things worse, not better
< jtimon>
phantomcircuit: perfect, that was my first interset with libconsensus (the idea of exposing stuff was BlueMatt's), I just wanted to encapsulate the consensus code initially
< sipa>
consensus logic is currently spread out over script/, consensus/, primitives/, and root
< jtimon>
s/root/main ?
< sipa>
by root i mean src/
< jtimon>
oh, no, root dir
< sipa>
not a subdirectory
< jtimon>
I would like to put it all in consensus/
< jtimon>
and in the consensus package (but those things don't need to happen at the same time)
< sipa>
that makes sense, but i still want to see a plan of what goes where first before we continue refactoring things
< jtimon>
but I don't want the consensus package to ever depend on storage or globals
< phantomcircuit>
jtimon, i assume that you mean the things which intend to be consensus rules
< phantomcircuit>
since there's lots of things that are consensus logic which probably weren't intentional
< sipa>
of course... glibc is consensus logic :)
< jtimon>
well, libconsensus will have dependencies too (the crypto package, libsecp356k1...)
< jtimon>
s/will have/ has
< phantomcircuit>
sipa, well my plan is quite simply really, move most if not all of the functions in main.cpp which modify the block index or utxo database to CBlockchain
< phantomcircuit>
initially just as static functions
< sipa>
phantomcircuit: i am heavily opposed to moving code without a plan
< sipa>
a big problem is for example what to do with CBlockIndex*, as it is heavily relied upon by consensus logic, but depends on database specific information
< phantomcircuit>
then move to have Params be a private member function
< sipa>
and virtual classes are really not acceptable memory/performance wise
< phantomcircuit>
sipa, that's really an independent thing of what im trying to achieve with CBlockchain
< phantomcircuit>
my limited goal here is to make the interface between networking and consensus logic brighter
< phantomcircuit>
more defined
< phantomcircuit>
currently it's uh
< phantomcircuit>
not
< phantomcircuit>
:P
< sipa>
phantomcircuit: i think it's easier to refactor the other way, by moving the message processing code out of main
< sipa>
phantomcircuit: in any case, cory's network refactor first
< jtimon>
phantomcircuit: well, if I will have to later destroy CBlockChain...
< phantomcircuit>
jtimon, nah the protected implementation methods take Params as a parameter
< phantomcircuit>
tada
< phantomcircuit>
pure functions and a sane internal api
< jtimon>
sipa: why first or instead? I'm waiting for segwit, but I believe consensus, policy, network, and wallet encapsulations can happen simultanously and even have synergies
< phantomcircuit>
sipa, im not falling for that trap again
< phantomcircuit>
"just wait for X to happen first"
< sipa>
coordinare with cory so you don't step on each other's toes
< jtimon>
yeah please, I would be happy if everyone pings me on refactor PRs
< jtimon>
at least those that touch consensus or relay policy
< sipa>
i think too many people have very different goals, so they don't see how their work could possibly interfere with other's
< jtimon>
phantomcircuit: what about a function that takes Consensus::Params. CBlockChain can store his own Consensus::Params (or better, a reference to the one in the global Params() ) and call this function from its homonimous methods
< jtimon>
tada
< jtimon>
I still fail to see the point of CBlockChain though, therefore I would prefer to undesrtand before working on potential concrete solutions
< jtimon>
if we're going to have a global CBlockChain with "encapsulated" attributes instead of those attributes as globals directly...I don't see that as a great improvement
< sipa>
i do see the improvement
< sipa>
having it in a class makes it easier to turn it into a non-global later
< jtimon>
well, yeah, that's actually what I want to do with CPolicy
< jtimon>
but it doesn't help libconsensus
< phantomcircuit>
jtimon, yes
< jtimon>
phantomcircuit: yes what?
< phantomcircuit>
jtimon, yes the additional parameter in 8077 makes sense
< phantomcircuit>
but small steps
< jtimon>
oh, awesome!
< jtimon>
now, isn't #8077 disruptive for segwit?
< jtimon>
actually, maybe not a after bip9...
< jtimon>
let's find out
< phantomcircuit>
jtimon, i'll add a commit modifying CheckBlockHeader to demonstrate the idea
< jtimon>
phantomcircuit: I'll happily review, but it's more effective to ping me on github than on IRC (both is the most effective, too bad not everyone is as annoying as I am)
< GitHub85>
[bitcoin] sdaftuar opened pull request #8095: Test framework: only cleanup on successful test runs (master...nocleanup-on-failure) https://github.com/bitcoin/bitcoin/pull/8095
< phantomcircuit>
is anybody going ot kill me for suggesting that MAX_MONEY and COIN/CENT be moved to consensus/params.h
< phantomcircuit>
just because... it's a constant that's consensus critical
< gmaxwell>
does it count if they are already going to kill you?
< phantomcircuit>
gmaxwell, no
< jtimon>
phantomcircuit: no, in fact, maybe it would make sense to move some other stuff (ie MoneyRange() ) back to core/transaction.h and leave CFeeRate and related stuff alone to be cleanly moved to policy/feerate.o, that shouldn't be in the consensus package or libconsensus, my "brainstorming" branch about that is #7820 but I will happily ack if you replace it with something simpler
< jtimon>
I mean, that PR couples moving CFeeRate out of libconsensus with introducing CPolicy, but you don't need to do that
< jtimon>
I mostly created that for policy encapsulation brainstorming/progress, but by all means take all the consensus stuff out of there (warning: likely include disruption)
< jtimon>
maaku may have a different opinion
< jtimon>
I suggest you ping him in the PR too
< GitHub37>
[bitcoin] theuni opened pull request #8097: RFC: rpc: Remove dns argument for getaddednodeinfo (master...remove-getaddednodeinfo-dns) https://github.com/bitcoin/bitcoin/pull/8097
< GitHub164>
[bitcoin] MarcoFalke opened pull request #8098: [qa] test_framework: Append portseed to tmpdir (master...Mf1605-qatmpdir) https://github.com/bitcoin/bitcoin/pull/8098
< NicolasDorier>
My RPC Client sometimes use source address 0.0.0.0 for making a request (randomly)
< NicolasDorier>
problem is
< NicolasDorier>
that 0.0.0.0 is an "invalid address" and thus fail CSubnet::match
< NicolasDorier>
so I receive a forbidden 403
< NicolasDorier>
sound like a bug ?
< paveljanik>
NicolasDorier, interesting. IIRC we have seen similar reports in Issues.
< NicolasDorier>
yep, forcing my client to use 127.0.0.1 fixed the issue on my side. But I think this is a regression, I don't remember having this problem before
< paveljanik>
interesting.
< gmaxwell>
why do you have 0/0 configured as an interface? thats just broken.
< NicolasDorier>
I have no idea, I use a class of .NET named WebRequest. It selects the interface automatically
< NicolasDorier>
somehow, it select 0.0.0.0 sometimes
< gmaxwell>
binding to 0.0.0.0 is a special case in the socket interface, it means "use any interface". Having an interface of 0.0.0.0 existing on your system is busted and invalid.
< NicolasDorier>
gmaxwell: I don't have such interface normally... it just select this IP as the IP source of the request
< NicolasDorier>
checking if something wrong on my system... I formatted 1 week ago so it is unlikely
< paveljanik>
I have never seen this on unices...
< NicolasDorier>
I have no interfaces on 0.0.0.0, yep very strange
< gmaxwell>
that may be a bug on windows where it sees incoming connections as 0/0 sometimes?
< NicolasDorier>
gmaxwell: it is possible, it would explain why I never had the bug before. Only now I formatted to windows 10
< gmaxwell>
an important question is if it only does it for local connections or if it could also do it with remote connections.
< NicolasDorier>
it would make no sense it does with remote one
< NicolasDorier>
but well... microsoft is often very creative
< NicolasDorier>
will try to put a wireshark and experiment with the WebRequest class tomorrow on remote address for curiosity :p
< paveljanik>
I think it is OK for remote connections. Because otherwise it could not escape the system 8)
< NicolasDorier>
paveljanik: except if the bug is specifically in the WebRequest class of .NET
< paveljanik>
you mean if the outgoing requests from such class are 1/3 successful? ;-)