Assuming you mean the attack where one person can wait to be the last to reveal their secret and then influence the game by dropping out, it doesn't appear to.
> What if someone loses network before the secret stage?
> A bad actor can't change the outcome of a flip but could prevent it from resolving.
> The Keybase app will highlight this scenario. Odds are it was just a network issue, but if you have such a person disappearing often, you should break up with them.
So someone with a malicious client could force the flip to not resolve until it creates an outcome they're satisfied with, which is... Not great. I can't tell if "The Keybase app will highlight this scenario" means it'll abort the roll or if it'll automatically reroll.
One way to solve this issue is to shuffle the possible outcomes and encrypt or hash their positions along with a nonce. This info would be distributed to clients during the game initialization. At reveal time, the server presents these outcome positions to the clients along with the other client secrets.
Also see my other comment in this thread where in a client/server architectured version of this protocol, the reveal step is split up in to two stages:
> 4a. All members submit their secret values to the server.
> 4b. Once all secret values are submitted, they are all sent to each member at once.
> This ensures that members cannot determine the outcome before anyone else.
Even requiring a deterministic reveal order (without a central, independent server) would reduce the chance an individual could force a reroll after knowing the outcome from 1/1 to 1/n, which would be significant. The 'central server' solution is probably more relevant for Keybase though.
TBH get comfortable with writing a web server in your favorite language and a popular framework e.g. flask (python), go (gorilla/mux), nodejs (express). Then try using it to make calls to an external system like a database. As a backend developer you should have a good feel for the data flow through the application stack.
There's nothing special about backend development, its mostly about the "plumbing" between systems. Lots of de(serializing) (e.g. json, protobuf) messages into objects and validation of those messages
I think the high wages are due to a lack of understanding from non-programmers. Non-technical folk see it as scary or hard to understand so would rather pay someone else to handle that stuff. We're on the inside looking out, not everyone wants to understand. As I'm sure we're all familiar with- i.e. the conversation killer of explaining our day job or even mentioning I'm in software/IT/programming etc.
> Digital currency can only be the #1 use case if we find a generic, uniform way to pull in real-time real-world data of which we can verify its confidentiality, integrity and availability.
I'm not sure I understand your point here
> Do you think fintech/banks can work use public ledgers?
The only reason they'd want a public ledger is for transparency with end users. This isn't high on their priority list but more importantly there's too much at stake to leave the protocol up to anonymous public participants.
Consortium chains make a lot of sense in these private B2B transfers. Which is the goal of something like Stellar as the only incentive to run a node is to keep the ledger/service lively. It is also a better engineering tradeoff to have a dedicated chain to process Txs only you care about and not have it degrade from cryptokitties. Lots of blockchain projects are moving to this parachain model. E.g. substrate, tendermint, plasma protocol
