#bitsquare.io

mkarrer, yes the 1 is the backstop in case of everything else being corrupted. if you're trying to argue for randomly chosen arbiters in a pool, well that was always what i argued for :)

mkarrer, also this discussion, don't know if you saw it: https://github.com/OpenBazaar/OpenBazaar/issues...

you know on reflection, they didn't address my concerns, ultimately. they still need a source of randomness, and they are talking about notaries, but i believe arbiters are where the real risk of collusion is.

(although totally understood that this isnt the highest priority for your or their system...)

waxwing: unfortunately I don't have time to step into their discussion, but it seems that their system is too complicate. I am also not sure if the collusion protection form the arbiters deposit is not enough at all. like the arbiters are the main protection in the trade and additional features like reputation would only introduce more problems, the collusiton problem in the artbiter system can be prevented via th

e deposit and 2. round. assuming we can have a reliable hi-trust circle of arbiters, which is not a pointless assumtion. We don't need to design a completely trust-free system, the people need to trust the software devs (open source is not enough) and the arbiter system will bootstrap from the devs. there will be a natural reputation which can be used to build up that hi-trusted circle for the 2. round arbitration

(in case of collusion or low quality work).

in our system though the selection might be done via randomness derived from private data of both (account id is not known before the takers trading fee is paid, so the taker would lose his taker fee if he want to corrupt that, not a very strong protection but the main protection against collusion is the 2. round/deposit)

more thoughts about randomness: one way to obtain some is to create a key pair, then use the private key to sign/decrypt the hash of a NUMS number

good timing i just got back :)

yesterday i was thinking, what you proposed before, i couldn't see how it would work now

waxwing: which one?

if everyone generates a rand and then xors, the problem is where does the xoring happen

or does everyone commit first

i guess that's the trick eh,commit/reveal

waxwing: yes, forgot to say everyone should commit first

so what's NUMS? vaguely heard about it but forgot

nothing up my sleeve number

say the hash of the time now, to the microsecond/second

then hash it

then try to "decrypt" or sign it with an existing private key

oakpacific, interesting point. addresses could be ones committed to through deposit/proof of burn.

but it does rather depend what you're using the rand for.

example: you use the rand to choose between 5 possible arbiters.

then you can just cycle the microseconds until you get one in the right range.

the commitment/xor approach sounds good. i just wonder about irrefutable publication though. if everyone's sending their commitments on a DHT, let's say ... do we end up needing a blockchain anyway?

i am actually thinking about whether anything could be done to make tlsnotary proof collusion-resistant

oakpacific, well, if the arbiter has to publish his result before he knows who the counterparties are, then that would be great. but seems impossible as fundamentally that information must be in the transaction data that he bases his decision on.

still, interesting line of thought.