< 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?
< 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?
< 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)
< 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
< 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
< 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] 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
< 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