< 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
< 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/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] 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 2.5.5.2 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:123.45.67.89
< 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
< 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.
< 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.
< 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.
< 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.
< 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.
< 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)