< luke-jr> no
< luke-jr> unless a buffer overflow or smth
< phantomcircuit> CScript expect = CScript() << nHeight;
< phantomcircuit> for values less than 10 CScript can encode them using the constant opcodes
< luke-jr> phantomcircuit: btw, add yourself to https://en.bitcoin.it/wiki/Segwit_support
< phantomcircuit> 1-75 i guess
< phantomcircuit> are probably wrong in every pools implementation of this
< phantomcircuit> er
< phantomcircuit> 1-17 that is
< luke-jr> oh, lol
< phantomcircuit> yeah i doubt anybody has that one right
< phantomcircuit> i certainly dont
< phantomcircuit> Lightsword, ^
< Lightsword> phantomcircuit, oh…yeah I had an issue at around that I recall
< phantomcircuit> Lightsword, why though?
< phantomcircuit> nothing new should be using that commitment
< phantomcircuit> just change it to use the locktime or whatever it is
< Lightsword> for testnets which immediately enforce BIP34
< Lightsword> “for values less than 10 CScript can encode them using the constant opcodes” how would that work?
< sipa> use OP_5 rather than 0x01 0x05
< sipa> Lightsword: is that from the BIP?
< sipa> that's not implemented in the consensus rules...
< luke-jr> ?
< sipa> using OP_n for the height in BIP34
< sipa> oh, he was quoting phantomcircuit
< sipa> no, the << operator on CScript always does a data push, never an OP_n
< Lightsword> so block heights 1-17 are encoded differently?
< phantomcircuit> sipa, really?
< phantomcircuit> sipa, push_int64 seems to implement the 1-17 encoding thing
< phantomcircuit> sipa, yeah no it only does data pushes if it's data you're pushing
< phantomcircuit> does use constants if it's an integer though
< sipa> phantomcircuit: i once tried to "fix" that, and ended up almost created a consensus bug
< sipa> Lightsword: no, they're all encoded the same
< Lightsword> sipa, same as each other or same as block 18-127?
< phantomcircuit> sipa, it seems like the push int things have always handled the shorter encodings
< phantomcircuit> sipa, wait how would fixing that cause a consensus bug
< luke-jr> phantomcircuit: encoding must be identical for height
< luke-jr> although I guess BIP34 was never enforced at those heights for mainnet
< phantomcircuit> sipa, yeah it's exactly what i thought
< phantomcircuit> height 1-75 are all single byte encodings
< sipa> phantomcircuit: sure
< sipa> single byte lengths
< sipa> phantomcircuit: but << will never cause an OP_n
< phantomcircuit> sipa, no it does
< phantomcircuit> try changing regtest to requite bip34 at height 2
< phantomcircuit> you'll see
< Lightsword> so how exactly do you do BIP34 single byte encodings?
< sipa> Lightsword: it's always the same!
< sipa> push the number as bytes
< sipa> heights 0 through 255 or 0x01 + 1 byte
< sipa> 256 through 65535 are 0x02 + 2 bytes
< sipa> 65536 through 16777215 are 0x03 + 3 bytes
< Lightsword> uh, luke said the “len2/len3 ought to be 32768 and 8388608”
< sipa> oh, right, signed
< sipa> ignore what is aid
< sipa> but there is nothing special about low heights
< phantomcircuit> sipa, im quite certain you are wrong there
< NicolasDorier> I am having issues to build:
< NicolasDorier> I tried git clean -dfx and everything I could
< NicolasDorier> it just explode here
< NicolasDorier> posted issue on https://github.com/bitcoin/bitcoin/issues/10622
< sipa> phantomcircuit: look at the code
< sipa> phantomcircuit: hmm, seems i'm wrong!
< sipa> wut
< sipa> very confused about history now
< Lightsword> hmm, so this is a block at height 1 that’s getting “ERROR: AcceptBlock: bad-cb-height, block height mismatch in coinbase (code 16)” any idea what’s wrong with it? https://0bin.net/paste/BzoPFsAofSo1zeSM#KF5e3O9H-+/txOlckwy13c6w0NKRpwek5OKgoToalA/
< phantomcircuit> Lightsword, can you just paste the coinbase scriptsig?
< Lightsword> should be 0101000493164659045433cd380c9916465985184659b22100000a636b706f6f6c162f426974636f696e2d496e6469612f4249503134382f I think
< phantomcircuit> should be 52 at the front
< Lightsword> phantomcircuit, hmm, any idea how I would get that using this serialization code? https://0bin.net/paste/AP402Ma-yujCRW8H#WBhmhyL1i5L0BJhLqKjMH39sQdmBMRgapFrXJkp4sD3
< luke-jr> phantomcircuit: why 52?
< phantomcircuit> luke-jr, OP_1 is 52
< phantomcircuit> 0x51
< phantomcircuit> ok im off by 1
< luke-jr> Lightsword: if (val < 17) { s[0] = 0x50 + val; return 1; }
< luke-jr> then your remaining bug is if you were to mine a genesis block, but that'd be dumb
< Lightsword> luke-jr, yep that worked
< luke-jr> Lightsword: what are you even doing? <.<
< Lightsword> screwing around with local testnets
< phantomcircuit> is that the only place where the encoding rules for CScript is a consensus rule?
< phantomcircuit> i think it is
< Lightsword> so how did this abomination happen? :P
< luke-jr> Lightsword: which part? :P
< Lightsword> luke-jr CScript encoding rules being consensus critical
< luke-jr> Lightsword: I don't know that it's a bad thing.
< luke-jr> BIP 62 was going to do the same
< phantomcircuit> Lightsword, gavin
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #10623: doc: Add 0.14.2 release notes (master...Mf1706-docRel) https://github.com/bitcoin/bitcoin/pull/10623
< lifeofguenter> hi all - is it normal for maxconnections to be limited to < 1024 ? I would have thought with libevent there would be virtually no limit of such?
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cafe24f039e1...e053e05c1305
< bitcoin-git> bitcoin/master 7810993 John Newbery: [trivial] fix indentation for ArgsManager class
< bitcoin-git> bitcoin/master e053e05 MarcoFalke: Merge #10592: [trivial] fix indentation for ArgsManager class...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10592: [trivial] fix indentation for ArgsManager class (master...argsmanager) https://github.com/bitcoin/bitcoin/pull/10592
< bitcoin-git> [bitcoin] MarcoFalke pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/e053e05c1305...643fa0b22d70
< bitcoin-git> bitcoin/master 4a0c08f John Newbery: [tests] update zmq test to use correct config.ini file
< bitcoin-git> bitcoin/master 5ebd5f9 John Newbery: [tests] tidy up zmq_test.py
< bitcoin-git> bitcoin/master b1bac1c John Newbery: [tests] in zmq test, timeout if message not received
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10552: [Test] Tests for zmqpubrawtx and zmqpubrawblock (master...zmq-raw-tests) https://github.com/bitcoin/bitcoin/pull/10552
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #10552: [Test] Tests for zmqpubrawtx and zmqpubrawblock (master...zmq-raw-tests) https://github.com/bitcoin/bitcoin/pull/10552
< luke-jr> 10790 installs of 0.14.1 from Core's official PPA.. :o
< luke-jr> about 22% of all 0.14.1 nodes
< luke-jr> BlueMatt: ^
< gaf_> luke-jr, can you share link of charts?
< luke-jr> gaf_: no, there aren't any such charts
< luke-jr> and getting the install counts needs some stupid Python mess :/
< luke-jr> some modules of which only support Python3, and others which only support Python2, curiously enough (I used 2to3 to get them to work together)
< draadpiraat[m]> 0.14.2 release note link seems broken?
< draadpiraat[m]> disregard me, I just noticed the PR for it
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #10626: doc: Remove outdated minrelaytxfee comment (master...Mf1706-docInit) https://github.com/bitcoin/bitcoin/pull/10626
< luke-jr> * [new tag] v0.14.2.knots20170618 -> v0.14.2.knots20170618 <-- midnightmagic, wumpus, and anyone else who can contribute gitian builds..
< BlueMatt> luke-jr: dear god dont tell me that
< BlueMatt> luke-jr: also, I'm entirely sure most of those are not always running, so its a much, much smaller percentage of total 0.14.1 nodes
< luke-jr> BlueMatt: "not always running" still counts as a node IMO
< BlueMatt> sure, but it means there are more nodes of the non-ppa variety that you arent aware of, so your percentage is skewed
< BlueMatt> not counting nodes behind nat and the like that may have never gotten their addr relayed
< luke-jr> BlueMatt: no, I'm counting them in the total too
< BlueMatt> no, cause addrs dont get relayed reliably
< draadpiraat[m]> forgive me for cursing in the church, but is anyone here monitoring the btc1 repo?
< draadpiraat[m]> I've been trying to analyze what the hardfork code changes do but the spaghetti factor is high