Quote from: phishead on March 09, 2018, 03:16:04 PM

Quote from: Anon136 on March 09, 2018, 11:01:21 AM

I'm going to X-post this over here too from the main thread because I ~~think~~ hope it is important.

Quote from: Anon136 on March 09, 2018, 10:51:56 AM

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

Code:

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)

To the average lurker who doesn't understand all the ins and outs of how you could pair up the same ring sigs, it sounds crazy enough to work. I bequeath you 1 merit, and 1 more if it actually works. Hopefully enough merits will help you sleep better at night.

I had some more time to think about it. It does have one flaw that I have thought of so far.

There is no way for an outside observer to verify that this method of ring sig partner selection had been used. So someone could run their own custom modified software that selected ring signature partners truely randomly their transactions would still be accepted by the network (though I don't know who would do that or why). Or if a fork chain was purposely malicious they could always delete this little bit of code roll that part of the software back to the way it is now. However if they did change that bit of code their motives would immediately become highly suspect, if not beyond reasonable doubt level incriminating, and this would severely damage if not ruin the reputation of their project (one hopes Roll Eyes

).

Also I think the current ring sig partner selection weights newer transactions. So talking about random all the time like I was I don't think is technically completely accurate. But it helped to simplify the point I was trying to make and I think it was ok because a very similar weighting could be incorporated into the scheme I laid out with only minor modifications.