"We are investigating reports of occasional DNS resolution errors. The AWS DNS servers are currently under a DDoS attack. Our DDoS mitigations are absorbing the vast majority of this traffic, but these mitigations are also flagging some legitimate customer queries at this time. We are actively working on additional mitigations, as well as tracking down the source of the attack to shut it down. Amazon S3 customers experiencing impact from this event can update the configuration of their clients accessing S3 to specify the specific region that their bucket is in when making requests to mitigate impact. For example, instead of "mybucket.s3.amazonaws.com" a customer would instead specify "mybucket.s3.us-west-2.amazonaws.com" for their bucket in the US-WEST-2 region. If you are using the AWS SDK, you can specify the region as part of the configuration of the Amazon S3 client to make sure your requests use this region-specific endpoint name."
Rain Financial | San Francisco, CA | Full Time | ONSITE
Rain is a regulated digital currency exchange established in a new region.
We have a partnership with a central bank, as well as multiple other banking partnerships. We believe we are a security company at our core. We are working closely with regulators to form one of the first licensed digital currency exchanges in the world. We strive to offer some of the industry's best rates and great customer support. We are currently in a private beta serving our first customers and building out a veteran technology team. We look forward to hearing from you.
Backend Engineer
Our platform team will be responsible for maintaining the backend systems that are responsible for managing users, processing orders, sending/receiving digital currency transactions, etc. We want to build a platform team of experienced, senior software engineers, that have 6+ years experience in the financial industry. They should have accumulated a great deal of domain knowledge about how to write software that handles money. In particular, they should have a solid understanding of how to build secure, robust, and scalable web applications. Knowledge of the digital currency industry is also highly sought after but not required.
Requirements
- Bachelor's degree in Computer Science, Engineering or related field
- You’ve been building large scale financial systems professionally for 6+ years and can point to things you’ve worked on
- You enjoy and have experience with building APIs at scale and know the factors that lead to a good API
- You are a very strong communicator. You’re excited to explain complex technical concepts and share your knowledge with different audiences
- You are curious how things work and when things break you are eager and able to help fix them
- You are located in or willing to relocate to the San Fransisco Bay Area
- Bonus: Experience with Go and Postgres
First of all, I haven't read the whitepaper yet, forgive me
But if I understand what you're saying correctly, Coco develops a smart contract that implements some sort of authentication method such that it cannot be publically read on the Ethereum blockchain?
And that the ability for Coco framework to implement those permissions depends upon the ledgers capability? So for example, Bitcoin's scripting language wouldn't be sophisticated enough to support authentication via Coco? (amongst numerous other functions of course)
There are three layers at work in the confidentiality demo.
Coco is at the bottom of the stack. Coco handles replication of data across a network of TEE-enabled nodes, ensuring confidentiality and integrity of the data. The data is only in the clear inside each enclave. Coco enforces network-level authentication, restricting connections to actors authorized by the network constitution. At this level there are no smart contracts.
In the middle of the stack is the ledger. In the demo that is Ethereum ported to run on Coco. We disabled a few Ethereum APIs so that transactions and smart contract state cannot be read directly. We also added access control to APIs that expose events.
At the top of the stack sit smart contracts that are hosted on the ledger. Here the DApp developer can add public read methods to expose any data that they want to expose, and they can implement access control within these smart contracts to restrict access to appropriate counterparties. This can be based on RBAC with arbitrarily fine-grained rules.
In the case of bitcoin, some design would be required. Today, the scripting language is used to decide whether to unlock UTXOs at the time that they are consumed as inputs to a new transaction. If bitcoin were integrated with Coco, there would have to be some modifications made to apply access control somewhere. This could be done in the ledger code. For example, it could only allow read access to a given transaction by the counterparties (it is not obvious how the counterparties would be identified, but in the P2PKH case perhaps the caller could sign the request with the private key corresponding to the public key hash of either an input or an output). Or the bitcoin ledger could be augmented by allowing the creation of scripts to govern access. They would need to be accommodated in the transaction format and stored along with the ledger. This would be a bigger change obviously.
