< bitcoin-git>
[bitcoin] gkrizek opened pull request #15196: Update all subprocess.check_output functions to be Python 3.4 compatible (master...cron-ci-fix) https://github.com/bitcoin/bitcoin/pull/15196
< gkrizek>
wumpus: ^
< Alixe>
Hello
< Alixe>
Can I ask questions here regarding full node?
< arshbot>
shoot
< Alixe>
So I think mining hash power can't do anything because full nodes enforce consensus rules. But some people think governments or corporates can buy a lot of nodes to affect Bitcoin with having majority of full nodes. Is it possible?
< sipa>
#bitcoin
< Alixe>
I really want to know devs opinion on this
< luke-jr>
Alixe: this is not "talk to devs", it is "talk about development", and your question is not about development. some of us are in #bitcoin too
< Alixe>
I guess everyone is busy
< Alixe>
Will ask on slack maybe
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #15197: Refactor and slightly stricter p2p message processing (master...2019/01/netmsg_1) https://github.com/bitcoin/bitcoin/pull/15197
< wumpus>
gkrizek: thanks!
< gkrizek>
No problem!
< dufferzafar>
i'm doing some network measurement experiments on bitcoin
< dufferzafar>
i have bitcoin daemons running on multiple machines
< dufferzafar>
and to simulate real network like delays and latencies i'm using Linux's tc/netem
< dufferzafar>
i want to add delays between P2P ports of machines
< dufferzafar>
but i think the p2p ports aren't fixed
< dufferzafar>
how would i go about adding delays?
< wumpus>
"but i think the p2p ports aren't fixed" by default it is always 8333, unless you change it, which you obviously wouldn't do for a simulated network
< wumpus>
(8333 is assuming this is mainnet; testnet and regtest networks have different, but also fixed ports)
< dufferzafar>
wumpus: i did change the p2p port, but bitcoind is binding to some other ports as well
< dufferzafar>
it only listens on the p2p port
< dufferzafar>
but i think data transmissions happen on other ports (which can't be configured?)
< wumpus>
by default it will listen on the P2P publicly and the RPC port localhost-only
< wumpus>
no, there is only one kind of P2P connection and that always connects to a P2P port
< dufferzafar>
let me explain by the output of "lsof -i" (lists all open ports)
< dufferzafar>
so, the ports 12192 & 12476 are the ones the two bitcoin processes (btc1 & btc2) are listening on
< dufferzafar>
these are the p2p ports
< wumpus>
there are two possiblities: incoming connections, which go *to* the P2P port on the local host, or outgoing connections which go to the P2P port of a remote host
< dufferzafar>
i don't get where the ports 33542 & 60332 are coming from
< dufferzafar>
i didn't specify these numbers anywhere in the config
< wumpus>
aren't they the ephermal source ports for the TCP connections?
< dufferzafar>
yeah, but they're dynamic right
< dufferzafar>
so i won't be able to set a delay
< dufferzafar>
because that requires me knowing the ports beforehand
< dufferzafar>
i was running a command like: "tcset ens3 --delay 120s --dst-network 10.17.6.18 --src-port 12476 --dst-port 12192"
< dufferzafar>
but since the data is being transmitted over the ephemeral ports, the delay doesn't work
< wumpus>
source ports for TCP connections are *always* dynamic, remember that the (source host:port, target host:port) tuple has to be unique for a connection, so otherwise you could only have one connection to a certain service from one host!
< dufferzafar>
yeah, i understand why it has to be dynamic
< dufferzafar>
but i don't get how i would be able to add delays then
< wumpus>
I think you need to read up on how your tooling is used with other TCP protocols, it's not really different for bitcoin
< dufferzafar>
i even tried something like: "tcset ens3 --delay 120s --dst-port 12192"
< dufferzafar>
but that doesn't work either
< dufferzafar>
leading me to believe that the P2P port isn't being used
< echeveria>
isn’t being used?
< dufferzafar>
as in, it is only being used to listen for new clients
< dufferzafar>
but the actual data is transmitted on some other port
< wumpus>
it is being used, believe me
< dufferzafar>
(just my hypothesis)
< echeveria>
no.
< wumpus>
if it's not being used then your node has no connection in the first place
< echeveria>
you’re not listening to experts that know the system. it does not use other ports. your hypothesis is utterly irrelevant.
< wumpus>
I suggest you ask in the help channel for your simulation tooling why it isn't working, I don't think anyone can help you here
< wumpus>
also this isn't a help channel, it's about development
< dufferzafar>
okay, is it bitcoin-help? i saw this channel mentioned on slack, so came here
< wumpus>
it's fine as long as you don't go arguing how bitcoin's P2P protocol works...
< wumpus>
DeanGuss: it was a crude but effective way to be sure that all the unencrypted data is removed from memory, and to be sure only the encrypted wallet is loaded next time
< achow101>
rafalcpp: the depends system is used to compile all dependencies deterministically and as static libraries
< rafalcpp>
achow101: is there any plan on moving to cmake one day? I'm looking to recreating this but in cmake, in next months
< achow101>
rafalcpp: no
< achow101>
autotools currently works. changing to a completely different build system would require tons of work and probably no one would review it since not many people understand build systems
< rafalcpp>
I wonder if automake is not even harder to understand though
< wumpus>
I understand automake/autoconf better than cmake and that's not saying a lot
< wumpus>
I'd nack moving to a different build system, it's just not a good use of limited reviewer bandwidth, and it will take ages to fix all the little problems again we've managed to with this build system
< ikus>
Hello
< jnewbery>
promag: thanks. After #15204, is there just a 'create wallet' menu item to add and then we're done?
< promag>
jnewbery: create wallet should open a dialog to ask for: name / external path, create empty? encrypted?
< midnightmagic>
Well.. boost's jam is way easier to build for, and a faster build too. But. Lot of work and hard to get right for multi-platform. :-/
< jnewbery>
I'd leave createempty and encrypted out for now to avoid dependency on 14938 and 15006. Seems like it shouldn't be too difficult to add those checkboxes in a follow-up
< jnewbery>
I'd really love to see load/unload/create wallet in the GUI for 0.18. Avoiding dependencies on other PRs increases the chances of us making it.
< promag>
I think I can submit the "create wallet" pr this weekend
< promag>
jnewbery: Avoiding dependencies on other PRs increases the chances of us making it -> you mean dependencies to 14938 and 15006?
< promag>
I don't want to depend on those
< promag>
initially I had the "file -> new wallet" use QInputDialog to type the wallet name
< promag>
and "file -> new external wallet" to use QFileDialog
< promag>
but I think I should create a dialog/wizard to easily extend with those options later
< jnewbery>
I think the distinction between open wallet and open external wallet (also new wallet and new external wallet) is probably confusing for most users. I'd lean towards just having one menu item for each
< jnewbery>
yes, I mean avoid having createempty and encrypted as options for create wallet, since that's unmerged functionality
< promag>
fot that (just one open wallet action) I would have to create a custom dialog
< promag>
Unless I add "file -> open wallet -> other ..." at the end of the menu
< promag>
jnewbery: I also think it's fair to improve after 0.18
< bitcoin-git>
[bitcoin] jamesob opened pull request #15205: validation: avoid potential deadlocks in ValidationInterface (master...2019-01-avoid-validationqueue-deadlock) https://github.com/bitcoin/bitcoin/pull/15205