Holy crap you guys. Eureka! I figured it out! Not just a stop gap measure to address the fork ring sig reuse problem. The actual solution! I was just laying in bed trying to fall asleep and it hit me like a tire iron to the face.
It is possable to deterministically derive ring sig partners but in a way that would be functionally random to any outside observer. I'll give an example of one way of doing it. Take
sha256([your private key] [transaction hash of most recent input]) mod [number of prospective ring signature partners]
Then make all of the prospective ring signature partners into an ordered numbered set and use the resulting modulus from the pseudo code above to select one. Continue wrapping around the clock face as many times as needed to arrive at the number of ring signature partners desired.
There would be 0 information leak from the outside, the ring signature partners would be functionally random to any outside observer BUT, and here is the beautiful thing, the same ring signature partners would end up being selected on both the main chain
AND the fork chain!
Of course what I outlined above almost certainly isn't the best way to achieve this. It was just to outline the concept.
Merits! I deserve all of the merits. Bequeath unto me thine merits! (well, after peer review, and not just if my specific idea is right but if I'm barking up close enough to the right tree to inspire someone smarter than me)
