Dev Meeting Transcript (November 5, 2021)

[3:52 PM] Tron: ————————————————————

[3:52 PM] Tron: Channel Open

[4:00 PM] fdov: hi.

[4:04 PM] Hans_Schmidt: Yo

[4:08 PM] fdov: I noticed the build-checks still does not handle .md changes well. But I noticed the PRs are made against master, could be the issue. not sure.

[4:10 PM] Hans_Schmidt: IIRC, that's something that we don't have the authority to change.

[4:10 PM] fdov: I guess if you change the target for the PR to develop, it will rebuild and hopefully work?

[4:11 PM] fdov: I don't think the latest change (#1078) is merged to master yet.

[4:12 PM] Tron: Can you make a PR for moving develop to master? It will take approvals. If I make it, I can't approve it.

[4:12 PM] fdov: sure, one sec.

[4:13 PM] Hans_Schmidt: I believe you are correct on both counts

[4:15 PM] Tron: Is anyone currently building on Mac (Monterey)?

[4:18 PM] fdov: I get some github error.. I'll create the PR later.

[4:19 PM] fdov: I don't have macs. But the new M1 pro looks really nice.

[4:19 PM] kralverde 🇺🇸 {CULT OF JOE}: 👋

[4:19 PM] Hans_Schmidt: No macs for me

[4:20 PM] fdov: I can build -for- mac.

[4:20 PM] Tron: I just got the 16" M1 Max yesterday. I'm setting up the build environment and running into a few issues. If anyone has slogged through the issues already, let me know.

[4:21 PM] fdov: I guess there are tons if you try to use the depends/ system. – I'm pretty sure that does not work.

[4:24 PM] Tron: Yeah, so far it hasn't worked. There is info on the ones I've run into so far, so I'm just documenting the issues and solutions as I go. Then we can either update the build docs, or fix the make system to compensate for the environment changes.

[4:25 PM] fdov: do you install the depends with brew?

[4:26 PM] Tron: Some of both so far. Apple has moved the default location for the SDK, so I'm working on that now.

[4:27 PM] Tron: The SDK can't legally be added to the repo. Installed with XCode, or downloadable from Apple.

[4:29 PM] fdov: You can download it to your machine. I've made some builds scripts look for it in /tmp/SDKs – that is for cross-compiling for osx.

[4:29 PM] fdov: Fastest is probably to make docker work, and just cross-compile. 😉

[4:30 PM] fdov: Apple are so developer-unfriendly it's insane.

[4:32 PM] fdov: Anyway, I've made some PRs i think would be good to get into the next release, if reviewed and approved. #1115 probably the most important.

[4:34 PM] Hans_Schmidt: Thanks, I saw the PRs. I will review and approve.

[4:35 PM] fdov: If the P2SH-assets-part needs more reviewing, I'm all for a release with the code in, but not activated on mainnet. – Making a new release with activation is easy.

[4:37 PM] Hans_Schmidt: I guess that's up for debate whether people want to be cautious and release without P2SH assets

[4:37 PM] fdov: I'm fine with both.

[4:38 PM] Tron: We should set an activation date where it can begin to count the blocks towards activation percentage — possibility of activation.

[4:38 PM] Tron: Before or after halving?

[4:39 PM] Tron: What percentage should we target?

[4:39 PM] Tron: Super conservative 95%

[4:39 PM] Tron: Conservative 90%

[4:40 PM] Tron: Anything less than 75% seems risky.

[4:40 PM] fdov: Whatever bitcoin uses? 80-90-ish?

[4:40 PM] Tron: 80 or 85 seems right.

[4:41 PM] Tron: It will be difficult to get to 85 with the communication channels that we have with mining pools.

[4:42 PM] Tron: 75% hasn't been easy, and requires some push with translated (localized) information.

[4:43 PM] Hans_Schmidt: The down side of having really decentralized mining 😉

[4:43 PM] fdov: Hardforking without 80+ isn't nice to the other 20-25%…

[4:44 PM] Someone_2: It seems like previous forks were at 85% but it did brush into some obnoxiousness and absurdity trying to get the word out. 80% may be more practical but then you also have a bit more risk of conspiracy stuff erupting.

[4:45 PM] fdov: Just set a long timeout, and set the "notification time" after lock in before activation to more than 1 day.

[4:46 PM] Tron: Agreed. We can only count the blocks that are mined as a trigger for activation. All economic actors (exchanges, merchants, known users) should be notified in advance of the possibility of activation.

[4:47 PM] Tron: Most important are exchanges, swap sites, and merchants. Users (spenders) will not be hurt if the spend on the wrong chain. They update, and spend again.

[4:55 PM] fdov: I think we should consider the number of blocks in the retarget-period after lockin.

[4:58 PM] Tron: A longer cycle than 1 2016-block cycle?

[4:58 PM] fdov: Yes.

[4:59 PM] Tron: The cycles are inherited from bitcoin, but since the blocks are 10x faster, the lock-in to activation is 1.4 days instead of 14 days.

[4:59 PM] fdov: exactly.

[4:59 PM] Tron: Do we keep the 1.4 day counting cycle?

[4:59 PM] Tron: Or just add a 0 to the number of blocks for both, to make both 2 weeks.

[5:00 PM] Tron: 20160 blocks per cycle.

[5:00 PM] fdov: Add the 0 is easiest.

[5:00 PM] Hans_Schmidt: I agree. The current settings have never seemed appropriate to me. Add a 0 makes sense.

[5:01 PM] fdov: If we make that change, users of the old wallet will get notifications for 14 days after the count is finished, and the feature is locked-in. Before anything activates.

[5:02 PM] Hans_Schmidt: Exactly what we want

[5:02 PM] Tron: Ok.

[5:02 PM] fdov: If you are Big Exchange Inc. and ignore e-mail notification, releases on github, etc. – I hope you check logs, at least once every 14 days.

[5:03 PM] Hans_Schmidt: It also gives social media more time to hear the buzz and distribute the message

[5:04 PM] Tron: I'll start notifying exchanges and swap sites as soon as we have a signed release candidate for download.

[5:05 PM] Tron: Even before the possibility of activation begins.

[5:08 PM] fdov: The earliest time of activation will be about a month after counting starts, in this case. If the first count period hits the threshold.

[5:10 PM] Hans_Schmidt: I gotta run, so TTYL. It was a nice little mini-reunion.

[5:11 PM] fdov: yeah, long time. nice to see you. later.

[5:17 PM] fdov: Tron PR with a merge of current develop to master created. #1119. If you review and approve, I suggest we ask HyperPeek to merge it. He's got a routine to merge it cleanly without the "merge bla bla" messages in git history.

[5:17 PM] Tron: Nice. Thank you!

[5:19 PM] fdov: If you find the time, reviews of #1111, #1113, #1115 and #1118 should all be simple. Mostly manual backports from bitcoin with links to upstream changes.

[5:20 PM] fdov: Most of them close CVE issues.

[5:22 PM] fdov: Looks like that's it for today? I'll stick around in thenest and development for a while.

[5:28 PM] Tron: Thanks fdov