collusion resistance

[snd]

notes by @rphmeier

collusion-resistance: have authorities perform blind-signatures on some kind of relay request hash. that preimage then gets revealed on the home chain after the signature is relayed. then the funds are released to the person named in the preimage

if we require a deposit on the relay request and enforce that the preimage is also revealed after some time on the foreign chain, we can put a cryptoeconomic protection on authorities ever relayed garbage

(actually we can have this protection on either chain, perhaps configurable)

slight hiccup around determining how many tokens a request actually transfers back from foreign, might require another round of communication to the foreign chain after the relay successfully completes

actually this might only be possible with UTXOs

more generally I would like to have a conversation about reducing the collusion risk just to censorship if possible

actually I don't think we need UTXOs for the scheme above, the only issue is if authorities sign their own garbage requests. if we can find a way to actually make a block invalid on the foreign chain if they do that (admin contract could do it), then they can't do it without forking the foreign chain

[rphmeier]

I also think this is a good case for having separate sets of bridge and chain authorities. It's not possible to make the security of a sidechain any better than the security of the network overall and having the authorities be different actors than those who are meant to provide security for the network really raises the bar against collusion.

[snd]

actually this might only be possible with UTXOs

i thought ethereum didn't have UTXOs? i'm curious, how do UTXOs enable this scheme?

[snd]

reducing the collusion risk just to censorship if possible

that would be great! security was the biggest issue in feedback at scaling now barcelona

having the authorities be different actors than those who are meant to provide security for the network really raises the bar against collusion.

indeed. those authorities would be the weakest link and they could (currently) collude to transfer main network assets that are in custody of the bridge. reducing that collusion risk is important.

collusion-resistance: have authorities perform blind-signatures on some kind of relay request hash. that preimage then gets revealed on the home chain after the signature is relayed. then the funds are released to the person named in the preimage

in other words: users of the bridge submit a hash of the message, that hash is relayed, then the user reveals the message on both sides (or one side and the authorities do so on the other later)? the contents of the message are not known to authorities during the relay. is that correct?

when relaying hashes there's no way to verify a message on the originating side. currently for example when transferring back there's a balance check. if only the hash is known no balance check is possible. users could send over invalid messages. solving this would require another roundtrip.

in general i'd prefer collusion resistance and security over low latency and low relay costs.
the bridge should be used for infrequent but secure transfers.
that fits well with all use cases we've collected so far.
seems ok to have multiple roundtrips if that increases security.
latency will be quite high in the main->side case anyway since we should wait for a high number (cosmos uses 100 for their ether peg zone) confirmations to minimize the probability of reorgs.

[snd]

if we'd require bridge users to sign (only possible off chain, right?) off on the withdraw message (recipient, amount) as well, submit message and signature on side, relay both as usual and check that signature on home, then authorities, even if they collude, could not forge requests that transfer a users funds. users would not give up control. to withdraw from address both the signature of address as well as of a majority of authorities would be required.

if i'm not mistaken this would decrease collusion risk to censorship. on the other hand it would require the additional off chain signing step for any use of the bridge. it would also make the bridge less "programmable" as smart contracts could only call the bridge if they themselves took the signature (on withdraw) from the user.

[rphmeier]

@snd what I mean about UTXOs is that they make it easy to provide a chain of ownership of a specific coin (we can use different denominations). The alternative approach is merkle trees mapping [coin id -> owner] sort of like plasma cash.

[snd]

@rphmeier after watching vitaliks talk on plasma cash from ethcc i get why you mentioned UTXOs.

i can see a design similar to plasma cash make sense for the bridge.

i imagine dapps bridging their token would feel much more comfortable if they had a daemon running that would verify all exits (withdraws) and automatically challenge them if the bridge authorities colluded.

[snd]

@rphmeier this is all token (deposit, withdraw) specific. does this generalize into a bridge that does arbitrary message passing (essentially calling a function on the other chain)?

[rphmeier]

provided that calls each correspond to some kind of proof of existence like coins would then I think so, yeah. We can think of transferring a call as depositing or withdrawing a single non-fungible coin.