snd
could you try https://github.com/paritytech/parity-bridge/ to see whether your problem occurs there as well?
> We have a #564 to show more information on why every tested failed. When writing `echidna_b fails because it returns false` it wasn't my intent to criticize the error...
since `ValidatorSet.getValidators()` can grow/shrink dynamically a fixed `requiredSignatures` doesn't make sense anymore. we could replace `requiredSignatures` by `majorityPercentage` (`66` for example) and change the check for enough signatures to: `signatures.length...
the deposit case should be fairly straightforward: since the validator set exists on `foreign_chain` and transactions on `foreign_chain` are free for authorities we can have authorities retry `ForeignChain.deposit` (if no...
so far i see two approaches to solving the withdraw case: 1) involves relaying all changes to the validator set from foreign to home so HomeBridge stays up to date...
**search for "validator set chain" to skip to the proposed solution** currently the bridge uses equal fixed validator sets on both sides. `MainBridge` can verify/trust things that are signed by...
could allow for lower mainnet transaction cost per withdraw at the cost of a higher relay delay
> actually this might only be possible with UTXOs i thought ethereum didn't have UTXOs? i'm curious, how do UTXOs enable this scheme?
> 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...