< promag> could #15652 be in high priority?
< gribble> https://github.com/bitcoin/bitcoin/issues/15652 | wallet: Update transactions with current mempool after load by promag · Pull Request #15652 · bitcoin/bitcoin · GitHub
< gmaxwell> +1 at a minimum we must ship with a loud warning in the release notes if that isn't fixed.
< gmaxwell> as incorrect balances can cause funds loss.
< sipa> it's marked as milestone 0.17.2; i assume that implies also 0.18
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #15681: [mempool] Allow one extra single-ancestor transaction per package (master...2019-03-lightning-policy) https://github.com/bitcoin/bitcoin/pull/15681
< cfields> wumpus: fyi, I'm deep in a quagmire of windows codesigning
< cfields> I'm not sure I'll make it in time for rc3
< cfields> We now have a valid cert, but it accidentaly went through a reseller, and I'm afraid that messed up the cert chain.
< cfields> Either that, or my win7 vm doesn't reflect the current reality of trusted root CA's.
< cfields> So I'm going to need at least another day to straighten this out :(
< cfields> If anyone has a working win10 install, it'd be helpful to test a signed helloworld.exe to see if the problem is that win7's cert store is just outdated.
< wumpus> cfields: uh oh
< cfields> tl;dr: gwillen and jonasschnelli helped to register for a new windows cert. It signs ok and gitian attaches it ok, but my win7 install doesn't like it.
< wumpus> and no, I don't have any windows (nor mac) anymore to test, but I'm sure someone here has?
< cfields> wumpus: if you'd like, I can PR the updated cert chain that _may_ work, and we can get feedback from rc3?
< wumpus> I think that'd make sense, then we can still do rc3 today
< cfields> the signer uses the .cert file in git, so it'll need to be updated either way.
< wumpus> I should at least tag it I guess :-)
< cfields> ok, will do. I think it's pretty unlikely that it'll work, but worth a shot.
< cfields> I can PR in just a min.
< wumpus> I'll then mention in the notification mail that the windows cert might have isues
< wumpus> and we need to get this sorted out for final
< kallewoof> My coworker has Win 7. Shoudl he try?
< kallewoof> Another coworker has Win 10 inside a virtual box, if that helps.
< gmaxwell> just don't sign for windows at all and see who reports it then we will have identified suckers^wtesters for future versions.
< achow101> cfields: I've got a win10
< cfields> gmaxwell: heh.
< cfields> kallewoof / achow101: a win10 test would be great. I believe the issue is that the trusted CA's were updated to cope with Comodo's recent renaming. But I'm really grasping. This is a black box :(
< kallewoof> cfields: where can I download the fiel-
< cfields> kallewoof: Since the tag is incoming, I'll just sign rc3 with the new cert. Could you test that? That avoids having random codesigned binaries hanging around.
< kallewoof> Oh, okay. Sure thing
< achow101> ok
< cfields> achow101: ^^ same to you.
< bitcoin-git> [bitcoin] theuni opened pull request #15682: release: Update the Windows Codesigning certificate (master...new-win-cert) https://github.com/bitcoin/bitcoin/pull/15682
< cfields> wumpus: sorry for leaving that inconclusive for now. I tried a million things tonight. Will have a look tomorrow with a clear head.
< cfields> kallewoof / achow101: thanks for volunteering to test :)
< wumpus> cfields: thanks for trying ! let's blame it on Microsoft for making people navigate such a maze for this
< cfields> I suspect, even if win7 doesn't have the new trusted CA, that there's a way to make a path with intermediaries. But I didn't have any luck.
< wumpus> this is at most a bypassable warning isn't it?
< cfields> Yes
< wumpus> (not that we should really be encouraging people to ignore warnings about unsigned code, but it's fine for a RC)
< cfields> But I believe that in its current state it may be no better than nothing.
< achow101> i'm pretty sure it's a scary looking warning in windows 10 though
< wumpus> yes, agreew with that, just need to know what to write inthe mail 'it probably doesn't work on w7' or 'it gives wa warning during install' so it's the latter
< cfields> Worst case I think we can buy a new cert. I believe the problem is that it went through a reseller, though I'm not 100%.
< cfields> The Comodo rename is really messing with my ability to understand wtf is going on :)
< cfields> Comodo -> Sectigo, apparently
< wumpus> did they have a breach or something :-)
< cfields> Heh, I thought Symantec's breach was bad. I assume you're right. Hard to keep up these days, I guess :)
< gwillen> I'm happy to pay to try again (and ask comodo for a refund or something) if this fails and there's a better party to buy it from that doesn't have the cert chain issue
< gwillen> (I doubt I'll get a refund but I can yell at them and it will make me feel better)
< gmaxwell> is this a case where you just have to staple the CA chain to the cert?
< cfields> gwillen: Not pinning it on you at all, sorry if it sounded that way. It's all very confusing.
< gwillen> no, not at all and no worried
< cfields> gmaxwell: Yes, and in the correct order.
< gwillen> worries*
< cfields> gmaxwell: it has to be chained together in the proper order, and it has to end in a trusted CA. And it's not clear who those trusted CA's are.
< wumpus> ahh like with TLS cert chains, that's also painful sometimes
< cfields> ^^ The issue
< cfields> wumpus: heh, yep, same as the unhelpful apache error when you get the cert order backwards.
< achow101> cfields: the cert you have is signed by the cert at http://crt.sectigo.com/SectigoRSACodeSigningCA.crt which is signed by the cert at http://crt.sectigo.com/SectigoRSACodeSigningCA.crt which in turn is signed by "http://crt.sectigo.com/SectigoRSACodeSigningCA.crt" which is a trusted root that I see in my windows 10
< achow101> AddTrust External CA Root is the final root (bad copy paste)
< cfields> achow101: ah, that seems to be missing in win7!
< cfields> So maybe it'll work for win10. Ugh, that almost seems worse.
< achow101> http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt is the second intermediate
< cfields> achow101: the Sectigo CA i don't see in the certificate snap-in via mmc in win7.
< achow101> I don't see it either. so I think we will need to provide the chain for it
< achow101> I got the sectigo CA url from openssl decoding of the cert
< cfields> "http://crt.sectigo.com/SectigoRSACodeSigningCA.crt" which is a trusted root
< achow101> That was supposed to be AddTrust External CA Root. bad copy paste
< cfields> Oh, sure, but does Windows trust it?
< achow101> windows 10 trusts it
< cfields> achow101: If rc3 isn't tagged by tomorrow, I'll re-sign rc2 with this cert and we can mess around with it.
< cfields> Thanks for poking at it :)
< achow101> np
< achow101> cfields: also, that trusted root expires next May, so maybe it isn't the greatest idea to go with them? especially if we need to provide our own CA chain (dunno if we do)
< achow101> cfields: have you tried updating your win 7 vm? afaict windows update will update the trusted root certificates so you should have the trusted root there
< cfields> achow101: it's a 1 year cert.
< cfields> achow101: deliberately no. Very possible that an update may install new certs, but I'm trying to stay as worst-case-scenario for my VM as possible.
< cfields> achow101: ah, I misunderstood about the expiration. Interesting. Ours expires first, though :)
< gwillen> I get testing the worst case scenario but it seems like par for the course that a non-updated install would have certificate problems
< gwillen> especially given the rerooting of comodo
< achow101> ah, I hadn't checked the expiry of our cert
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/7eab2db849d9...f14a0aa99b84
< bitcoin-git> bitcoin/0.18 09a05e8 Wladimir J. van der Laan: qt: Translations update pre-rc3
< bitcoin-git> bitcoin/0.18 f14a0aa Wladimir J. van der Laan: build: Bump to rc3
< wumpus> running bitcoin on an unupdated w7 ouch :)
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3702e1c17b6c...edb8df4fea13
< bitcoin-git> bitcoin/master 43ae1e9 Cory Fields: release: Update the Windows Codesigning certificate
< bitcoin-git> bitcoin/master edb8df4 Wladimir J. van der Laan: Merge #15682: release: Update the Windows Codesigning certificate
< bitcoin-git> [bitcoin] laanwj merged pull request #15682: release: Update the Windows Codesigning certificate (master...new-win-cert) https://github.com/bitcoin/bitcoin/pull/15682
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/f14a0aa99b84...dcd96b84cf82
< bitcoin-git> bitcoin/0.18 dcd96b8 Cory Fields: release: Update the Windows Codesigning certificate
< wumpus> ok, ready to tag rc3 I think?
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/dcd96b84cf82...7bcf90cb01aa
< bitcoin-git> bitcoin/0.18 7bcf90c Wladimir J. van der Laan: doc: Update manpages for changes since rc2
< bitcoin-git> [bitcoin] murrayn closed pull request #15500: Support for a bitcoind 'ready' file to indicate startup is complete. (master...ready_file) https://github.com/bitcoin/bitcoin/pull/15500
< bitcoin-git> [bitcoin] Bushstar opened pull request #15683: Comment for seemingly duplicate LIBBITCOIN_SERVER (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15683
< bitcoin-git> [bitcoin] luke-jr opened pull request #15684: doc/dependencies: Fix typo libsrvg->librsvg (master...typo_libsrvg) https://github.com/bitcoin/bitcoin/pull/15684
< luke-jr> wumpus: ^
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15685: doc: rpc-mining: Clarify error messages (master...1903-docMining) https://github.com/bitcoin/bitcoin/pull/15685
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/edb8df4fea13...32e0428e371e
< bitcoin-git> bitcoin/master 7d01b5c Luke Dashjr: doc/dependencies: Fix typo libsrvg->librsvg
< bitcoin-git> bitcoin/master 32e0428 MarcoFalke: Merge #15684: doc/dependencies: Fix typo libsrvg->librsvg
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15684: doc/dependencies: Fix typo libsrvg->librsvg (master...typo_libsrvg) https://github.com/bitcoin/bitcoin/pull/15684
< luke-jr> BTW, that commit should be a clean merge to 0.18
< luke-jr> MarcoFalke:
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/32e0428e371e...9e7dc682e0f6
< bitcoin-git> bitcoin/master faad33f MarcoFalke: rpc: Clarify decodescript RPCResult doc
< bitcoin-git> bitcoin/master fa3caa1 MarcoFalke: rpc: decodescript use IsValidNumArgs over hardcoded check
< bitcoin-git> bitcoin/master fa926ec MarcoFalke: rpc: Mention all output types in decodescript doc
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15616: rpc: Clarify decodescript RPCResult doc (master...1903-rpcDocDecodeS) https://github.com/bitcoin/bitcoin/pull/15616
< Kevslinger0> Bored? Call the official freenode IRC partyline at +4521137886
< gernot26> Bored? Call the official freenode IRC partyline at +4521137886
< hugo127> Bored? Call the official freenode IRC partyline at +4521137886
< dcxk24> Bored? Call the official freenode IRC partyline at +4521137886
<@luke-jr> (probably should remember to undo that before the meeting)
< internetworm> spams here?
<@luke-jr> internetworm: yeah, I silenced it for now
< MarcoFalke> Shall we pull in the current release notes for rc3?
< MarcoFalke> The release notes in the branch are neither empty nor up-to-date iwth the branch
< MarcoFalke> Some people link to those in the branch
< bitcoin-git> [bitcoin] dongcarl closed pull request #15671: net: Don't return unreachable local addresses for peer (master...2019-03-fix-getlocal) https://github.com/bitcoin/bitcoin/pull/15671
< internetworm> luke-jr: as expected thanks
< bitcoin-git> [bitcoin] jnewbery opened pull request #15686: [tests] make pruning test faster (master...2019_03_faster_pruning_test) https://github.com/bitcoin/bitcoin/pull/15686
< bitcoin-git> [bitcoin] instagibbs closed pull request #15547: Switch wallet default to reject too-long transaction chains for mempool (master...walletreject_true) https://github.com/bitcoin/bitcoin/pull/15547
< bitcoin-git> [bitcoin] jonatack opened pull request #15687: test: tool wallet test coverage for unexpected writes to wallet (master...tool-wallet-tests-for-unexpected-writes-to-wallet-file) https://github.com/bitcoin/bitcoin/pull/15687
< dongcarl> Hi all, struggling with the specification of IPv4-mapped IPv6 addresses. According to section of RFC 4291 and section 4.2 of RFC 4038 the prefix is ::ffff:/96, but in section 2.2 of RFC 5156 it says that it is ::ffff:0:0/96. And it would seem our code says it is ::ffff:0/96 and says it'ss RFC6145?
< sipa> dongcarl: are you perhaps confused by the ipv6 notation? the number of bits between two colons is 16
< sipa> so it should be ::ffff:0:0/96
< sipa> anything that doesn't end in two 0s at the end makes no sense
< sipa> for a /96
< gwillen> dongcarl: I think the two RFC notations you give are meant to be equivalent
< gwillen> it is typical to write a v4-in-v6 address as ::ffff:
< gwillen> it's not crazy to express the prefix as either ::ffff:/96 or ::ffff:0:0/96 depending on how you think about it
< gwillen> the former is not really correct but I can see why you'd notate it like that
< dongcarl> Ah I'm wrong
< dongcarl> It seems to want to enforce an extra :0: at the end
< sipa> dongcarl: i think rfc6145 may be for something else
< sipa> ipv4-mapped addresses are tested for by IsIPv4
< dongcarl> sipa: Right right.
< sipa> ipv4 mapped addresses vs ipv4 translated addresses
< dongcarl> ah, so there's ipv4 mapped addresses, ipv4 translated addresses, 6to4, and IPv4-embedded IPv6 addresses......
< jonasschnelli> sipa: re ChaCha20. Do you mean duplicating the whole chacha function and do the XOR part in the duplicated function ... or ...
< sipa> jonasschnelli: yes
< jonasschnelli> create a new function that uses the old keystream output and XORing in the new one?
< jonasschnelli> okay.
< wumpus> MarcoFalke: I think we should only pull in release notes from the wiki before final
< wumpus> anything else makes the situation more comple
< wumpus> if people link the release notes on the branch, that's simply wrong, I take care to link the right ones in all announcements
< sipa> i think for the period during which the notes are being edited on the wiki, the version on the branch should be wiped and replaced with a link to the wiki
< wumpus> sounds good, please add that to the release process so we can do that for next release
< wumpus> I was also about to propose that, it's IMO too late to bother with that now
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Mar 28 19:01:36 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jnewbery> hello!
< midnightmagic> hello!
< moneyball> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
< cfields> hi
< jonasschnelli> hi
< sipa> wumpus: agree
< achow101> hi\
< wumpus> we should probably tag rc
< wumpus> rc3
< moneyball> we have 1 proposed topic! topic proposed by gmaxwell: Bech32 support shipped first in Bitcoin Core in Feb 2018, more than a year ago. We should consider making an announcement that Bitcoin Core intends to change the default addresstype from p2sh-segwit to bech32 in 0.19 or 0.20.
< wumpus> moneyball: thanks!
< instagibbs> oi
< wumpus> any other last-minute topic proposals?
< phantomcircuit> hi
< wumpus> #topic high priority for review
< MarcoFalke> Fine with rc3 to test the win-sig
< MarcoFalke> Thogh, there needs to be an rc4 for the wallet-mempool bug
< wumpus> six things on there right now, anything to add/remove?
< wumpus> MarcoFalke: is there a PR for that?
< MarcoFalke> yeah the one from promag
< MarcoFalke> It should be in high-priority already ...
< wumpus> ehm, why isn't it labaled 0.18.0 anymore
< harding> Somebody said earlier that it was labeled 0.17.2
< wumpus> that's not good
< MarcoFalke> #15652
< gribble> https://github.com/bitcoin/bitcoin/issues/15652 | wallet: Update transactions with current mempool after load by promag · Pull Request #15652 · bitcoin/bitcoin · GitHub
< MarcoFalke> The bug is labeled 0.18.0
< MarcoFalke> But it needs to be fixed in 17 as well
< wumpus> please keep things labeled 0.18.0 for the release now, otherwise it's confusing
< MarcoFalke> Ok
< wumpus> I don't think 17.2 is planned any time soon
< wumpus> but fine let's hold up the RC for that
< MarcoFalke> wumpus: It will take another day or so to get reviewed
< MarcoFalke> Maybe until monday
< wumpus> that's ok
< MarcoFalke> The windows sigs need testing, though
< wumpus> if it's urgent enough to hold upthe relesaer, it should hold up the release
< cfields> I could create and sign a helloworld.exe for testing if everyone is ok with that.
< wumpus> cfields: sounds good to me
< achow101> to test the windows sig, just resign rc2?
< wumpus> I think doing a distributed rc build is overkill just to test a signature
< wumpus> at least *if* the rc is a dead end otherwise
< MarcoFalke> achow101: You mean without a gitian build?
< cfields> achow101: I'd rather not have different versions of an rc floating around.
< wumpus> if it would be a possible -final apart rom the signature test it'd have made sense
< MarcoFalke> gitian build with sig wouldn't work for rc2, if I understand correctly
< cfields> MarcoFalke: yeah, it'd have to be stitched together manually.
< wumpus> I had forgotten about #15652 because it was moved off the milestone
< gribble> https://github.com/bitcoin/bitcoin/issues/15652 | wallet: Update transactions with current mempool after load by promag · Pull Request #15652 · bitcoin/bitcoin · GitHub
< achow101> oh right, gitian build wouldn't work
< cfields> helloworld.exe is trivial. I'll just do that.
< wumpus> thank you
< MarcoFalke> ok, sounds good to me
< achow101> ack
< MarcoFalke> So we have two pulls to merge for rc3
< MarcoFalke> And one issue to discuss: #15665
< gribble> https://github.com/bitcoin/bitcoin/issues/15665 | 0.18.0 rc2 CPU spike in thread bitcoin-opencon · Issue #15665 · bitcoin/bitcoin · GitHub
< MarcoFalke> Some while(true) loop again?
< sipa> that sounds related to some of the changes we made
< cfields> the peer selection was just reworked a bunch, no?
< wumpus> two pulls?
< sipa> sigh
< sipa> i'll have a look at that
< wumpus> #topic CPU spike in thread
< MarcoFalke> > htop is telling me bitcoin-opencon is responsible. Peers are neither added or dropped coinciding with the CPU spike
< wumpus> sorry, haven't been paying much attention, my personal life is hell right no
< sipa> don't think there's much to discuss; just a report of a regression that sounds like it may be caused by changes in 0.18
< cfields> sipa: out of curiosity, why not push the selection algorithm into addrman? That'd make it much easier to test, no?
< MarcoFalke> wumpus: Sorry to hear that
< sdaftuar> sipa: are you thinking of the addrman tried collision bugfix PR?
< sipa> sdaftuar: possibly
< cfields> wumpus: Please let us know if there's anything we can do to help.
< sdaftuar> i can take a look as well
< wumpus> cfields: thanks!
< wumpus> if it's a regression for 0.18 then yes, it makes sense to try to fix it before the release of 0.18.0
< wumpus> if not, it's still good to fix it but no need to block rcs
< wumpus> #topic bech32 as default address type in 0.19 or 0.20 (gmaxwell)
< gmaxwell> Hi
< gmaxwell> There is now an issue that encapsulates a lot of the discussion.
< achow101> what about making the address type part of the wallet and not a startup option?
< moneyball> #15560
< gribble> https://github.com/bitcoin/bitcoin/issues/15560 | When to make bech32 the default -addresstype? · Issue #15560 · bitcoin/bitcoin · GitHub
< wumpus> which issue?
< wumpus> okay
< moneyball> Optech is doing a number of things to help here, as outlined in that PR
< gmaxwell> achow101: we should be really cautious about incorrectly giving the impression that you have to decide wallet wide, (like electrum does)...
< moneyball> I agree with the intention of the PR, and if we collect enough data before v0.19 is cut, we could potentially demonstrate that a sufficient portion of the ecosystem supports bech32 sends that it would be pretty uncontroversial to do.
< gmaxwell> In any case, I think we obviously want to make bc1x addresses the default at some point.
< gmaxwell> I think it would be helpful to the industry to announce in advance when we're doing to do that.
< gmaxwell> in related news, gemini is now defaulting to handing now bc1x addresses as new addresses.
< moneyball> and BitGo announced yesterday too
< moneyball> We might have data in say, 2-3 months, which would help the Core project to determine whether to announce it will be default in v0.19 or v0.20. Are folks ok waiting for that?
< gmaxwell> which I believe is the first (or at least one of the first) major services doing that... and makes me feel much more comfortable that 0.19 would be a good target (instead of 0.20)
< cfields> How many known stragglers are there?
< achow101> gmaxwell: why would it not be wallet wide? (maybe I'm misunderstanding you)
< gmaxwell> Data is good but also we wouldn't want to be circular. The languishing with no schedule to change the default has been contributing to lack of support.
< sipa> well we mostly care about ability to send to bech32
< gmaxwell> (I'm sure thats not completely current)
< gmaxwell> Things like ledger's wallet cannot.
< moneyball> data also here https://whensegwit.com
< gmaxwell> I'm concerned that we're erroring a little too strongly towards total compatiblity, which is causing industry participants to make an economically rational decision to ignore updating their bitcoin support in favor of supporting more altcoins.
< gmaxwell> (I can privately discuss some parties that have told me this outright)
< gmaxwell> sipa: yes, thats the only thing to actually care about.
< sipa> we wouldn't move to bech32-only in any case, so the question isn't nearly as strong as for electrum (which afaik needs either fully bech32 or not at all)
< gmaxwell> achow101: in electrum when you make a segwit wallet it is essentially bc1x only.
< gmaxwell> achow101: we wouldn't want to create an impression that we work that way too.
< gmaxwell> The difference in making a default is that users will splat into invalid address messages sometimes and need to go hit a button to get a compatiblity address.
< wumpus> right, the only risk is that we'd switch to bech32 addresses by default while there's still wallets in common use that can't send to them, that would be kind of bad though as the UI allows for generating different address types, also not uncircumventable
< wumpus> but it needs to be documented well at least...
< gmaxwell> And I think we've reached a point in deployment now where most things that don't support it are going to continue to not support it, (and instead spend efforts adding more altcoins) unless there is a bit more of a push. But more probably is just making their shortcomings more visible by changing defaults.
< wumpus> in any case, planning this for 0.20 (potentially moved backward to 0.19) sounds fine to me
< gmaxwell> Regardless of that: at some point we want to change, for sure, and we should establish in advance when we're going to do it.
< wumpus> yes
< sipa> agreed
< sipa> the left column which is mostly green on https://en.bitcoin.it/wiki/Bech32_adoption is pretty encouraging
< gmaxwell> wumpus: sounds good to me. So right now we'll do it in .20 and potentially .19.
< wumpus> gmaxwell: exactly
< instagibbs> any way we could signal "deprecation" in the software for .19?
< instagibbs> i can't think of any, just wondering aloud
< wumpus> instagibbs: that's a good idea
< achow101> with descriptor wallets I'm not sure how we would support choosing different address types
< gmaxwell> instagibbs: really the default change is the deprecation.
< moneyball> gmaxwell: i do hope optech's 24 weeks of bech32 in our newsletter as well as our personal outreach to many services will have an impact on this in 2019. no guarantees but i think we might move the needle a bit.
< instagibbs> gmaxwell, yeah true :)
< achow101> since a descriptor is what we use as "the keypool" and descriptor specify the type
< wumpus> eh yes what gmaxwell says
< wumpus> deprecation is for *removing* features
< wumpus> this is a default change
< wumpus> it just needs to be announced well
< sipa> achow101: you'd have a descriptor record per address type
< instagibbs> it's an imperfect analogy, announce during 0.18 release, switch for 0.19 fine by me
< gmaxwell> I was about to say we don't have any intent to remove getting compat addresses, but achow points out that they're actually hard to universally support in a descriptor only wallet... so thats another reason to make the switch sooner rather than later too.
< gmaxwell> instagibbs: we can announce now ish that we'll default to it in .20 and potentially also .19.
< moneyball> announcing now will allow Optech to amplify that announcement too
< achow101> sipa: that's a bit incompatible with things like sethdseed. and I don't think we would want to have 3 records that refer to the same seed
< sipa> achow101: "sethdseed" has no meaning in a descriptor wallet
< sipa> achow101: that's a discussion for another topic i think
< achow101> ok
< sipa> but i don't think there is much of a problem
< wumpus> please, don't announce dropping support for old-style addresses (at whatever point), I expect this to cause major upheaval and it's not relevant to this
< gmaxwell> (and to make it clear, I don't fault parties that have been allocating their time elsewhere, they need to make whatever is the best business decisions for them... but by the same token, we shouldn't wait forever to hit 0% disruption)
< moneyball> wumpus: to be clear, that is not Optech's plan! our best practices guidance is to continue supporting legacy addresses
< gmaxwell> Yeah, to be clear we have no plans to drop support for compatiblity addresses. I was only going to say that we even had no reason to ever consider that, but achow did give a reason why we might someday want to, at least in some contexts.
< wumpus> moneyball: good to know
< moneyball> this is a summary of our guidance https://github.com/bitcoin/bitcoin/issues/15560#issuecomment-471690972
< gmaxwell> (and by drop support, I mean not generating in some new wallet types, no one has ever suggested a reason to drop being able to send to.)
< wumpus> right, that would be like what electrum has already done
< gmaxwell> right.
< wumpus> any other prposed topics?
< kanzure> minor mailing list updates. warren is the sole person handling that at this point. also i noticed that like 1200 users were mass unsubscribed this morning, dunno why.
< gmaxwell> aside, I'm not seeing this cpu spike.
< gwillen> kanzure: any obvious pattern in the mass unsubscription? (All gmail users, all non-gmail users, all people with names starting with A?)
< wumpus> gmaxwell: haven't noticed it either, maybe it's something that happens if there's no results like a previous time
< gmaxwell> wumpus: or if your addrman is mostly empty.
< wumpus> right
< kanzure> gwillen: definitely a lot of yahoo
< wumpus> #topic mailing list issues
< kanzure> i've give my update
< kanzure> i'd like warren to start cc'ing me on communication with linuxfoundation
< wumpus> thanks!
< gmaxwell> I unsubbed recently of my own volition, not an example of some kind of automated screwup.
< kanzure> or if not me then someone else
< gmaxwell> single threading things through one person is not a good idea for sure.
< kanzure> s/give/given
< gmaxwell> I've always made a point of CCing other people (usually wumpus and sipa) anytime I communicated something 'for bitcoin core project', even dumb stuff like lame whining at people for idiotic tweets. ... just so if I drop off the face of the earth someone has context.
< gmaxwell> (or BCCing)
< wumpus> yes, that makes sense
< gmaxwell> +1 on mailing list stuff being CC/BCC to kanzure, perhaps wumpus too if just to collect info.
< bitcoin-git> [bitcoin] dongcarl opened pull request #15689: netaddress: Update CNetAddr for ORCHIDv2 (master...2019-03-account-for-orchidv2) https://github.com/bitcoin/bitcoin/pull/15689
< wumpus> good, any other topics?
< wumpus> thanks everyone
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Mar 28 19:45:51 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< cfields> hello-signed.exe: https://ufile.io/2vnl6
< cfields> 52665dec47f3c004b63aa6d4e8cf4d9e5139242108a81112eb88854740fae43b hello-signed.exe
< wumpus> ^^ please help testing if you're using windows 7 to 10
< cfields> Sorry for the shitty uploader host, I don't have anything handy.
< * jonasschnelli> starting up windows...
< wumpus> I'll upload it to mine
< cfields> wumpus: thanks, I was hoping that would happen :)
< jonasschnelli> cfields: the hello-world app runs perfect on my Win7
< jonasschnelli> No warning or such
< jonasschnelli> Runs also smooth on Win8.1 and Win10.
< jonasschnelli> "Digital Signature" shows "Bitcoin Core Code Signing Association"... Digest is sha1
< jonasschnelli> Looks good at my end
< cfields> jonasschnelli: right-click .exe -> properties -> digital signatures -> details -> (30sec freeze) -> "root cert not trusted"
< wumpus> jonasschnelli: thanks for testing!
< cfields> jonasschnelli: bingo!
< cfields> Thanks!
< jonasschnelli> We should have used a more formal global email :)
< cfields> It didn't show in the last cert, I didn't think it would this time either :\
< jonasschnelli> (we can switch the email when the cert expires in 1yr)
< jonasschnelli> no worries...
< cfields> jonasschnelli: thanks again for testing. Looks like the only problem is my un-updated Win7 install.
< jonasschnelli> Should I do the right click thing on my Win7?
< cfields> Oh, yes please. I thought that was.
< jonasschnelli> Its a system I haven't run at least for 8month.
< * jonasschnelli> running Win7
< jonasschnelli> Windows 7 tells me its "build 7601"... if that helps
< jonasschnelli> clicking on details gives me the freeze
< jonasschnelli> But then it shows it...
< jonasschnelli> Yeah.. seams to be a old, unknown CA
< jonasschnelli> I think its fine for an rc
< achow101> cfields: looks fine on win10 too
< jonasschnelli> Lets see if there are complains...
< jonasschnelli> Maybe fixable by upgrading win7?
< cfields> https://i.imgur.com/lRLhhDb.png is what I was seeing.
< cfields> So yes, looks all good to me!
< cfields> achow101: thanks for testing.
< cfields> also, thanks for running my wallet-stealer :p
< jonasschnelli> cfields: hehe... good lock with 1.34 testnet coins. :)
< jonasschnelli> *luck
< MarcoFalke> sig also worked for me on a win7 vm
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15691: 0.18: rc3 backports (0.18...1904-18B) https://github.com/bitcoin/bitcoin/pull/15691
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15692: doc: Mention wiki release notes draft in release-process (master...1904-docRel) https://github.com/bitcoin/bitcoin/pull/15692
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15693: travis: Switch to ubuntu keyserver to avoid timeouts (master...1903-travisKeyTimeout) https://github.com/bitcoin/bitcoin/pull/15693
< midnightmagic> if a setban overlaps, I wonder if the bantime in the overlap should be updated..