< gmaxwell>
Nice to confirm that it was actually an OOM at aleast.
< Chris_Stewart_5>
Has anyone looked into the supposed testnet chain fork at 1094169?
< Chris_Stewart_5>
Is a two day testnet chain split possible? There definitely seems to be a split according to what a couple of block explorers I have looked at. The blocks were mined 2 days ago
< Chris_Stewart_5>
I don't have an synced testnet node to look at my own node :/
< Lightsword>
oh, yeah I’m not at same height as blocktrail, I’ll dump some hashpower on testnet and fix it
< Chris_Stewart_5>
Lightsword: So basically this is happening because difficulty is so low it is viable to have two competing chains that are that long?
< Lightsword>
guess someone mined an invalid block and overtook the valid chain
< Lightsword>
it will reorg when valid gets more work…which should be soon now
< Chris_Stewart_5>
So IIRC bitcoin core stores invalid blocks on disk too right? Seems weird that block explorers would display a chain built on an invalid block...
< Lightsword>
no
< Lightsword>
some block explorers are probably not running full nodes
< sipa>
it will only store things whose block _headers_ are valid
< sipa>
it can't know whether the block is fully valid without having all blocks before it
< sipa>
so it will store potentially invalid blocks if they have valid headers
< Chris_Stewart_5>
Lightsword: sipa Thanks for the explanations!
< Lightsword>
so looks like block 000000000000034ba26cee29d86f20d6ead376aa1b868c14fd13bacac54959de is invalid
< Lightsword>
coinbase tag is “Bitprim Project”
< Chris_Stewart_5>
Lightsword: What is illegal about that? Can't the coinbase scriptSig be anything as long as it is more than 4 bytes and less than 100 IIRC
< gmaxwell>
"Bitprim is a 100% compatible BItcoin PRotocol IMplementation."
< Lightsword>
coinbase sig isn’t what’s invalid I don’t think
< gmaxwell>
I like that there is a commit there with 0 changed files called "some improvements", can't mess with perfection, I guess. :)
< talmai>
"perfection isn't a fact, it's an opinion"
< Chris_Stewart_5>
So essentially these block explorers are running nodes -- but skipping some sort of validation i.e. script validation. However these must have some sort of UTXO set
< sipa>
Chris_Stewart_5: why do they need a utxo set?
< sipa>
they just show blocks
< sipa>
oh, to show whether outputs are spent, right
< sipa>
but they need way more than a utxo set... they need a database that says for each output where it is spent even
< Chris_Stewart_5>
A little scary if this could be executed on main chain, could be used as a scare tactic. I guess we can't figure out how deep the rabbit hole goes since they run custom infrastructure
< gmaxwell>
because that gets in the way of showing things.
< morcos>
sdaftuar took a quick look earlier and said it looked like there was a witness commitment in coinbase but at least one tx that needed a witness was missing it .
< kitsu>
Does the client support skipping validation of the incoming txs?
< luke-jr>
of course not? what would even be the point?
< kitsu>
luke-jr: just care about world climate
< paveljanik>
-blocksonly? ;-)
< luke-jr>
kitsu: skipping validation of your incoming txs would have basically no effect
< paveljanik>
faster ban from your peers...
< wumpus>
kitsu: then blocksonly is even better, as your client will request not to receive transactions at all
< kitsu>
yeah, that probably what I'm searching
< kitsu>
thanks!
< wumpus>
if you're going to not validate them anyway that's preferable
< afk11>
I was in here last week asking about the same.. eventually someone put some hashrate back on and v0.12 nodes were in sync with v0.13+ testnet nodes. just unfortunate they didn't upgrade on time. I assume it's due to spending a witness output?
< Lightsword>
afk11, fork seems to an alternative full node “Bitprim”
< Lightsword>
I dumped some hashpower on testnet and killed the invalid chain
< Chris_Stewart_5>
afk11: Apparently sdaftuar looked into it and said it was it due to a missing witness :/
< NicolasDorier>
I have a super weird problem with the tests
< Victorsueca>
is there a way to make the rest API ignore the rpcallowip? I was hoping to make the rest API on my node public while only allowing my IPs to connect to the JSON-RPC
< sipa>
you shouldn't
< sipa>
it's likely trivial to DoS a system through the rest interface
< Victorsueca>
right... hmmm
< Victorsueca>
not my case, but maybe we should stop assuming that the machine that is running bitcoin core doesn't have it's own DoS protection service and is ready to deal with it
< sipa>
??
< sipa>
if you have your own DoS protection service (whatever that means, any decent one will need application specific logic), it'll need to proxy the calls somewhere anyway
< sipa>
so you'd configure rpcallowip to include the service
< sipa>
still not expose it to the public
< Victorsueca>
right then, now it makes sense, thanks
< BlueMatt>
jonasschnelli: hmm, looks like you signed d42729a8fbb60510322d2d80ef5fa302189318c8 with the wrong subkey (sha1 sig)
< bitcoin-git>
[bitcoin] rat4 opened pull request #10040: wallet: don't leak height of local chain during inital sync (master...patch) https://github.com/bitcoin/bitcoin/pull/10040
< adiabat>
sipa: yayyyyy base32 address spec!
< adiabat>
sipa: will start work on a golang implementation
< gmaxwell>
adiabat: make sure you implement the tests too! :P (and perhaps contribute some more tests)
< sipa>
adiabat: i'll gladly include it in the repo/BIP if it's moderately readable and passes the tests
< phantomcircuit>
sipa, your vps seems to be offline
< sipa>
works fine here
< sipa>
oh, are you having the same blackholing issue as matt has?
< sipa>
for some reason he can't reach my vps
< phantomcircuit>
maybe
< phantomcircuit>
im on att wireless
< phantomcircuit>
which probably means that ip is blackholed by a significant number of providers
< sipa>
that's... unfortunate (and surprising, i'd expect much more frequent reports in that case)
< phantomcircuit>
oh no it's ipv6 issue
< phantomcircuit>
wait what my tethering has an ipv6 address??
< TD-Linux>
sipa, your web server is not listening on ipv6
< TD-Linux>
phantomcircuit, yeah first thing I checked, most mobile connections have ipv6 (or in fact are ipv6 only)
< TD-Linux>
with 6to4 or whatever
< phantomcircuit>
-_- i cant turn this off with network manager apparently
< TD-Linux>
sipa should just delete his AAAA record or listen on ipv6
< phantomcircuit>
ah there hax
< phantomcircuit>
yeah
< sipa>
TD-Linux: done, moved it to bitcoin6.sipa.be (though it may take a few hours)