Yeah I mean it's only useful in certain conditions like secrets. Clearing the stack with fencing is SLOW as fuck like 1000s of CPU cycles to write back to physical memory, often blocking other threads, and dealing with kernel preemption. That's a massive slowdown. Were willing to take the massive performance hit for secrets though.  

 Probably 100,000s of cpu cycles 

 ```go
func Zero(sk *SecKey) {
	b := (*[96]byte)(unsafe.Pointer(sk))[:96]
	tmp := byte(1)
	for i := range b {
		for tmp != 0 {
			b[i] = 0
			tmp = b[i]
		}
	}
}
``` 

 i have an idea 

 forget zero, scramble 

 ```go
func Zero(sk *SecKey) {
	b := (*[96]byte)(unsafe.Pointer(sk))[:96]
	for i := range 8 {
		rand.Read(b)
	}
	// reverse the order and negate
	for i := range b {
		b[i] = ^b[len(b)-1-i]
	}
}
```

this should rewrite the bits 8 times with secure random bits and then reverse and negate them, i can't see how it could optimize that out 

 and yeah, i sorta have an idea about this... in Go, it caches tests with deterministic results, but tests that read from the crypto/rand library never do, neither do the ones even from pseudorandom generators like luke champine's frand, which uses chacha12/20 hash chains and seeds 

 Yeah many people write CSRNG data instead of zeroing. It's an option. Don't know the results of it's effectiveness. I've considered it in some instances.  

 it bypasses the problem of optimization 

 it also mitigates against flash memory shadows 

 I'm not sure it will do that. Depends on the controller I guess. Some flash controllers can randomize writes and mark an old block as stale for wear leveling 

 well, really the chances of a key falling into swap are nearly insignificant if the signing is being done frequently

but even stilll, i've put 8 rewrites on it, even if it optimizes out to only one actual write it's still effective 

 Yes and if it's that important you can always use mlock() or VirtualLock() 

 oh yeah i am always forgetting... with Go there is always cgo for this kind of thing or maybe it can be done with assembler, assembler is preferable because it doesn't complicate the build workflow

not sure about such kernel specific calls and build workflow but probably it's something you can just dump into the symbol tabel and voila 

 i would very much like to spend a whole month reviewing that library and porting it to pure Go and inserting some SIMD instructions where relevant 

 Reviewers are not contributors, that's a project issue. It doesn't look like there is a lack of contributions. I don't know what the processes now, but I don't remember it being worth many people's time to become part of the project because if their red tape.

I'm not suggesting Bitcoin-Core developers suck as a whole, most are probably far more intelligent than myself. I'm saying they made a pretty silly mistake that MANY if not MOST other developers make and that took way too long to make it to release (that should have been a patch release). 

I also think criticism shouldn't be stifled for the sake of "if you can do it better, just do it yourself" doesn't fix the problem that everyone else depends on X project and they have obvious problems they aren't fixing etc. 

Could I have worded my original note better, probably, do I think I shouldn't have said anything at all. No.  

 At this point I'm considering vendoring the entire project for noscrypt. I'll have to review open PRs to see what else is missing I could fast-track.  

 I'm available now for a 1-1 convo.-!!
You can connect with me via simpleX Chat with the link below ⏬ 
https://simplex.chat/contact#/?v=2-7&smp=smp%3A%2F%2FPtsqghzQKU83kYTlQ1VKg996dW4Cw4x_bvpKmiv8uns%3D%40smp18.simplex.im%2FD1yZe9VTHaaYgGw5orbCq5dKNRuXn67I%23%2F%3Fv%3D1-3%26dh%3DMCowBQYDK2VuAyEA8jxuVUwBtzlwikmHx9Tqpstet3raCJyvenI2ql6lWyk%253D%26srv%3Dlyqpnwbs2zqfr45jqkncwpywpbtq7jrhxnib5qddtr6npjyezuwd3nqd.onion