< bitcoin-git>
[bitcoin] Sjors opened pull request #21467: Move external signer out of wallet module (master...2021/03/signer_no_wallet) https://github.com/bitcoin/bitcoin/pull/21467
< michaelfolkson>
#proposedmeetingtopic Taproot activation PRs and attempting to finalize startheight
< Arvidt>
Any preference for having base-10 (kB/MB/GB) or base-2 (KiB/MiB/GiB) prefix for GUI network peer tab data transferred/throughput value? See https://github.com/bitcoin-core/gui/pull/248 Would be thankful to get some feedback.
< luke-jr>
Arvidt: base 10 sucks ;)
< hebasto>
luke-jr: what reasons for?
< luke-jr>
hebasto: 10 is a multiple of 5 and 2
< luke-jr>
but more importantly, networks tend to use base-1024 measurements
< sipa>
my gigabit ethernet does 1000000000 bits/s
< luke-jr>
sipa: it does? :o
< sipa>
yes
< luke-jr>
hmm
< sipa>
all network stuff is 1000-based, as far as i know'
< sipa>
only disk sizes use 1024-based units conventionally
< sipa>
or on-disk sizes
< luke-jr>
RAM typically does even now
< sipa>
that's true, RAM is also typically 1024-based
< luke-jr>
well, decimal still sucks, but we should match what other stuff does
< luke-jr>
eg, torrent clients, browsers, etc
< jeremyrubin>
can we use nats?
< jeremyrubin>
I think the thing with the MiB MB is it's always "close enough" if you mix em up
< sipa>
it's 7.3% off!
< jeremyrubin>
I think that's why people get away with confusing labeling
< sipa>
once you get to peta/pebi it's a 12.6% difference
< jeremyrubin>
you should file a CFPB complaint :)
< sipa>
child for parent bays?
< jeremyrubin>
I guess CFPB only does financial fraud
< jeremyrubin>
anyways off topic
< Arvidt>
OK I just left the 1000-based prefixes then and just corrected the divisor from 1024 to 1000. Thanks for Your feedback
< * luke-jr>
proposes using 1024-based units when it is a good thing, and 1000-based units when it is bad or a cost :P
< Arvidt>
The good thing with binary prefix is that one can be pretty sure the programmers are aware of the complex and (hopefully) knew what they have programmed
< michaelfolkson>
Now there is obviously the added complication of needing to finalize a startheight
< wumpus>
any specific reason to have competing PRs?
< achow101>
21377 uses the MTP start and timeouts, 21392 uses height
< michaelfolkson>
aj PR changes less code, uses existing BIP 9 code
< wumpus>
right, thanks
< michaelfolkson>
There is an added complication that some people seem not like to BIP 8 and so trying to get around using it (I think but I could be wrong)
< michaelfolkson>
That is a sense I get (which some people have told me is wrong)
< michaelfolkson>
Speedy Trial doesn't have a relaxed proposed timetable
< achow101>
people seem to not like some aspects of BIP 8, but the change to heights is generally seen to be a good change
< luke-jr>
ST would be very controversial with MTP, or without a clear documentation/disclaimer
< michaelfolkson>
Those are proposed dates
< achow101>
no one is trying to "get around using BIP 8" because they don't like it. 21377 exists because it is a minimal change, not because MTP is better or that heights are bad.
< michaelfolkson>
So we don't have much time to work with if we are going to keep to that proposed timetable
< michaelfolkson>
achow101: I've got the sense that it is more than that (but as I said I've been corrected)
< jeremyrubin>
I think that ST with MTP is only really controversial with activate MTP, not activate height
< achow101>
michaelfolkson: the objections I've seen have been to the lockinontimeout parameter. please don't generalize that to disliking the entirety of bip 8
< jeremyrubin>
It's really easy to get around the signaling periods issue by targetting a mid-signal period activate height and time
< michaelfolkson>
achow101: Right but lockinontimeout is in BIP 8
< jeremyrubin>
given the short timetable, mining drift will likely be minimal
< michaelfolkson>
achow101: So that seems to be the only reason for disliking BIP 8 (at least in my view)
< luke-jr>
achow101's proposal seems the least controversial at the moment
< jeremyrubin>
s/activate height and time/start,end height and time/
< michaelfolkson>
A startheight of May 1st was proposed which doesn't leave much time
< luke-jr>
michaelfolkson: it's for signalling, not activation
< achow101>
michaelfolkson: it really does not matter and trying to focus on that bip number distinction is bikeshedding, a waste of time, and no one (except you) cares
< luke-jr>
a release May 1 is okay with that startheight
< michaelfolkson>
achow101: I don't care about it personally :) I just don't want it delaying reviewing of PR(s)
< jeremyrubin>
To restate more clearly: The main reason to prefer Achow's w/ start height and time is to fix the issue of a known number of singalling periods by using heights and not times. The main reason to prefer AJ's is smaller diff. Either will work. Because of the 3 month period proposed, we can likely set times so that we have a known number of periods with high confidence.
< jeremyrubin>
I don't have a preference either way
< achow101>
jeremyrubin: note that 21377 has changed to using an activation height. It only uses MTP for start and timeout time
< jeremyrubin>
Yep!
< michaelfolkson>
luke-jr: Assuming. a release of May 1 when does the PR need to be merged by?
< michaelfolkson>
I'm kind of in the dark on whether the proposed startheight of May 1st is doable
< luke-jr>
michaelfolkson: typically there's at least 1 week of a RC
< luke-jr>
add a few days to backport I guess
< achow101>
Note that the windows signing certificate expires next week. I'm in the process of renewing it currently, but it's a process that takes some time
< jeremyrubin>
achow101: my point about known periods is just that if you pick start/end heights that are mid-signaling period there's unlikely to be enough drift to cause an off-by-one in intended # of singaling. I agree that height is superior in general.
< michaelfolkson>
And what needs to be done in advance of May 1st. Lots of communication to mining pools, users etc?
< achow101>
so any future release will need to wait for that cert to be renewed
< jeremyrubin>
and activationheight is agreed on across both proposals
< luke-jr>
michaelfolkson: ST is okay because it's okay if ST fails
< wumpus>
achow101: good to know
< michaelfolkson>
luke-jr: Right but we want to give it as good chance as we can to succeed
< michaelfolkson>
Releasing quietly and waiting until it fails shouldn't be the plan
< wumpus>
achow101: i guess we have no releases planned immediately so given it cawn be resolved in a month or so it's no big deal
< jeremyrubin>
I don't think we should wait for a windows signing cert personally -- I don't like the notion of Microsoft being in the way of bitcoin development
< achow101>
jeremyrubin: I expect I'll have it resolved by the time we're ready to make a release anyways
< wumpus>
jeremyrubin: that doesn't seem to be the case at all
< meshcollider>
Is this going to be 21.1 release, not 22?
< luke-jr>
jeremyrubin: we could always publish the unsigned binaries, but it'd be better to not have an odd release
< wumpus>
not codesigning it will probably hinder adoption i think that would be even worse and besides there is no real hurry
< michaelfolkson>
Normally competing PRs is good, gives a chance for people to pursue different approaches. Given the short timetable I'm not sure if this is as important for this. But obviously not going to ask people to only review one PR
< jeremyrubin>
sure, i just don't think we should ever be in a position that we delay anything due to a third party vendor -- if signing binaries with MSFT approval opens us up to coercion, we should probably plan to deprecate that sort of signing. Let's not discuss further in this meeting though
< wumpus>
please
< wumpus>
there is no talk of coercion at all here, if there was i'd agree with you ,for now we have enough real issues let's not make up any
< achow101>
in order to make the May 1st start time, I think we should get 0.21.1 by April 24th at the latest
< michaelfolkson>
But it sounds like May 1st is doable which is great
< achow101>
For 2 RCs, we need to get everything in by April 10th
< jeremyrubin>
michaelfolkson: I don't see any concrete dates there?
< jeremyrubin>
so I don't know what people are ACKing w.r.t. a timeline
< michaelfolkson>
If anyone has concerns though about this timetable please raise them. Personally I think a delay of a few weeks would be ok
< achow101>
Since this requires backport, I think having the PRs merged to master by April 3rd is the latest
< achow101>
then a week for backport
< achow101>
then RC1 and so on
< michaelfolkson>
jeremyrubin: They are ACKing the proposal
< wumpus>
so the real bottleneck is trusting the code enough to merge it (including the backport), it is better to not split reviewers over multiple PRs if possible
< achow101>
indeed
< wumpus>
maybe two competing approaches is fine but let's not open more :-)
< michaelfolkson>
wumpus: Personally I would agree. I also don't want it to be rushed. If the timetable needs to be pushed back I think that is ok
< michaelfolkson>
But if we can avoid that it would be great
< jeremyrubin>
michaelfolkson: I just don't see a specific startheight/startime in the proposal
< wumpus>
aiming for april 3 sgtm
< luke-jr>
I opened a PR with just the height/user-facing stuff, but it already conflicts between 0.21 and master, so I'm not sure it gains anything over just reviewing+merging achow's as-is
< meshcollider>
FWIW I don't think the size of the diff of achow101's version is really an issue ^
< amiti>
my two cents: I don't think either PR is close to being RFM, both need significantly more review. looks like 21392 is currently failing CI. If the goal is to quickly merge with safety, I think 21377 makes more sense (as I stated on the PR)
< wumpus>
having to rebase the PR all the time will not make it getting through review easier, after all
< amiti>
the diff is much smaller and mostly tests
< wumpus>
amiti: +1
< luke-jr>
amiti: consensus comes first
< achow101>
the ci failure on 21392 should be fixed now
< amiti>
achow101: cool, and I'm not opposed to 21392, I'm just saying its a bigger patch requires more review.
< michaelfolkson>
I know I sound like a broken record but BIP 8 has been updated and BIP 9 is "dead" according to one of the authors. So from a BIP perspective BIP 8 would be easier. I get amiti's argument that code diff wise AJ's smaller
< jeremyrubin>
I don't think "BIP9 is dead" is useful here
< jeremyrubin>
the code works fine
< michaelfolkson>
Code is most important
< amiti>
michaelfolkson: I don't think it makes sense to fixate on the associated bip number. the main difference between these two PRs are using block height vs MTP
< jeremyrubin>
the property that achow101's PR improves is a fixed # of signals
< achow101>
it comes down to mtp vs block height
< michaelfolkson>
amiti: I think there is consensus on block height from what I've seen
< jeremyrubin>
The question is if it is worth addtl review on new code.
< jeremyrubin>
I agree that height is superior long term
< michaelfolkson>
(but there are still a lot of reviewers who haven't looked at it yet)
< amiti>
micahelfolkson: I don't think you can claim that there is consensus on either, neither patch has been thoroughly reviewed
< achow101>
with mtp, we run the risk of losing 2 signaling periods. with already few signaling periods, this has the possibility of failng to activate due to bad luck
< luke-jr>
jeremyrubin: without height, ST doesn't have community support
< achow101>
amiti: consensus on the concept
< jeremyrubin>
But it's important to mind that for ST, it's a very short window of time (3 months) so by targetting a mid-period we have a known # of signals with high confidence
< luke-jr>
amiti: consensus has nothing to do with review
< michaelfolkson>
amiti: I'm only basing it on what I've seen in discussions and meetings. I personally don't have a (strong) view
< michaelfolkson>
We've had meetings with a number of Core contributors showing up and discussing it
< jeremyrubin>
achow101: the risk is tiny with MTP if you target mid signal periods, and only the last one matters
< michaelfolkson>
Deliberately off this channel so as not to block this channel for weeks/months
< jeremyrubin>
(is my point about mid period times falling on deaf ears?)
< jeremyrubin>
you would need a super large hashrate shift to happen, and then we'd have bigger problems
< dongcarl>
Originally, I planned to build things heads-down for 5 wks (ending today) then do user-testing + refinement for 5 weeks (ending on April 22nd). /1
< dongcarl>
However, many of you were eager enough to test my half-baked scripts, and I’m actually glad we did it this way because many pitfalls were discovered and fixed along the way (see #21375)! Thanks all! /2
< dongcarl>
So the new plan (operation “roll-with-it”) is this: we do the building + user testing for 4 more weeks (ending on April 15th), and after that we’ll agree on a commit on which to perform a non-codesigned build and upload signatures to `guix.sigs`. /3
< wumpus>
hebasto: sorry, i think some of the changes are a bit questionable/unnecessary, fine to let other people weigh in i don't have strong opinions about it but you asked me explicitly :)
< hebasto>
wumpus: I was talking about 21465, not #21463...
< bitcoin-git>
[bitcoin] sipa opened pull request #21471: bugfix: fix bech32_encode calls in gen_key_io_test_vectors.py (master...202103_bech32m_fix_genscript) https://github.com/bitcoin/bitcoin/pull/21471
< bitcoin-git>
[bitcoin] sipa opened pull request #21472: BIP 350: Implement Bech32m and use it for v1+ segwit addresses (0.19 backport) (0.19...202103_bech32m_0.19) https://github.com/bitcoin/bitcoin/pull/21472
< luke-jr>
hebasto: I guess it's a good idea; but might be a good idea to ask Transifex to support it in TS files first?
< hebasto>
luke-jr: they have a paid service for fork flow with XLIFF
< hebasto>
"Translate using XLIFF files as an intermediate format if you’re working with professional translators" -- https://www.transifex.com/pricing/
< hebasto>
*for work
< luke-jr>
wait, we'd need to pay to use it?
< hebasto>
no
< hebasto>
conversion on their side is paid -- "File conversion to XLIFF format is only available on the Premium plan and up."