< meshcollider>
BlueMatt harding: if it's not stepping on anyone's toes (if you just want it up there asap), I can chuck up a PR in a bit for them?
< BlueMatt>
meshcollider: if its not up yet I assume just go for it
< meshcollider>
ok its up, PR 440
< fanquake>
wumpus I have some changes for the Windows builds notes ready, but can't seem to cherry-pick the commit out of 11244. If they push a commit with author info I'll grab that, otherwise will credit them in my commit message. Hopefully we'll have some clarity around the Windows build docs shortly..
< meshcollider>
Is there any permission level other than admin which can delete pages
< meshcollider>
"Lead developer" and "Original Client developers" both redirect to a deleted page, so they should be deleted too
< meshcollider>
Oops wrong channel
< meshcollider>
Meant that for the wiki channel lol
< bitcoin-git>
[bitcoin] fanquake opened pull request #11437: [Docs] Update Windows build instructions for using WSL and Ubuntu 17.04 (master...windows-build-1704) https://github.com/bitcoin/bitcoin/pull/11437
< bitcoin-git>
[bitcoin] fanquake closed pull request #11244: Docs: Add extra step to clean $PATH var to strip out windows %PATH% paths. (master...windows_build_fix) https://github.com/bitcoin/bitcoin/pull/11244
< bitcoin-git>
bitcoin/master d601f16 Anthony Towns: Fix invalid memory access in CScript::operator+=
< bitcoin-git>
bitcoin/master 10bee0d Wladimir J. van der Laan: Merge #11284: Fix invalid memory access in CScript::operator+= (guidovranken, ajtowns)...
< bitcoin-git>
bitcoin/master 3a4401a practicalswift: [Qt] Terminate string *pszExePath after readlink and without using memset
< bitcoin-git>
bitcoin/master c5c77bd Wladimir J. van der Laan: Merge #11193: [Qt] Terminate string *pszExePath after readlink and without using memset...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11193: [Qt] Terminate string *pszExePath after readlink and without using memset (master...null-terminate-after-readlink) https://github.com/bitcoin/bitcoin/pull/11193
< bitcoin-git>
[bitcoin] laanwj closed pull request #10457: Don't use fixed "wallet.bak"-filename during salvagewallet (master...2017/05/rename_bdb) https://github.com/bitcoin/bitcoin/pull/10457
< wxxs>
should 0.15 disconnect clients with version string /Satoshi:1.14.4(2X)/ ?
< andytoshi>
there's no point in having an arms race, if btc1 is going to masquerade as core then they'll masquerade as core
< andytoshi>
leaving the situation as-is at least means it's possible to identify them so individuals and businesses can manually patch them out if they cause problems
< wxxs>
so this is btc1 with the signal bit removed?
< BlueMatt>
wxxs: yea, btc1 decided to deliberately cause more harm to the network than neccessary, because they felt like trolling, I guess
< BlueMatt>
so if it didnt get disconencted, it was either a pre-version-bit version of btc1, or masquerading
< BlueMatt>
(or core with the version message changed to that)
< wxxs>
ew, I feel violated
< BlueMatt>
trolls gonna troll
< sipa>
i don't think there is any particular problem with them not having the service bit for a while
< sipa>
(up until a bit before the fork, when they'll want preferential peering)
< BlueMatt>
sipa: I dont believe they've implemented any "week before, force service bit on" logic
< BlueMatt>
so that they can maximize network disruption and possible isolate some nodes
< Murch>
Luckily, if the node count stays like this, it'll be likely only disrupt their nodes.
< BlueMatt>
true, but it still seems needlessly stupid...the only reason to have that option is to troll, but, then, that seems to be what 2x is all about
< Murch>
of course it's stupid, but if they're being stupid and only hurting themselves, that's less of an issue than if they were being stupid and hurting others
< wxxs>
wouldn't they rather isolate their own nodes this way? Do the 2X CEOs know what their engineer is doing?
< BlueMatt>
well they're risking it - if some charitable person decides 2x doesnt have enough nodes so spins up some crazy sybil like we've seen with all the previous forks, they could cause issues for both themselves and others
< gmaxwell>
We need bad block interogation.
< gmaxwell>
Whenever we reject a bad block, we should remember it, and try fetching it from every other peer we connect to... and then ban any that serve it to us.
< gmaxwell>
Still won't prevent isolation from s2x nodes entirely but it would make it less bad.
< BlueMatt>
grrr, why didnt they fucking use the hardfork bit
< gmaxwell>
because that would minimize disruption.
< BlueMatt>
trolls gonna troll.....
< wxxs>
provocation?
< gmaxwell>
the whole strategy of s2x is to try to force people to accept their rule change by disrupting everything else.
< sturles>
I suggest to just write a script which periodically scan getpeerinfo for 2x, then limit their bandwidth to a minimum where they will still stay connected. I used to do that with BU, XT, etc.
< sturles>
They don't seem to thinkt that bandwidth can be a problem to anyone, so it shouldn't bother them.
< achow101>
gmaxwell: I've been thinking about bad block interrogation. How would you be able to distinguish between they don't have the block, they didn't accept the block, and they're just taking a really long time to respond with the block?
< andytoshi>
probably sufficient to send them a request for it, set a flag somewhere, and then if they ever reply with the block, ban them
< sipa>
it could also be done based on headers
< sipa>
as long as difficulty rule isn't modified, we'll learn about all chains our peers have through the headers
< gmaxwell>
achow101: I don't think we need to.
< gmaxwell>
achow101: we ask for it. ... and seperately anyone who ever sends it to use gets punted.
< gmaxwell>
we don't even have to track if we asked
< gmaxwell>
though sipa notes doing it through the header is even stronger and simpler.
< achow101>
gmaxwell: well right now we only ban the first person who relays us an invalid block. So I suppose we can just change that to ban anyone who relays us an invalid block regardless of whether we have already seen it
< achow101>
I was already thinking about just using headers. It can all be done in ProcessNewBlockHeaders I think
< gmaxwell>
achow101: yes, kind of, but if its burried when they connect they won't send it to us.
< achow101>
gmaxwell: if it's buried, couldn't we imitate IBD?
< bitcoin-git>
bitcoin/master 634e38c Anditto Heristyo: [Tests] Add Qt GUI tests to Overview and ReceiveCoin Page
< bitcoin-git>
bitcoin/master f199b8a MarcoFalke: Merge #11365: [Tests] Add Qt GUI tests to Overview and ReceiveCoin Page...
< gmaxwell>
I don't think we need to in any case, ejecting any peers that has a header chain with a block we consider invalid is sufficient, and simpler than anything with fetching blocks.
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11365: [Tests] Add Qt GUI tests to Overview and ReceiveCoin Page (master...Adding-Qt-tests) https://github.com/bitcoin/bitcoin/pull/11365
< achow101>
so we can just ask a peer for the headers starting from block X where block X is invalid to us. If they respond with headers, then ban
< achow101>
by imitating IBD I meant doing the whole fetch 2000 headers thing starting from some block X and seeing if they responded to us with those headers
< gmaxwell>
well there are two degress of badness to think about, one is if their best chain contains a block we consider invalid and the other is if they accept a block we consider invalid at all even if its not in their best chain right now.
< achow101>
If a block is not in their best chain, we can't fetch it, no?
< gmaxwell>
we can, if it's not too far outside of it.
< achow101>
but if it is too far outside of the best chain, we can't determine whether they accepted it or not
< gmaxwell>
it avoids a case where it was on their best chain, they offered it to us, we attempted to fetch it... but were too slow.
< gmaxwell>
yes, if it's too far outside we can't, indeed.
< achow101>
unless we give them the block, but that risks getting us banned
< bitcoin-git>
bitcoin/master 1088b53 Gregory Sanders: add functional test for mempoolreplacement command line arg
< bitcoin-git>
bitcoin/master 8ddf60d MarcoFalke: Merge #11407: [tests] add functional test for mempoolreplacement command line arg...
< gmaxwell>
But I don't think the too far limit is that limiting.
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11407: [tests] add functional test for mempoolreplacement command line arg (master...testmempoolreplacearg) https://github.com/bitcoin/bitcoin/pull/11407
< achow101>
the too far limit is one month.
< achow101>
I guess we can't cover the case where we are connected to an isolated peer that is following different consensus rules
< r251d>
If a set of nodes wanted to protect against a 51% attack, they might collectively decide to invalidateblock on an attacking block. The coordination may be difficult, deciding whether a block constitutes an attack, but it may be helpful for the defending nodes to be able to reconsiderblock in some cases. In that scenario, the temporarily invalidated block may not be a bannable offense for nodes who
< r251d>
relayed it.
< gmaxwell>
r251d: if it isn't your defence won't work well, because you'll invalidate that block but be surrounded by nothing but peers that have it, and so not even hear about the other chain.
< gmaxwell>
so you're actually giving an argument for the importance of kicking off peers that have a block you consider invalid in their best chain.
< Oda_nobunaga>
Yesterday Adam talked about "bunker mode" on slack: that is, if I understood well, a way to build the chain by selecting blocks sort of manually, and invalidating blocks from a suspected 51% attack?
< r251d>
I was hoping that a hypothetical "bunker mode" could keep connections with nodes that have alternative tips until social coordination decided on the best one to follow.
< Oda_nobunaga>
I was also wondering about the reaction to a 51% attack. How long would a PoW change take? Would we be talking hours or weeks?
< Oda_nobunaga>
I'm afraid that Jihan might use the threat of a reorg attack (very implicitly worded of course) as a way to sap confidence in the original chain, and scare people away from investing in it - thus deflating its price and possibly chasing more hash power away. The mere threat of an attack could work almost as well as an actual one.
< sipa>
please keep this channel about software development
< Oda_nobunaga>
Sorry, I was eager to get devs opinions about this. Perhaps this would be more suited for #bitcoin
< mryandao>
i was wondering if it would be possible to remove the libboost dependency for bitcoin-cli so it is possible to compile separately on a lightweight node with minimal libs.
< achow101>
mryandao: what does bitcoin-cli use boost for?
< mryandao>
that's exactly my question a week ago
< mryandao>
if you run `ldd` on it, you will see that bitcoin-cli requires libboost
< achow101>
oh, its for thread management
< achow101>
and some of the things it includes requires boost
< mryandao>
ok, i see.
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #11438: Updated Windows build doc for WSL/Xenial workaround (master...wslbuilddoc) https://github.com/bitcoin/bitcoin/pull/11438
< bitcoin-git>
[bitcoin] promag opened pull request #11439: [test] Refactor ZMQ test to use one address per notification type (master...2017-10-clean-zmq-test) https://github.com/bitcoin/bitcoin/pull/11439
< BlueMatt>
I'd love to see someone actually document what in the hell the zmq stuff actually does, yes
< BlueMatt>
once we have such a doc, I think it'd be reasonable to deprecate certain behaviors being normative, eg the ordering restrictions
< promag>
later jonasschnelli added sequence which I believe is not documented (sorry if it is)
< BlueMatt>
its mentioned, but only in passing, no what the fuck format it has
< promag>
agree BlueMatt, I'll improve the doc
< BlueMatt>
I dont think we should remove ordering for a release or two, however
< promag>
I can split the PR in 2 - cleanup + remove-ordering
< promag>
create a 3rd improve-doc
< BlueMatt>
I dont think we should remove ordering until 0.17, assuming we have docs noting it is non-normative in 0.16
< BlueMatt>
(also cause there is no rush)
< BlueMatt>
we have no reason to need to remove ordering, and probably will keep the same ordering requirements in validationinterface
< promag>
From the client perspective, it should not rely on the order not because of bitcoind but because of zmq
< BlueMatt>
are you sure zmq doesnt provide consistent ordering?
< esotericnonsense>
zmq is only guaranteed to preserve order over TCP
< BlueMatt>
you may lose messages but I'd assume in practice its ordered
< BlueMatt>
heh, ok, so in common-usage its guaranteed to preserve order :p
< esotericnonsense>
and only in the simple case with no proxies that may cause different paths to be taken by different messages
< BlueMatt>
<BlueMatt> heh, ok, so in common-usage its guaranteed to preserve order :p
< esotericnonsense>
hehe
< promag>
> probably will keep the same ordering requirements in validationinterface - where is this tested (beside in zmq)?
< BlueMatt>
stuff that calls into wallet is required, mostly
< BlueMatt>
depends on which calls zmq uses, I dont recall
< BlueMatt>
do we have a standard for adding options to rpc calls now? we have named args, but also lots of stuff in options{} objects....do we prefer one for new things?
< sipa>
i prefer using named arguments over options - easier or equally easy to use
< sipa>
unless it's options that apply to only some arguments (like per-output options in createrawtransactions eg)
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11440: Fix validationinterface build on super old boost/clang (master...2017-10-cblock-validationinterface) https://github.com/bitcoin/bitcoin/pull/11440
< gmaxwell>
results in a terrible commandline expirence either way.