Dev Meeting Transcript (June 18, 2021)

[3:55 PM] brianmct: Channel open!

[4:01 PM] Tron: Hello.

[4:02 PM] fdov: Hi.

[4:04 PM] Tron: Update on the EV Code Signing Key. I've ordered a 3 year key for the foundation. There is currently an issue with their verification of the phone number (one of the requirements). I gave them a Google Voice number that I've had for a long time. There is no "land-line" number and I didn't want it to reference my personal cell number.

[4:04 PM] Tron: I'm in the process of sorting this out.

[4:05 PM] fdov: Is that for Windows, or both Apple and Windows?

[4:05 PM] Tron: Windows

[4:06 PM] fdov: ok, I guess apple have their own way, as usual.

[4:07 PM] Tron: Does anyone know if there are crypto projects available from the App Store on Mac?

[4:08 PM] Someone_2: I never use the app store but, are you meaning like a wallet and so forth?

[4:08 PM] Tron: I've seen wallets, but core software.

[4:08 PM] Tron: I looked for Dash Core, Bitcoin Core, Litecoin Core. None seem to be there.

[4:08 PM] Someone_2: To me it seems like the last place anyone would put open source code related software.

[4:10 PM] Tron: Not allowed, or nobody has tried? There is an ease-of-use benefit, and a provenance (signing) benefit.

[4:10 PM] fdov: I don't care much about the appstore, but signing to remove the big warnings when installing, would be nice, if possible. (I don't do apple devices, heard rumours about the warnings).

[4:11 PM] Hans_Schmidt: During discussion of code signing keys in the SIG, there seemed to be consensus that we would use code signing keys for core binary releases if they were available, but release unsigned code if not available. Bitcoin has also done some unsigned releases.

[4:11 PM] Someone_2: Yeah I can see how warnings and so on would possibly dissuade or scare off inexperienced crypto enthusiasts.

[4:11 PM] kralverde: I believe for apple, you need a developer id for signing and then submit the binary for notarization to remove the “this software was download from the internet” warning

[4:14 PM] Hans_Schmidt: I personally don't care about App Stores. But I expect published hashes somewhere trustworthy to check against the binary.

[4:15 PM] fdov: the build-scripts make hashes automatically. For the test-releases I have combined them into a CHECKSUMS and gpg -clearsigned it with my gpg-key.

[4:15 PM] Tron: SHA256 and MD5 hashes have always been published for releases.

[4:15 PM] fdov: The rest of the signing business is basically just to remove warnings in osx and windows.

[4:18 PM] Hans_Schmidt: Hashes signed with a dev gpg-key seems sufficient to me. Having Appstore and/or apple/microsoft signing keys would be nice but not required. Sounds like Microsft key is doable. AppStore and Apple key maybe not.

[4:22 PM] Tron: I think the Apple one requires signing by one machine. It can be done, but then it has to be built by the keyholder. Is that a role we want the Foundation to perform?

[4:22 PM] fdov: If we go that path we should make a new file somewhere in github, similar to bitcoins contrib/verify-commits/trusted-hashes – with GPG fingerprints.

[4:24 PM] Hans_Schmidt: The current SIG members may not represent the community well since none of us are Apple fans (or barely users)

[4:24 PM] Jeroz: I have a macbook :stuck_out_tongue:

[4:24 PM] Hans_Schmidt: OK. one of us

[4:25 PM] fdov: 😀

[4:25 PM] Jeroz: I also use ubuntu, redhat, and windows 10 lol

[4:25 PM] Hans_Schmidt: The RavenQt SIG is planning on doing the first post-Medici "official" mainnet release (including P2SH assets) shortly after the audit is complete and any necessary patches have been made. For such releases in the past, there was a coordinated effort by the community to notify miners and exchanges in order to prevent a chain split and minimize confusion. Doing the hard fork without such a coordination effort could be risky for the chain. I would like to request community thoughts on who should coordinate this and how.

[4:28 PM] Tron: Correct me if I'm wrong, but if the BIP9 is working properly, it will not activate until X% of blocks have all adopted the P2SH version, so we need to make sure economic actors (payment gateways, exchanges, DEXes, etc) have all upgraded before the activation since they are at-risk.

[4:29 PM] fdov: Related to this, I propose that we make the lock-in window longer. 2016 blocks is way to short imo.

[4:29 PM] Hans_Schmidt: Agreed. How to make that happen smoothly and risk-free

[4:30 PM] LoranceCall: I can contribute at least testing using my mac if you guys need more hands. :popcorn:

[4:30 PM] Tron: Or, push the first activation date out a month or two after the release.

[4:30 PM] Tron: There are also two activations (locked-in, and activated) — both are 2016 blocks (about 1.4 days each).

[4:30 PM] fdov: That's not a problem. The feature I want to activate, is the warnings displayed when "new rules are active" – during the lock in, before activation.

[4:31 PM] fdov: Currently it's like 1,4 days.

[4:31 PM] Hans_Schmidt: On the other hand, a short coordinated change-over may be better than a long period of uncertainty. Plus we want P2SH assets soon.

[4:33 PM] Tron: We have the results back from the code audit. They started earlier than I expected.

[4:33 PM] fdov: It's not uncertainty imo. After lock-in there is no way back. We just give users some time to see the warning, review the update, and upgrade. (If they don't follow our announcements etc).

[4:34 PM] Tron: The good news is they didn't find any serious flaws in P2SH. The bad news is that they limited to P2SH pull-request.

[4:35 PM] fdov: What branch did they review, at what commit?

[4:35 PM] Tron:

Attachment file type: acrobat

ise-ravencoin-assessment-202106-r1.pdf

295.17 KB

[4:35 PM] fdov: omg. they did only the #873 ?

[4:36 PM] Tron: Yes

[4:37 PM] Hans_Schmidt: I would be ok with making the lock-in to activation delay up to a month rather than a few days. But not 6 months like bitcoin is doing for taproot. Anyone else have an opinion?

[4:38 PM] fdov: Wasted money, imo.

[4:38 PM] Tron: I like having a month. We can notify all the exchanges (that we can), and give them some time to upgrade.

[4:39 PM] Tron: For some of the exchanges, we only have contacts through their support. Sometimes we get feedback, and sometimes we don't.

[4:39 PM] fdov: Yeah, something like that.

[4:40 PM] Tron: There are five dates. Code release, activation start, locked-in, activated, first P2SH tx.

[4:40 PM] Tron: Worst case is that important exchanges aren't upgraded by P2SH tx.

[4:41 PM] Hans_Schmidt: "… so we need to make sure economic actors (payment gateways, exchanges, DEXes, etc) have all upgraded before the activation since they are at-risk" – who did this in the past? Is this something that you have time to coordinate? Or do you have suggestions?

[4:42 PM] Tron: Yes, we (team) notified everyone. There is no team. I have previous contact info, but new economic actors have been added since.

[4:43 PM] Tron: Jeroz helped.

[4:43 PM] fdov: Time to make a new team, then.

[4:44 PM] Hans_Schmidt: We need a miner representative

[4:45 PM] Tron: Someone in mind, or would it help for me to make a public request for one?

[4:47 PM] Hans_Schmidt: You are in the best position to ask people to help with the fork coordination. How is up to you imo.

[4:48 PM] #1RVNfan: What does being a mining representative entail? Just notifying pools of updates? I am a full-time miner and open to volunteer if no one else does.

[4:48 PM] brianmct: Yeah, the idea is we need to get all the major mining pools on the new software so that the BIP9 passes

[4:49 PM] brianmct: So we need to contact them and also all major exchange reps to upgrade so they're on the new fork once BIP9 passes

[4:50 PM] #1RVNfan: I can reach out to all publicly listed pools, though a large percentage of our hashrate is currently made up of unknown pools/solo miners

[4:50 PM] brianmct: We've done this in the past but there are new exchanges / mining pools / other economic actors since the last fork

[4:51 PM] Jeroz: I have an excel list with many contacts, Tron has access to that sheet too.

[4:53 PM] Tron: I will definitely help notify. The problem we've had in the past is that we don't have direct contact info for all the mining pools. That can make it tricky to get to 75 or 80%.

[4:53 PM] brianmct: I think what we need to do is estimate how long it would take to coordinate the transition then publish a transition plan. After that we can coordinate reaching out to pools and exchanges etc to get them to migrate

[4:54 PM] fdov: I don't think this will be a problem if we give it enough time. startTime at about release+1m, then timeout +1y, and it would make sense (to me anyway) to 10x the MinerConfirmationWindow from 2016.

[4:55 PM] Jeroz: Well that also gives time for all other parties to upgrade. Its a major headache for many users, and from experience, I expect that we have to help A LOT of people again with moving their wallet sync from a fork to the updated chain for months.

[4:55 PM] Tron: Idea…. The time it takes to activate is largely up to how well we can communicate with mining pools. If we start with notifying all the economic actors, and measure their feedback before the mining pool push, it is unlikely for it to activate too soon.

[4:56 PM] brianmct: Maybe it will be easier now that we have a functional electrum wallet with active devs?

[4:56 PM] brianmct: If folks have difficulty syncing we can point them to electrum

[4:56 PM] Jeroz: They would need to move their coins then though

[4:56 PM] Jeroz: from a working core wallet 😉

[4:57 PM] Jeroz: unless there is a sweep function

[5:00 PM] fdov: Tron I would keep the activation window long enough for both miners and pools to manage to update. We could do like release +60 days, or something like that. It's not like we need it to activate 3 days after release.

[5:00 PM] Tron: That sounds safer to me.

[5:00 PM] fdov: This is not a critical security update that needs to activate ASAP.

[5:04 PM] LoranceCall: Question, during the upgrade, is it suggested to move all $RVNs from exchange wallet to the core wallet? Or it is not a matter?

[5:05 PM] fdov: does not matter.

[5:09 PM] Hans_Schmidt: Does this represent the consensus for this discussion? >>

Code release & voting start

…variable time

1) notify users and exchanges – measure feedback

2) push mining pools

locked-in

…60 days – blast social media

activated & first P2SH asset

[5:10 PM] Tron: After it is locked-in, it only takes 2016 blocks (1.4 days) to activate. The social media blast should be simultaneous with mining push.

[5:10 PM] fdov: Hans_Schmidt To not over-complicate the code part, it is easier to start counting/voting approx. 60 days after release.

[5:10 PM] Tron: In fact a social media blast will be required to get mining to 80%

[5:11 PM] fdov: the 2016 block needs to be a complete epoch, so it could be double, if unlucky.

[5:12 PM] Tron: We can directly communicate with under 50% of miners – or at least that was true.

[5:12 PM] Tron: This is healthy, and part of the security of Ravencoin.

[5:15 PM] Tron: ———–

[5:15 PM] Tron: I'm going to talk to ISE about expanding the scope. What needs review?

[5:16 PM] Tron: I've already mentioned the wallet.cpp change to the randomization.

[5:16 PM] fdov: I'm not sure if it is worth the money. Does not look like they understand references.

[5:17 PM] fdov: Or it is just some automated scripts, idk.

[5:17 PM] Jeroz: would this be part of the same review?

[5:18 PM] Tron: I think it is a combination of things. I think their expertise isn't in the crypto-code field.

[5:18 PM] Tron: I don't think it would be part of the same review.

[5:19 PM] Tron: I thought they were going to do more. We had talked about reviewing anything having to do with consensus.

[5:22 PM] Jeroz: We decided on doing this back in February iirc. This was during a time where we had far less eyes on core code. I do think that having some sort of third party audit badge would be good for creating trust among (future) users and help adoption. Especially with the young history of RVN with lots of ups and downs. Not to discredit our current devs of course. But if I would be talking to a third party / user group, I think they would be less happy when I say "cuz fdov said so".

[5:23 PM] Jeroz: And rather say: cuz we have a lot of (independent) eyes on the code

[5:24 PM] fdov: Sure. But this is throwing money out the window. It's not worth anything imo.

[5:24 PM] Jeroz: But I agree that it does need to include a reasonable amount of "value" for what the community is paying

[5:25 PM] brianmct: I just took a look a look at the report, and wow it's really not worth anything

[5:26 PM] brianmct: They're all just basic surface-level C++ issues a junior engineer could point out in a code review

[5:26 PM] brianmct: Nothing useful at the protocol level

[5:27 PM] brianmct: I could give a more in-depth review in 15 minutes :sweat_smile:

[5:28 PM] Jeroz: please do :slight_smile:

[5:28 PM] Hans_Schmidt: I'm not a big fan of software security audits- they have almost no technical value IMO, and even less in crypto-currencies. But they do have some legal value. "Doing due diligence" means making an effort to get done what is available to you, whether that's good or not.

[5:29 PM] Tron: Agreed. Like the first report, it is hard to tell if they're digging deep and not finding anything, so the uninitialized vars is the only thing to report. Or if there's just a surface view of code. My analogy goes back to a mechanic evaluating a used car. Maybe everything is perfect and just one tire has low pressure. Or maybe they just kicked the tires.

[5:30 PM] Jeroz: was the tx issue that was later found, also found by ISE?

[5:30 PM] brianmct: Right; the only way to evaluate the audit is to have someone else find issues that the audit didn't find

[5:31 PM] fdov: And the vars in question are a 3 min fix, but they are a limited problem, because most of them are actually initialised by the isAssetScript function 2 lines down in most cases.

[5:33 PM] Tron: I'm reading Ted Harrington's book (Hackable), which discusses security audits, benefits of a long-term partnership, the benefits of white box vs. black box testing. https://www.linkedin.com/in/securityted/

[5:35 PM] Tron: He says that with black box testing, you're not getting much, and it's like testing the security audit team, where white-box let's the team find the flaws. But, I can also see that knowing the team found something deep, has its advantages in terms of inspiring confidence in the methodology.

[5:35 PM] Tron: Ravencoin is open-source, so white-box is the only option.

[5:37 PM] brianmct: One thing that could inspire confidence is if the security report provided a detailed explanation of how the code worked. Basically prove that the reviewers actually understand the code even though they didn't find anything substantial

[5:38 PM] Hans_Schmidt: The old model of adding security audits at the end of the SDLC doesn't work well. We need to build security into the dev flow. Step 1 could be adding some code analyzers to the github actions build scripts, which would easily flag what this audit report found.

[5:38 PM] Tron: Ted Harrington is the co-founder of ISE.

[5:42 PM] fdov: If they checked out the code from PR #873 directly, they did not find a hardfork before activation, probably didn't look for one either. Or did they and didn't write anything about it as we found it on our own?

[5:42 PM] brianmct: Anyways, I'll take a look at the P2SH PR when I have time this weekend. Is it just #873 or is there other code to review?

[5:42 PM] Hans_Schmidt: Also PR1019

[5:43 PM] fdov: brianmct current develop branch. bascially anything touching src/wallet and src/validation.* and src/consensus

[5:44 PM] brianmct: Alright I'll take a look, hope it's not too much code to review :sweat_smile:

[5:44 PM] Hans_Schmidt: OK, so no changes to "lock-in to activation delay" like on taproot. This then? >>

Code release

— 60 days

Voting start

…variable time

-notify users, exchanges, social meida, mining pools

locked-in

… 1 to 2 * 2016 blocks

activated + first P2SH asset

[5:45 PM] Jeroz: Why is everyone notified after 60 days and not at release?

[5:46 PM] fdov: start notifying at release.

[5:46 PM] Jeroz: Yes

[5:46 PM] Tron: Start notifying everyone but miners at release.

[5:46 PM] Tron: We need all the economic actors first.

[5:46 PM] Hans_Schmidt: your turn to make the graph :upside_down:

[5:47 PM] fdov: Miners too, it's just good that they update early. We control the nStartTime counting does not start until release+60d. and nTimeOut should be like +1y.

[5:49 PM] Jeroz: OK, so no changes to "lock-in to activation delay" like on taproot. This then? >>

Code release

-notify users, exchanges, social meida, mining pools

— 60 days

Voting start

…variable time

– keep actively notifying (also to make sure enough miners are reached)

locked-in

… 1 to 2 * 2016 blocks

activated + first P2SH asset

[5:50 PM] Hans_Schmidt: Finally agreement?

[5:50 PM] Tron: Consensus!

[5:51 PM] brianmct: We should make a blog post about the release timeline once the code release is published 🙂

[5:52 PM] brianmct: Also do we have a fork tracker? I recall having one last time

[5:52 PM] Tron: I have to run. If you have anything we should have ISE review, DM me.

[5:52 PM] brianmct: Okay cool, we're way over time anyways

[5:52 PM] Tron: If we have a fork tracker, send it to me and I'll put it on the Foundation website, and add it to the dashboard, and notifications.

[5:52 PM] Jeroz: Also that updating is mandatory to stay on the chain if enough miners decide to mine with the new consensus rules

[5:53 PM] Hans_Schmidt: Good meeting

[5:53 PM] fdov: Tron We need more users with github access. I suggest Ben, brianmct and myself.

[5:54 PM] brianmct: I haven't really studied the code much so I'll decline GitHub access for now 🙂

[5:54 PM] fdov: If that is too many, delete anyone without a commit the last 12m.

[5:54 PM] fdov: brianmctwe need two reviwers with write access. Currently I have to make all PRs because HyperPeek and Hans_Schmidt are the only active ones with write access. It's stupid.

[5:55 PM] Tron: I'll come back and look at this and make GitHub permission changes.

[5:57 PM] brianmct: Fair enough, I'm comfortable enough to do basic code reviews, probably won't have time to contribute code though

[5:57 PM] brianmct: Anyways let's wrap up the meeting, were already way over time

[5:57 PM] brianmct: We can continue discussion in #ravenqt-sig-working

[5:57 PM] fdov: :thumbsup:

[5:58 PM] Hans_Schmidt: TTYL. Have a good one.