< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/77fc469fc78c...3f726c99f819
< bitcoin-git> bitcoin/master f1708ef practicalswift: Add recommendation: By default, declare single-argument constructors `explicit`
< bitcoin-git> bitcoin/master 3f726c9 MarcoFalke: Merge #11112: [developer-notes] By default, declare single-argument constructors "explicit"...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11112: [developer-notes] By default, declare single-argument constructors "explicit" (master...declare-single-argument-constructors-explicit) https://github.com/bitcoin/bitcoin/pull/11112
< luke-jr> hm, do we still warn about BIP91?
< meshcollider> sipa: gmaxwell is the idea that the full serialised transaction has to be obtainable just from the compressed transaction, for hashing, etc? i.e. no throwing away of data even if it's unused but hashed?
< Lightsword> luke-jr, warn about what in regards to BIP91?
< sipa> meshcollider: indeed
< luke-jr> Lightsword: unknown versionbit deployment
< Lightsword> luke-jr, why would it be showing anything anymore? it didn’t use.a 2016 block activation period so it shouldn’t show as activated
< Lightsword> hmm, well I do see “Warning: Unknown block versions being mined! It's possible unknown rules are in effect” but that’s not a version bit specific warning right?
< Lightsword> warning='59 of last 100 blocks have unexpected version'
< sipa> Lightsword: those are from miners who are still signalling segwit
< sipa> not bip91
< Lightsword> yep…guess I’ll tell them to turn that off
< luke-jr> ah
< gmaxwell> meshcollider: because the hashes are normative there is no unused data.
< meshcollider> i mean unused in the sense of having no actual function, not just unused in general. E.g. the transaction locktime, if all the sequence numbers are set to 0xffffffff
< gmaxwell> meshcollider: almost always the locktime is zero in that case, however.
< meshcollider> yeah I'd imagine so, so most of the time it would be encoded in the TxHeader in that case right 👍
< meshcollider> what is the reason for choosing 0-14 for the nLockTime = TxVersionCode? Why 14?
< gmaxwell> that is a misprint, that is nVersion = TxVersionCode.
< gmaxwell> (because why would nLocktime be _versionCode_ :) )
< gmaxwell> so tx versions 0-14 are explicitly coded, and any version greater than that ends up as a uint32.
< meshcollider> mhm I did wonder haha, seemed odd. sipa, you might want to update that
< gmaxwell> the document isn't really intended for public consumption.
< gmaxwell> (not to say that he won't fix it, but this is just working notes)
< meshcollider> regardless, was there any specific reason for choosing 14 for the version code?
< gmaxwell> because it room for plenty of transaction versions, and leaves space to signal future encoding versions.
< meshcollider> makes sense :) are the blank sections not thought out or just not written up
< meshcollider> guessing the latter because back references sounds like something which wouldn't just be added in without a plan
< gmaxwell> it's just not written up. pieter implemented an encoder, which is how we know what the space savings is.
< gmaxwell> (actually it looks like all the parts are actually describe in the bulleted lists, but not explained)
< meshcollider> it looks really well thought out and comprehensive to me, that's awesome :) so would compressed blocks just have a new compressed block header and contain compressed transactions like this?
< luke-jr> meshcollider: blocks aren't typically transmitted as a big data blob anymore anyway
< gmaxwell> except in ibd.
< gmaxwell> it's just an alternative encoding of transactions, and blocks are transmited as a header and a bunch of transactions.
< meshcollider> Ah I guess block headers are only 80 bytes anyway, probably not worth even trying to compress them more?
< luke-jr> they're already compressed somewhat IIRC
< gmaxwell> well for headers messages it's useful to compact them, but thats pretty orthorgonal to blocks.
< luke-jr> (when sent as a chain, the prevblock part is skipped)
< gmaxwell> in a message that sends a lot of headers you can roughly halve their size.
< gmaxwell> ::sigh::
< gmaxwell> 2017-08-25 06:50:40.485126 UpdateTip: new best=0000000000000000007a3061573f5bba379cc02eb472e96f0941d37548fd2982 height=481946 version=0x20000002 log2_work=86.989803 tx=249281504 date='2017-08-25 06:50:23' progress=1.000000 cache=14.2MiB(50014txo) warning='60 of last 100 blocks have unexpected version'
< gmaxwell> wumpus: gonna updates submittx for segwit?
< wumpus> gmaxwell: it's in the plans
< gmaxwell> wumpus: hurray.
< Murch> gmaxwell: Am I correct to assume that SegWit will be supported in 0.15.1 and that could be expected shortly after 0.15?
< gmaxwell> yes, thats our current tenative plan.
< gmaxwell> (I say tenative just because the work hasn't been done yet, people are working on it)
< gmaxwell> (of course, much of the backend wallet support was already done as part of the development of segwit itself... just not the more user facing parts)
< Murch> okay
< gmaxwell> 00000000000000000139cb443e16442fcd07a4a0e0788dd045ee3cf268982016 ... A block larger than 1MB!
< gmaxwell> also, three cheers for bc.i for actually displaying this fact! https://blockchain.info/block-height/481947
< gmaxwell> murch: congrats on your txn.
< juscamarena> I made this one that made it go over 1MB https://blockchain.info/tx/8ef2d3c3e8ff4d937746aa39677b347c043287c1fbfeda34b9c241f1e85173ec thanks again for segwit! Works great!
< gmaxwell> juscamarena: thanks. we noticed the block earlier.
< gmaxwell> we need to do more work reaching out to miners and getting them to fix their settings, lots of confusion.
< gmaxwell> (there have been several other points where my node would have mined a greater than 1MB block... but the miner that got the block had a 1MB limit.)
< juscamarena> We would have gotten an earlier one but yeah
< bitcoin-git> [bitcoin] laanwj opened pull request #11131: rpc: Write authcookie atomically (master...2017_08_atomic_cookie) https://github.com/bitcoin/bitcoin/pull/11131
< sturles> Is there a patch to make segwit addresses for change outputs?
< bitcoin-git> [bitcoin] practicalswift opened pull request #11132: [wallet] Document assumptions that must be fulfilled to avoid NULL pointer dereferences (master...document-non-nullptr-assumptions) https://github.com/bitcoin/bitcoin/pull/11132
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11129: [qa] util: Poll cookie file size before reading (master...Mf1708-qaPollCookie) https://github.com/bitcoin/bitcoin/pull/11129
< instagibbs> what exactly does contrib/verify-commits/verify-commits.sh do?
< MarcoFalke> read the commits, starting from HEAD, checking if there is at least one signed parent
< MarcoFalke> only taking into account the keys of maintainers
< bitcoin-git> [bitcoin] practicalswift opened pull request #11133: Document assumptions that must be fulfilled to avoid division by zero (master...div0) https://github.com/bitcoin/bitcoin/pull/11133
< promag> Maybe we should make all RPC responses an JSON object, that way it is easier to avoid breaking changes cc instagibbs
< instagibbs> promag, in general avoiding breakage is good, but I think verifytxoutproof is a bit less used(and isn't returning what's actually required to be entirely useful)
< promag> yeah, I mean maybe add developer note for future calls.
< bitcoin-git> [bitcoin] promag opened pull request #11135: Add RPC response notes (master...2017-08-rpc-response-notes) https://github.com/bitcoin/bitcoin/pull/11135
< bitcoin-git> [bitcoin] danra opened pull request #11136: Docs: Add python3 to list of dependencies on macOS (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11136
< bitcoin-git> [bitcoin] danra opened pull request #11138: Compat: Simplify bswap_16 implementation (master...patch-2) https://github.com/bitcoin/bitcoin/pull/11138
< luke-jr> jonasschnelli: what's the status of your stats_*_tmp branches? seems you added a typo? O.o
< luke-jr> (precision -> percision)
< luke-jr> hm, or maybe the rpc one is obsolete
< luke-jr> or both are :x
< bitcoin-git> [bitcoin] danra opened pull request #11139: Trivial: Whitespace in bswap_64 implementation (master...patch-3) https://github.com/bitcoin/bitcoin/pull/11139
< bitcoin-git> [bitcoin] danra opened pull request #11140: Trivial: Improve #endif comments (master...patch-4) https://github.com/bitcoin/bitcoin/pull/11140
< bitcoin-git> [bitcoin] wrapperband opened pull request #11142: Enhance getinfo with regtest information (0.15...0.15-GetInfo-regtest) https://github.com/bitcoin/bitcoin/pull/11142
< rhavar> For a "pure" segwit transaction (p2sh) is this formula correct: estimatedVSizeOfSegwitTransaction(inputCount, outputCount) { return 92 * inputCount + 12 + 32 * outputCount; }
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11142: Enhance getinfo with regtest information (0.15...0.15-GetInfo-regtest) https://github.com/bitcoin/bitcoin/pull/11142
< bitcoin-git> [bitcoin] danra opened pull request #11143: Fix include path for bitcoin-config.h (master...patch-5) https://github.com/bitcoin/bitcoin/pull/11143
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11139: Trivial: Whitespace in bswap_64 implementation (master...patch-3) https://github.com/bitcoin/bitcoin/pull/11139
< bitcoin-git> [bitcoin] danra opened pull request #11144: Move local include to before system includes (master...patch-6) https://github.com/bitcoin/bitcoin/pull/11144
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/3f726c99f819...07c92b98e2a0
< bitcoin-git> bitcoin/master d97fe20 Russell Yanofsky: Move some static functions out of wallet.h/cpp...
< bitcoin-git> bitcoin/master e7fe320 Russell Yanofsky: MOVEONLY: Fee functions wallet/wallet.cpp -> wallet/fees.cpp
< bitcoin-git> bitcoin/master f01103c Russell Yanofsky: MOVEONLY: Init functions wallet/wallet.cpp -> wallet/init.cpp
< bitcoin-git> [bitcoin] laanwj closed pull request #10976: [MOVEONLY] Move some static functions out of wallet.h/cpp (master...pr/wmove) https://github.com/bitcoin/bitcoin/pull/10976
< luke-jr> wumpus: can we get #7339 reopened and in? apparently it won't be n/a as early as expect
< bitcoin-git> [bitcoin] morcos opened pull request #11145: Fix rounding bug in calculation of minimum change (master...fixrounding) https://github.com/bitcoin/bitcoin/pull/11145
< morcos> ok sorry guys if i killed 0.15 being on time, please review ^^ ASAP
< instagibbs> you can blame the person reporting :P
< * sipa> blames the person who merged the PR that introduced the error
< sipa> oh, wait...
< MarcoFalke> I blame Satoshi
< gmaxwell> well I'm very glad to have found this, would have been an irritating issue. "payments randomly fail" :(
< bitcoin-git> [bitcoin] eaxvac opened pull request #11147: Merge remote-tracking branch 'refs/remotes/bitcoin/master' (master...master) https://github.com/bitcoin/bitcoin/pull/11147
< bitcoin-git> [bitcoin] eaxvac closed pull request #11147: Merge remote-tracking branch 'refs/remotes/bitcoin/master' (master...master) https://github.com/bitcoin/bitcoin/pull/11147
< bitcoin-git> [bitcoin] danra opened pull request #11148: Trivial: Fix outdated comment (master...patch-7) https://github.com/bitcoin/bitcoin/pull/11148
< morcos> gmaxwell: yeah unfortunately there are a lot o changes in that code, where fees and change can be adjusted... so its really hard to think through and be sure there isn't some edge case we're missing.
< gmaxwell> I feel like we should have some kind of exceptional case flagging infrastructure. So that there are varrious exceptional cases which are triggerable, but should only be triggered by a specific test and otherwise we want to know about them.
< morcos> it'll be nice to rewrite all this for 0.16... and i think i still feel it's safer to error there rather than risk continuing in some way
< bitcoin-git> [bitcoin] danra opened pull request #11149: Use prefix instead of postfix increment/decrement for non-trivial typ… (master...prefix-increment) https://github.com/bitcoin/bitcoin/pull/11149
< bitcoin-git> [bitcoin] mess110 opened pull request #11150: [tests] Add getmininginfo functional tests (master...test_rpc_getmininginfo) https://github.com/bitcoin/bitcoin/pull/11150
< MarcoFalke> Where did juscamarena report the issue about the fee "rounding bug"?
< instagibbs> MarcoFalke, originally to me, I forwarded to morcos since it was code he wrote(IIRC)
< MarcoFalke> Ah
< MarcoFalke> So the issue is that fees are *underpayed*
< MarcoFalke> s/payed/paid/
< instagibbs> it re-tries assuming it has enough input value, then somehow doesn't, and panics