< bitcoin-git> [bitcoin] fanquake closed pull request #15469: 0.17 (master...0.17) https://github.com/bitcoin/bitcoin/pull/15469
< moneyball> Hi!
< moneyball> Whoops wrong channel
< moneyball> Oh maybe not haha. Yes meshcollider I am
< moneyball> Expect to hear more this coming week
< moneyball> Feel free to ask me questions if you have any
< meshcollider> moneyball: awesome, theres some very cheap flights at the moment so it'd be good to hear asap :)
< moneyball> the dates are set - same as communicated a few months ago. it will precede the breaking bitcoin conference, june 5-7, with the conference being that weekend june 8-9, in amsterdam. so you should feel comfortable booking flights with those dates in mind.
< moneyball> also there is now more information about the conference on the web site https://breaking-bitcoin.com/
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/f3f9c1de19e6...1a8a5ede9fc3
< bitcoin-git> bitcoin/master fa05626 MarcoFalke: rpc: Add RPCHelpMan::IsValidNumArgs()
< bitcoin-git> bitcoin/master fa4ce70 MarcoFalke: rpc: Actually throw help when passed invalid number of params
< bitcoin-git> bitcoin/master 1a8a5ed Wladimir J. van der Laan: Merge #15401: rpc: Actually throw help when passed invalid number of param...
< bitcoin-git> [bitcoin] laanwj merged pull request #15401: rpc: Actually throw help when passed invalid number of params (master...Mf1902-rpcNumArgs) https://github.com/bitcoin/bitcoin/pull/15401
< nanai> hi
< nanai> can i withdraw b2x to bitcoincore v0.17.1 ? or is it only for btc
< bitcoin-git> [bitcoin] laanwj opened pull request #15471: rpc/gui: Remove 'Unknown block versions being mined' warning (master...2019_02_false_positives) https://github.com/bitcoin/bitcoin/pull/15471
< wumpus> uhmmm test_bitcoin is printing loads of these
< wumpus> Error: Specified -walletdir "/tmp/test_bitcoin/1551089075_943311758/tempdir/path_does_not_exist" does not exist
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/1a8a5ede9fc3...b4fc5257b7dc
< bitcoin-git> bitcoin/master 3f5ad62 riordant: Enable PID file creation on Windows
< bitcoin-git> bitcoin/master b4fc525 Wladimir J. van der Laan: Merge #15456: Enable PID file creation on WIN
< bitcoin-git> [bitcoin] laanwj merged pull request #15456: Enable PID file creation on WIN (master...master) https://github.com/bitcoin/bitcoin/pull/15456
< provoostenator> Is there a SegWit v1 proposal on the bitcoin-dev list or elsewhere that I just managed to overlook? I though gmaxwell referred to that a few days ago in the context of SIGHASH_NO_INPUT_FULL_DISCLAIMER
< luke-jr> provoostenator: I sent one like a year ago, but I think there's been more recent work since (possibly unrelated?)
< bitcoin-git> [bitcoin] qingqingzijjin opened pull request #15472: Create Bitcoin (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15472
< provoostenator> luke-jr: I thought there was something more recent, with some Schnorr related things already dropped from the proposal.
< bitcoin-git> [bitcoin] fanquake closed pull request #15472: Create Bitcoin (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15472
< luke-jr> yeah, gmaxwell was talking about it the other day, but not sure the best/recent source for it
< luke-jr> I recall seeing a blog somewhere about it
< luke-jr> but blockstream's blog is killing my browser, so not sure if that's where
< provoostenator> Ok, but no BIP yet... or you'd know about it :-)
< luke-jr> no number assigned yet, but that means relatively little
< provoostenator> Re #15471 let's make sure the current commit is ACKable, but otherwise hold off until the last minute if anyone has a better PR?
< gribble> https://github.com/bitcoin/bitcoin/issues/15471 | rpc/gui: Remove Unknown block versions being mined warning by laanwj · Pull Request #15471 · bitcoin/bitcoin · GitHub
< luke-jr> provoostenator: it seems to completely fly in the face of supposed principles of merging; the protocol change has near zero community support
< provoostenator> luke-jr: that PR simply drops the warning entirely (option 2 in my list), I think you're confusing it with #13972 (option 3 in my list)
< gribble> https://github.com/bitcoin/bitcoin/issues/13972 | Remove 16 bits from versionbits signalling system by btcdrak · Pull Request #13972 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15473: bench: Benchmark MempoolToJSON (master...Mf1902-benchRpcMempool) https://github.com/bitcoin/bitcoin/pull/15473
< aj> provoostenator: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-December/016556.html ? but NOINPUT tagging per the more recent threads seems more likely than OP_MASK at this point
< bitcoin-git> [bitcoin] promag opened pull request #15474: rest/rpc: Make mempoolinfo atomic (master...2019-02-atomic-mempoolinfo) https://github.com/bitcoin/bitcoin/pull/15474
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/b4fc5257b7dc...8f470ecc534d
< bitcoin-git> bitcoin/master fab0d85 MarcoFalke: qa: Remove mocktime unless required
< bitcoin-git> bitcoin/master 1111aec MarcoFalke: qa: Always refresh stale cache to be out of ibd
< bitcoin-git> bitcoin/master fa25210 MarcoFalke: qa: Fix wallet_txn_doublespend issue
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15419: qa: Always refresh cache to be out of ibd (master...Mf1902-mocktime) https://github.com/bitcoin/bitcoin/pull/15419
< bitcoin-git> [bitcoin] geekastute opened pull request #15475: 0.17 (master...0.17) https://github.com/bitcoin/bitcoin/pull/15475
< bitcoin-git> [bitcoin] geekastute closed pull request #15475: 0.17 (master...0.17) https://github.com/bitcoin/bitcoin/pull/15475
< luke-jr> provoostenator: no, dropping the warning is what I meant
< provoostenator> luke-jr: good news, for now: I ran the numbers back to before SegWit and if you look *per bit* we can stil use the 50 out of 100 blocks threshold for warnings.
< provoostenator> Afaik the protocol doesn't support signalling by rotating bits, so that shouldn't be a violation.
< luke-jr> provoostenator: what do you mean?
< provoostenator> Alerts are currently triggered when 50 out of 100 recent blocks have any unexpected bit set, even if it's a different bit in each of those blocks.
< luke-jr> hmm, that's weird. fixing that does make sense
< provoostenator> If we change that to tracking each bit individually, then there wouuld have been no alerts expect for SegWit and BIP91.
< luke-jr> gotta run, bbiab
< sipa> we already track each bit individually
< provoostenator> sipa: the activation logic does, the alert logic doesn't
< sipa> yes we do
< sipa> (separate from the warning logic under discussio nnow)
< provoostenator> on master nUpgraded tracks whether we send an alert https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2262
< provoostenator> We check if each block has an unexpected value. Any unexpected value.
< sipa> yes, i know
< sipa> i'm saying there is also another warning mechanism which does work per bit
< provoostenator> Ah yes, the one that warns some new rule is active.
< provoostenator> But that's not the one causing all the false positive alerts afaik.
< sipa> correct
< provoostenator> The nUpgraded warning says "It's possible unknown rules are in effect", but that's only possible if a lower threshold or some other upgrade mechanism than BIP9 is introduced.
< provoostenator> Or if a future soft fork makes another bit permanent.
< sipa> ?
< provoostenator> sipa: see latest comment on PR: https://github.com/bitcoin/bitcoin/pull/15471#issuecomment-467137377
< sipa> yes, agree with that
< MarcoFalke> Is there any chance that there will be a softfork deployed not via BIP9?
< MarcoFalke> I doubt it and I think the changes in #15471 are pretty minimal to get into 0.18.0 as a bugfix
< gribble> https://github.com/bitcoin/bitcoin/issues/15471 | rpc/gui: Remove Unknown block versions being mined warning by laanwj · Pull Request #15471 · bitcoin/bitcoin · GitHub
< wumpus> I also have the feeling this whole thing is overblown
< wumpus> this warning is actively dangerous to users, and it would be good to disable it for 0.18, even if a better approach will be added later
< MarcoFalke> agree
< provoostenator> Yeah, the per bit counting is easier said than done.
< sipa> I don't think it's hard, but i agree it's probably too much for 0.18 at this point
< wumpus> I also wonder how much it matters, it's not that BIP9 is reliable anymore for those bits
< provoostenator> It's hard to get a good signal to noise ratio to detect potential soft forks that could be activated soon.
< adiabat> maybe if you see a bunch of non-standard txs? also gameable but at some cost to miners
< adiabat> though I guess that's after the fact, not for something that will be activated soon
< wumpus> in *practice* it's easy because we know what bits the miners have chosen to use
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15477: doc: Remove misleading hint in getrawtransaction (master...Mf1902-rpcRawDocFix) https://github.com/bitcoin/bitcoin/pull/15477
< bitcoin-git> [bitcoin] promag opened pull request #15478: wip: gui: Refactor open wallet activity (master...2019-02-refactor-open-wallet) https://github.com/bitcoin/bitcoin/pull/15478
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15479: test: Add .style.yapf (master...Mf1902-testYapf) https://github.com/bitcoin/bitcoin/pull/15479
< gmaxwell> wumpus: well also because they only want a couple bits, so if we say "use bits x,y,z" they'll probably use them.
< MarcoFalke> BIP320 could make sense to make it explicit, but that can be done for 0.19 or not at all
< dongcarl> For BIP32, is the identifier the Hash160 of the compressed or uncompressed serialization of the ECDSA public key?
< sipa> dongcarl: it's hash160 of the public key. from bitcoin's perspective, compressed and uncompressed public keys are distinct
< sipa> and bip32 only supports compressed keys, iirc
< sipa> oh, that's not explicitly spelled out it seems
< dongcarl> Oh boy
< sipa> in any case, if the key is compressed, use the compressed serialization - otherwise use the uncompressed one :)
< sipa> but xpub serializations always uses compressed... so integrating bip32 with uncompressed keys seems hard in any case
< dongcarl> What does Core do?
< sipa> bip32 derived keys are always compressed
< dongcarl> Okay, thanks.
< luke-jr> FWIW, for now I made a Twitter poll on BIP 320 since I don't know if we have a better way to assess community support: https://twitter.com/LukeDashjr/status/1100102745951006720
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #15481: Restrict timestamp when mining a diff-adjustment block to prev-600 (master...2019-02-600s-gbt) https://github.com/bitcoin/bitcoin/pull/15481
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #15482: Implement BIPXXX's new softfork rules (The Great Consensus Cleanup) (master...2019-02-great-consensus-cleanup) https://github.com/bitcoin/bitcoin/pull/15482