< bitcoin-git>
[bitcoin] jimpo opened pull request #11116: [script] Unit tests for script/standard and IsMine functions. (master...script-standard-tests) https://github.com/bitcoin/bitcoin/pull/11116
< bitcoin-git>
bitcoin/master a65e028 practicalswift: Build with --enable-werror under OS X
< bitcoin-git>
bitcoin/master 2c9f5ec Wladimir J. van der Laan: Merge #10923: travis: Build with --enable-werror under OS X...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10923: travis: Build with --enable-werror under OS X (master...thread-safety-analysis) https://github.com/bitcoin/bitcoin/pull/10923
< bitcoin-git>
bitcoin/master ecb11f5 Andreas Schildbach: Document the non-strict-DER-conformance of one test in tx_valid.json....
< bitcoin-git>
bitcoin/master 31b2612 Wladimir J. van der Laan: Merge #10679: Document the non-DER-conformance of one test in tx_valid.json....
< bitcoin-git>
[bitcoin] laanwj closed pull request #10679: Document the non-DER-conformance of one test in tx_valid.json. (master...tx-valid-comment) https://github.com/bitcoin/bitcoin/pull/10679
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #11119: [doc] build-windows: Mention that only trusty works (master...Mf1708-docBuildWinTrusty) https://github.com/bitcoin/bitcoin/pull/11119
< bitcoin-git>
[bitcoin] instagibbs opened pull request #11120: verifytxoutproof returns object including blockhash (master...verifytxoutproof-blockhash) https://github.com/bitcoin/bitcoin/pull/11120
< michagogo>
Hmm, the gitian build is taking a really long time
< michagogo>
2:20 and counting and it's still on Linux
< michagogo>
Oh, that's probably because it first does all the depends, on 4 architectures
< luke-jr>
does pay-to-contract require disclosing the pubkey to prove the commitment?
< gmaxwell>
Yes, at least if its not constructed in the totally busted way thats posted on the list.
< luke-jr>
aww, nuts. would have been a nice way to commit to a second key used to sign messages and such
< luke-jr>
guess that will need to wait for MAST-type stuff
< instagibbs>
luke-jr, why do you think #11089 is 0.16 and not 0.15.1
< wumpus>
0.15.1 was going to be the segwit wallet release
< wumpus>
so P2SH-P2WPKH sounded like something to backport for that, let me know if wrong
< instagibbs>
If we're supporting nested-p2sh that makes perfect sense
< wumpus>
that's a lower target than full native p2wsh so I think we should in any case
< luke-jr>
wumpus: eww
< wumpus>
what?
< luke-jr>
segwit wallet release should just be an early 0.16
< luke-jr>
it's new features
< wumpus>
we discussed this in the meeting
< wumpus>
not going to renegotiate on this
< luke-jr>
I don't remember that at all. And meetings aren't for decisions anyway, remember?
< luke-jr>
anyhow, not worth arguing over. just a dumb label.
< wumpus>
yeah, exactly, we want to do an early segwit wallet release and 0.15.1 is as good as any label imo, yes it's a feature but at least a specific one that we really need now
< wumpus>
it's kind of stupid that segwit is activating and the wallet isn't 100% ready for it
< wumpus>
but anyhow
< luke-jr>
not like we're short on numbers in any field *shrug*
< wumpus>
yeah we could still delay 0.15.0
< wumpus>
but adding a feature betwen rcs would be even more heresical so...
< luke-jr>
def don't delay 0.15 :p
< luke-jr>
I meant just 0.16 in a few months ASAP, and 0.17 for the next big one
< wumpus>
whatever we do people will complain
< wumpus>
I wouldn't have minded that
< luke-jr>
anyway, tagging it for interim-segwit-release is fine, I was just confused by the numbering
< wumpus>
just to have less time between major releases for once, but read back the meeting log, most preferred 0.15.1 as segwit wallet release at least I remember
< wumpus>
and yes versions are just user communication, confusion can be taken away by being clear in the release notes, hey at least we don't suddenly change to 1.x.y or 14.x.y or 9.9.9 like some crazy spin-offs...
< luke-jr>
haha
< instagibbs>
ok, at least we're in agreement in what kind of release it will be.