OnlinePaySystems.info

235 systems total

Login | Register

You are watching news of Coinbase. Go back to all news.

• 

  View all news of Coinbase
  
  Posted on November 20, 2018

  Coinbase at AWS re:Invent 2018

  

  The AWS re:Invent conference is coming to Las Vegas the week of November 26–30, and Coinbase is representing! Our incredible Product and Engineering team members will be speaking about site reliability, scaling our blockchain infrastructure, teaching about cryptocurrencies, and co-hosting a Happy Hour with our AWS friends. Come and join us!

  AWS re:Invent is the annual Amazon Web Services (AWS) learning conference in Las Vegas that attracts developers, system administrators, architects, and technical decision makers from all over the cloud computing world. Last year, they had an estimated attendance of 43,000 and succeeded in taking over most of the famous Las Vegas Strip. This year, re:Invent is anticipated to set new records, and the Coinbase team is proud to be contributing to the learning aspect of the conference, as well as facilitating some after-hours mingling time with our fellow attendees.

  Coinbase has a special relationship with Amazon on a few levels. First, AWS powers almost all of Coinbase’s infrastructure, from storage, databases, analytics, you name it. Second, our VP of Engineering, Tim Wagner, recently came to us from Amazon, where he was the General Manager of AWS Lambda and a pioneer of serverless computing. We are incredibly lucky to have him lead and grow our world-class Engineering team. Third, we are on a mission to build an open financial system for the world and with that, bring the utility of blockchain and digital currencies to the masses.

  

  Back when Web 1.0 was just taking off, there were folks who were still unsure about the promise of telecommuting workers or even buying stuff over a network, and Amazon was there to pave the way. I was consulting at a hot young start-up called AltaVista, developing new, innovative consumer-focused features: integrating product search into web search results and building streaming music samples into product pages. This was before people were sure that buying things over a distributed network wasn’t just a passing fad. A marketing exec walked to my desk, slapped some papers down, and said, “I want you to make it look exactly like this!” He had printed out several pages from a site called Amazon.com, Earth’s Biggest Bookstore. Wow. It was forward-thinking and visionary for its time. Amazon really believed in that promise. The art of up-selling and cross-selling on the web, reproducing what customers might experience in a brick and mortar shop, and “ease of use” came from companies like Amazon. They were dead serious about this “buying stuff over a network” thing! Later on, Amazon took it to whole new level with AWS, by commoditizing compute power and enabling companies to focus on their core businesses. There are but a few companies from Web 1.0 that weathered the booms and busts and have gone on to reinforce the foundations on which Web 1.0 and 2.0 are built.

  Coinbase will be the one that weathers the booms and busts of Web 3.0. We believe, just like Amazon believed. As a company that has grown from 250 employees to over 600 this past year, we are in it for the long haul. Our engineers and product managers are excited about sharing stories from the trenches, our lessons learned, and talking shop about blockchain, crypto, and decentralized applications with fellow technologists who want to come along for the ride.

  

  Conference Events

  If you are attending the conference, or watching from the comfort of your home or office over Twitch, please tune in for the following sessions by our talented colleagues:

  • Niall O’Higgins, Engineering Manager of the Coinbase Site Reliability Engineering team, will be co-presenting with Datadog on building processes and adopting practices that helped scale our SRE group during hyper growth. Tuesday 11/27, 11:30 am — 12:30 pm, Aria West, Level 3, Juniper 1
  • Graham Jensen, Technical Lead on the Coinbase Infrastructure team, will be recording a video with the AWS Step Functions team on how Coinbase uses Step Functions to coordinate serverless workflows. Tuesday 11/27, 1:45 pm — 2:45 pm, Expo, Scamall Theater
  • Kristen Stone, Product Manager of the Coinbase Cryptocurrency Payments team, and Jake Craige, the team’s Technical Lead, will be holding a Cryptocurrency 101 & 201 breakout session to discuss the evolution of blockchain, its impact on our day-to-day lives, a deep dive into the inner workings of the tech, and what’s on the horizon. Wednesday 11/28, 4–5 pm, Startup Central @ The Aria
  • Coinbase Crypto Happy Hour will be hosted at The Aria, right after our Crypto 101 & 201 session and is sponsored by AWS, Coinbase Engineering, and Coinbase Recruiting. Please come join us for hor d’oeuvres and a fully hosted bar! Wednesday 11/28, 5–6 pm at Startup Central @ The Aria
  • Jack Kearney, Senior Software Engineer from the Coinbase Custody team, will be sharing how Coinbase builds out its blockchain infrastructure in a way that allows other teams to use blockchain nodes as a service. Thursday 11/29, 11 — noon, Startup Central @ The Aria

  We look forward to seeing you at re:Invent! For the latest news and updates, follow us on Twitter @Coinbase, or like us on Facebook. Interested in learning more about opportunities at Coinbase? Check out our careers page. We saved a seat for you!

  This website may contain links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.

  

  ---

  Coinbase at AWS re:Invent 2018 was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

  Read more on Coinbase
• 

  View all news of Coinbase
  
  Posted on November 20, 2018

  AWS Step Functions, State Machines, Bifrost, and Building Deployers

  AWS Step Functions are hosted state-machines defined according to the Amazon States Language. To execute a Step function you send it JSON data which is given to an initial state to process then pass the output to another state. States are processed until a success or failure state is reached.

  How a state processes its input and selects the next state depends on its Type. For example, a Task state can use a Lambda function to process the input, and a Choice state can select which state to go to next based on its input.

  Step functions are awesome because they:

  1. Explicitly define the order of execution, including all conditional paths, in a simple to understand model.
  2. Perform common tasks, like calling Lambda functions, removing a ton of boilerplate code.
  3. Handle errors and retrying in response to failure increasing reliability without sacrificing understandability.

  Here is a small example where a state-machine calls out to a Lambda function and makes a choice based on its output:

  {
   "StartAt": "CallLambda",
   "States": {
    "CallLambda": {
     "Type": "Task",
     "Resource": "<lambda_arn>",
     "Next": "Worked?",
     "Retry": [{ "ErrorEquals": ["KnownError"] }],
     "Catch": [{
      "ErrorEquals": ["States.ALL"],
      "Next": "Failure"
     }]
    },
    "Worked?": {
     "Type": "Choice",
     "Choices": [
      {
       "Variable": "$.Worked",
       "BooleanEquals": true,
       "Next": "Success"
      }
    ],
    "Default": "Failure"
   },
   "Success": {
    "Type": "Succeed"
   },
   "Failure": {
     "Type": "Fail”
    } 
   }
  }

  This state-machine looks like (generated with step dot --states <state_machine>):

  

  StartAt defines the initial state CallLambda that executes the lambda at <lambda_arn>. The lambda’s output is then sent to Worked?, which goes to Success if its $.Worked attribute is true, otherwise it goes to Failure. If CallLambda returns a KnownError, it will Retry. For other errors it will go to Failure asStates.ALL is a catch-all for any error.

  Lambda code and Step functions are separated from one another in AWS and can be developed independently. This can make them difficult to test and validate, as a change in one can cause a bug in the other. To make it easier to develop and test Step functions and Lambda we built the Step framework.

  Here is an example of a state-machine using the Step framework:

  func StateMachine() (*machine.StateMachine) {
   state_machine, _ := machine.FromJSON([]byte(`{
   "StartAt": "CallLambda",
   "States": {
    "CallLambda": {
     "Type": "TaskFn",
      "Next": "Worked?",
      "Retry": [{ "ErrorEquals": ["KnownError"] }],
      "Catch": [{
        "ErrorEquals": ["States.ALL"],
        "Next": "Failure"
       }]
      },
      "Worked?": {
       "Type": "Choice",
       "Choices": [
         {
          "Variable": "$.Worked",
          "BooleanEquals": true,
          "Next": "Success"
         }
        ],
        "Default": "Failure"
       },
       "Success": {
        "Type": "Succeed"
       },
       "Failure": {
        "Type": "Fail”
       }
   }}`))
  
   state_machine.SetResourceFunction("CallLambda", LambdaHandler)
  
   return state_machine
  }

  The type TaskFn is an extension of the spec to tell the Lambda which Task is calling it so it can route to the correct handler.

  LambdaHandler is the function that is called when the Task state CallLambda is reached:

  type Input struct {}
  
  type Result struct {
   Worked bool
  }
  
  func LambdaHandler(_ context.Context, _ *Input) (Result, error) {
    return Result{true}, nil
  }

  Handlers contain the logic. The path is controlled by the state-machine. State-machines can change the path based on the handlers output, but a handler cannot decide what state to jump to.

  Testing

  With Step a state-machine can be executed by calling StateMachine().Execute("{}"). This sends {} as an input into the machine and returns:

  1. The final output.
  2. The “path” of the states that were visited.
  3. Errors encountered by the process.

  This is used by tests:

  func Test_Machine(t *testing.T) {
   exec, err := StateMachine().Execute("{}")
   assert.NoError(t, err)
  
   assert.Equal(t, `{"Worked": true}`, exec.OutputJSON)
   assert.Equal(t, []string{
    "CallLambda",
    "Worked?",
    "Success",
   }, exec.Path())
  }

  Fuzz tests are also very useful to help build reliable state-machines. The gofuzz library will randomly generate input to make sure no unhandled errors are returned:

  func Test_With_Fuzz(t *testing.T) {
   for i := 0; i < 50; i++ {
    var input Input
    fuzz.New().Fuzz(&input)
  
    _, err := StateMachine().Execute(input)
    if err != nil {
     assert.NotRegexp(t, "Panic", err.Error())
    }
    // Other assertions like final states
   }
  }

  Deploy

  The ultimate goal is to deploy the Step function and Lambda to AWS. For this we need an executable binary, let’s call it hello. hello executed without any arguments must start a Lambda with run.Lambda(StateMachine()). hello json should print the state-machine with run.JSON(StateMachine()).

  The step binary can bootstrap (directly upload) hello to AWS. To install step:

  go get github.com/coinbase/step
  cd $GOPATH/src/github.com/coinbase/step 
  go build && go install

  Then build and bootstrap hello:

  # Build your code for the Lambdas linux environment
  GOOS=linux go build -o lambda
  zip lambda.zip lambda
  
  # export AWS creds using https://github.com/coinbase/assume-role
  assume-role account user
  
  # Use step to upload your code and state-machine to AWS
  step bootstrap \
    -lambda "hello-lambda" \
    -step "hello-step-function" \
    -states "$(hello json)"

  Step does not create the Lambda/IAM/Step function resources, these must be created first with a tool like terraform or geoengineer.

  Practices

  Here are a few good practices to follow using Step:

  1. Handle All Errors: Every TaskFn should have a catch for States.ALL errors. This will ensure the state-machine ends in a proper state.
  2. Fail Quickly: The faster a state-machine fails the less cleanup is needed. Fail if unknown JSON parameters are sent, if referenced resources don’t exist, or if other pre-conditions are not met.
  3. Fuzz Input: As described above, using the gofuzz can save you a lot of time as it highlights errors caused by invalid input.
  4. Comment: use the Comment attribute on states. The ultimate goal is to be able to fully understand the state-machine without looking at the code.
  5. Design defensively: Step functions should behave predictably, especially when failing. Alert if a Step function execution finishes in an unexpected state.

  Deployers and Bifrost

  

  While making deployers as Step functions, a set of conventions emerged which I am calling Bifrost. It is named after the mythical bridge because taking a bridge is easier (and safer) than swimming.

  Deployers, at their core, productionize developed assets. For example, starting a server, pushing code to a Lambda, or uploading a new version of a package or container. Given this is the step in the development process that shows your hard work to the world, it should be very reliable.

  Bifrost helps to build reliable deployers. By grouping together common concepts, a deployer’s code can focus on its core functionality.

  The core of all deployers is the bifrost.Release struct:

  type Release struct {
   AwsAccountID *string `json:"aws_account_id,omitempty"`
   AwsRegion    *string `json:"aws_region,omitempty"`
  
   ReleaseSHA256 string `json:"-"`
  
   UUID      *string `json:"uuid,omitempty"`
   ReleaseID *string `json:"release_id,omitempty"`
  
   ProjectName *string `json:"project_name,omitempty"`
   ConfigName  *string `json:"config_name,omitempty"`
   Bucket      *string `json:"bucket,omitempty"`
  
   CreatedAt *time.Time `json:"created_at,omitempty"`
  
   Timeout *int `json:"timeout,omitempty"`
  
   Error   *ReleaseError `json:"error,omitempty"`
   Success *bool         `json:"success,omitempty"`
  }

  To extend the release:

  type DeployerRelease struct {
   bifrost.Release
   ... // The attributes for your release
  } 

  This model stores information needed to deploy, e.g. the list of services, paths to assets, SHA’s for validation. The release is:

  1. The input and output for every state handler. This means each state has immediate access to all necessary information about the release.
  2. Not secure. The state history log is persisted forever, so be careful with what you put in it.
  3. Always validated. The Validate method on the release ensures everything is correct. This can be overridden, but should always call the original.

  The Machine

  How a deployers state-machine is organized will depend on the asset being deployed. However, the end state should always be either:

  1. "Success": { "Type": "Succeed" }: Deploy succeeded and everything is good.
  2. FailureClean": { "Type": "Fail"}: Failed to deploy, but successfully cleaned up so a retry can be attempted.
  3. "FailureDirty": { "Type": "Fail" }: Something went really bad, and you should alert someone to have a look.

  This means that a Step execution can fail in a Clean expected way, or a very bad and Dirty way. If a state-machine execution ends in a FailureDirty state (or any state not Success or FailureClean) then someone needs to be alerted.

  The state-machines TaskFn handlers should be thin with fat models. Handlers should be very obvious in their implementation and push the complexities to the Release model (which as stated above is the input and output of each handler). The goal is to make it easy to understand the impact a handler will have on a state-machine.

  The first handler in your state-machine should look like this:

  func Validate(awsc aws.Clients) DeployHandler {
   return func(ctx context.Context, release *models.Release) (*models.Release, error) {
    // Assign the release its SHA before anything alters it
    release.ReleaseSHA256 = to.SHA256Struct(release)
  
    // Extracts the region and account the Lambda is running in
    // This is used to set defaults for release attributes 
    region, account := to.AwsRegionAccountFromContext(ctx)
    release.SetDefaults(region, account, "coinbase-odin-")
     
    if err := release.Validate(awsc.S3(nil, nil, nil)); err != nil {
     return nil, &errors.BadReleaseError{err.Error()}
    }
  
    return release, nil
   }
  }

  This function returns a handler that:

  1. Calculates the input release’s SHA.
  2. Sets the defaults of the release, including Region, Account and Bucket.
  3. Validates the input release SHA against one uploaded to S3.

  The reason this function returns a handler is so that the aws.Clients struct is persisted across calls. aws.Clients manages AWS clients where awsc.S3Client(nil, nil, nil) creates a S3 Client without assuming a role. This pattern is further described here.

  It is neither secure nor practical to put all information into the release. For this and other functions we use S3. Each release has a bucket where:

  1. /<account_id>/<project_name>/<config_name> is the root dir release.RootDir().
  2. /<root_dir>/<release_id> is the release dir release.ReleaseDir().

  These directories are useful as an audit trail, sending signals like Halt to the step function or release instances, and asset storage for things like Lambda zip files.

  Bifrost Example Project

  To assist in building Bifrost deployers we built a “paved path” archetypal implementation that is a basic EC2 deployer. Structure like:

  ./
  ├── .circleci/ # example CI setup
  ├── aws/
  │   ├── ec2/ # example EC2 client
  │   ├── mocks/ # mock AWS clients
  │   └── aws.go # setup for multi-account AWS clients
  ├── client/
  │   └── client.go # example client code
  ├── deployer/
  │   ├── fuzz_test.go # fuzz test example
  │   ├── integration_test.go # tests for the Deployer
  │   ├── machine.go # state-machine definition
  │   ├── handlers.go # handler functions for tasks
  │   └── release.go # bifrost release struct
  ├── releases/
  │   └── release.json # example release
  ├── scripts/
  │   └── bootstrap_depolyer # bootstraping script
  ├── bifrost.go # executable code
  ├── Gopkg.toml # Go dependencies
  └── Dockerfile # Build bifrost for deploy

  To use this to start building your own deployer run:

  export ORG=<your-org>
  export DEPLOYER=<your_deployer>
  
  git clone git@github.com:coinbase/bifrost.git $DEPLOYER
  cd $DEPLOYER
  
  scripts/rename

  This will correctly rename the folder and references in the files to your deployer creating an easy starting place.

  The deployers state-machine looks like:

  

  It validates the input, locks the release, validates resources exist, deploys, waits a bit, checks if the deploy is healthy, then succeeds if healthy, fails if an error, or waits to retry and check later. Although the exact details of this deployer are not obvious, the overall flow of the state-machine is understandable.

  Odin

  Odin deploys 12 Factor applications into Auto-Scaling groups. To demonstrate how Bifrost’s conventions impact Odin’s implementation, let’s look at how Odin works.

  Odin’s Release looks like:

  type Release struct {
   bifrost.Release
  
   Services map[string]*Service `json:"services,omitempty"`
    
   userdata       *string // Not serialized
   UserDataSHA256 *string `json:"user_data_sha256,omitempty"`
   
   Healthy *bool `json:"healthy,omitempty"`
  
   ... // ignored LifecycleHooks, Subnets, Image
  }

  This Release struct at the center of Odin contains:

  1. The list of services to be deployed.
  2. userdata that might be sensitive so is not persisted, instead is uploaded to S3 and validated against a SHA UserDataSHA256.
  3. A Healthy check to see if all its services are also healthy.

  Odin’s state-machine looks like:

  

  The “Happy path” is Validate, Lock, ValidateResources, Deploy, CheckHealthy, Healthy?, CleanUpSuccess, Success. As seen in the diagram at any point an error might occur and the state will retry, or catch the error and clean up. This is very similar to the Bifrost example with a few extra paths to recover from failure.

  Bifrost Going Forward

  The goal of this post was to give an introduction to Step, Step functions, and how to build a deployer with Bifrost. Our goal is to automate as many different deployers as we can to reduce toil, increase security and make processes easier to understand.

  For more discussion on the above topics see Baking Bread with Step, Open sourcing Odin, and Hitchhiker’s Guide to AWS Step Functions.

  Unless otherwise indicated, all images provided herein are by Coinbase.

  This website may contain links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.

  

  ---

  AWS Step Functions, State Machines, Bifrost, and Building Deployers was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

  Read more on Coinbase
• 

  View all news of Coinbase
  
  Posted on November 16, 2018

  A brand new look for Coinbase Wallet

  

  We’re excited to present a fresh new look for the easiest and most trusted crypto wallet.

  We’ve been talking to you, our users, and compiled a list of the features and improvements you want the most.

  With this release, you can now view the value of your coin portfolio in your local fiat currency. You can also check the fiat values for individual tokens whenever available.

  And now, all the ERC20 tokens you own show up automatically — no more manually adding custom tokens.

  

  We’ve also created a beautiful new gallery for your collectibles, and integrated with OpenSea and RareBits to support hundreds of collectibles. Now you can show off your collectibles from right inside your wallet.

  

  And we’ve made a series of other changes under the hood for improved stability, security, and better gas price estimation.

  If you use an iPhone, your app should already have updated to the new look. Wallet users on Android phones will see the update roll out over the next few days.

  We hope you enjoy using the new, updated Coinbase Wallet. Your feedback helps us make Wallet better for everyone. You can now reach us at wallet.support@coinbase.com. Please reach out with feedback or if you ever need some troubleshooting.

  

  ---

  A brand new look for Coinbase Wallet was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

  Read more on Coinbase
• 

  View all news of Coinbase
  
  Posted on November 14, 2018

  What to Expect During the Bitcoin Cash Hard Fork

  Updated: What to Expect During the Bitcoin Cash Hard Fork

  

  Update as of Tuesday, November 20, 2018

  Since the Bitcoin Cash fork on November 15, 2018, Coinbase has been closely monitoring the BCH network. We have observed consensus in the community that the BCH ABC chain will retain the designation of Bitcoin Cash (BCH). Coinbase will also adopt this designation for BCH. Coinbase has made this decision based on a number of factors including the fact that ABC has a higher hashrate and a longer proof-of-work chain.

  Coinbase is now prepared to resume limited trading in BCH. For Coinbase Pro and Prime, we will turn on trading of BCH in the next 2 hours. Sends and receives will remain offline until we can confirm that they are safe to re-enable, including a prolonged absence of chain reorganizations. We expect that to occur within the next week.

  For Coinbase.com and the iOS and Android apps, we will continue to evaluate the safety of the network before re-enabling buys, sells, sends, and receives. We expect that to occur within the next week. We will resume all BCH services when it is safe for our customers.

  We will continue to evaluate the safety of the BCH SV chain. Our current intention is to support withdrawal services for the BCH SV chain so that our customers may withdraw funds at a future date. We anticipate this development work will take at least a few weeks, but may take longer. We will communicate directly with customers that hold BCH and notify them when we complete this work and they can withdraw funds from the BCH SV chain.

  If network conditions significantly change or become unsafe at any point, Coinbase may revise these plans.

  November 13, 2018

  Twice a year, the Bitcoin Cash (BCH) network hard forks as part of scheduled protocol upgrades. The next BCH hard fork is scheduled for this Thursday, Nov 15, 2018.

  Unlike previous BCH hard forks, there is a competing proposal that is not compatible with the published roadmap. Coinbase will monitor the hard fork process and work to minimize customer disruption until the network meets Coinbase security standards.

  Coinbase previously announced that we would pause sends and receives on the BCH wallets at Coinbase.com, in our iOS and Android apps, and at Coinbase Pro, Prime, and Custody beginning at 8:00AM PST on Thursday, November 15 (approximately 1 hour before the fork).

  Due to recent developments, we have now determined that it will be necessary to also pause all buys, sells, and trading of BCH starting at 8:00AM PST on Thursday on Coinbase.com, in the iOS and Android apps, and on Coinbase Pro and Prime. Accordingly, during the time of the pause, you will not be able to sell or remove your BCH from Coinbase. If you wish to have access to your BCH during the pause, you will need to remove it from the Coinbase platform prior.

  Please note that Coinbase has no control over the timing of the fork, and therefore cannot provide specific timing for the items below. We will monitor the fork and communicate with our customers promptly and frequently regarding the status of access to BCH. During the fork, we will take the following steps.

  Starting at 8:00AM PST on Thursday, November 15, Coinbase will:

  1. Pause sends (withdrawals) and receives (deposits), as well as buys, sells, and trading of BCH;
  2. Take a snapshot of existing BCH balances;
  3. Monitor the fork for network consensus;
  4. When network conditions stabilize, we will notify customers of the expected date and time to re-enable buys, sells, sends, receives, and trading of BCH
  5. Clear order books and re-enable buys, sells, sends, receives, and trading of BCH; and
  6. If another viable chain exists, customers will have the ability to withdraw funds at a future date. We anticipate this will take at least a few weeks, but may take longer.

  Questions & Answers

  When will Coinbase pause sends and receives of BCH?
  We will pause sends and receives and all trading on the BCH wallets at Coinbase.com, in our iOS and Android apps, and at Coinbase Pro, Prime, and Custody beginning at 8:00AM PST on Thursday, November 15 (approximately 1 hour before the fork). Please be sure all BCH sends, receives, and trading are completed prior to that time. During the pause, your BCH will remain safely at Coinbase. As it may take several hours for a transaction to be processed, we recommend initiating any sends, receives or trading no later than 3:00 am PST.

  When will Coinbase take a snapshot of BCH balances?
  We will take a snapshot of existing BCH balances on the platform immediately after sends, receives, buys, sells, and trading of BCH are paused at 8:00am PST on Thursday, November 15.

  How long will trading be paused, and what happens when you turn it back on?
  We cannot predict the duration of this process. When the upgrade is complete, we will evaluate the security and viability of the network and take appropriate next steps, including re-enabling sends, receives, and trading. We will update our customers throughout the upgrade process and about the outcome of the fork once the network reaches consensus.

  The order book for BCH on Coinbase Pro and Coinbase Prime will be cleared after trading is paused so Coinbase Pro and Prime users will need to submit any new orders after trading is re-enabled.

  When will Coinbase re-enable sends and receives of BCH?
  We cannot predict the duration of this process. When the upgrade is complete, we will evaluate the security and viability of the network and take appropriate next steps, including re-enabling sends, receives, and trading. We will update our customers throughout the upgrade process and about the outcome of the fork once the network reaches consensus.

  Will there be more than one BCH chain?
  We cannot predict if there will be one or two viable chains after the fork. We will monitor the network closely, and will communicate with our customers. as to when we will re-enable sends, receives, and trading of BCH.

  What will happen if there are two viable chains?
  In the event that multiple viable chains persist after the fork, we will strive to ensure that customers have access to their funds on each chain. Coinbase will initially resume customer access to BCH and then Coinbase will work to provide withdrawal access to funds on the second chain at a future date. We anticipate this will take at least a few weeks, but may take longer.

  If I leave my funds on Coinbase during the fork, will they be safe?
  Funds stored on the Coinbase platform will remain safe throughout the fork. Our primary goal during this fork is to protect customer funds. Customers who leave BCH on Coinbase during the fork will be able to access it after the network has reached sufficient consensus as to the outcome of the fork, and we have determined that the network is secure, at which time we will re-enable sends, receives, and trading of BCH.

  

  ---

  What to Expect During the Bitcoin Cash Hard Fork was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

  Read more on Coinbase
• 

  View all news of Coinbase
  
  Posted on November 8, 2018

  Buy and Sell BAT on Coinbase

  

  Starting today, Coinbase supports the Basic Attention Token (BAT) at Coinbase.com and in the Coinbase Android and iOS apps. Coinbase customers can now buy, sell, send, receive, or store BAT, along with Bitcoin, Bitcoin Cash, Ethereum, Ethereum Classic, Litecoin, ZRX and USDC.

  BAT will be available for customers in most jurisdictions, but will not initially be available for residents of the state of New York.

  One of the most common requests we hear from customers is to be able to buy more assets on Coinbase. In September we announced a new process for listing assets, designed in part to accelerate asset addition. We are also investing in new tools to help people understand and explore cryptocurrencies. We launched informational asset pages (see BAT here), as well as a new section of the Coinbase website to answer common questions about crypto.

  You can sign up for a Coinbase account here to buy and sell BAT today.

  

  ---

  Buy and Sell BAT on Coinbase was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

  Read more on Coinbase
• 

  View all news of Coinbase
  
  Posted on November 8, 2018

  Wrapping up Devcon4

  

  Last week, more than 3,000 blockchain engineers, thinkers and investors descended on the city of Prague for the 4th Annual Ethereum Developers Conference. The ethos of an open financial system was on full display as everyone came together to ideate on and solve some of the toughest challenges facing Ethereum and blockchains today. Here’s a quick look at some of the highlights from our week.

  DeFi Summit
  We kicked off the week at DeFi Summit, the second event in a new series hosted by a number of startups building the new decentralized financial infrastructure. Alex Kern of Coinbase’s identity team and Ron Bernstein of Paradex gave a presentation called, “The Future of Permissioned Relays”. They talked about how relays could incorporate certain KYC elements and enable the trading of permissioned assets like securities. The presentation included a cool demo that showcased how Paradex, a relay product, could one day make use of this utility.

  

  We also hosted a conversation called, “How Stablecoins Unlock an Open Financial System,” led by Emre Tekisalp, Business Development Lead on Coinbase Wallet. Stablecoins, like Coinbase’s own USDC, are essentially programmable money that is easy to send to friends, use in applications, and store on your device without needing a bank account, while also protecting users from the volatility we see in cryptocurrencies such as Bitcoin.

  They’re becoming a critical piece of the decentralized financial system that we believe will open the door to better tools, access and user experiences. We had a great discussion with attendees on what we can focus on in the short term to get stablecoin-friendly products into the hands of millions of people.

  

  We wrapped up DeFi with a panel on security tokens where Ron Bernstein represented Paradex and shared thoughts on why security tokens and decentralized trading tech stack is a more efficient way to trade securities and, more importantly, what some of the key pieces we’re working on to make this a reality.

  

  Devcon4

  Devcon is the main annual conference for developers building the Ethereum blockchain and applications on top of it. Over four days, attendees had the opportunity to learn from leading figures in the space, discuss technical challenges, collaborate on new creative solutions, and meet new folks. Everyone in attendance seemed to agree that this year’s event was a huge success, both in terms of content, organization and production value. Huge kudos to the Ethereum Foundation and all volunteers for putting on such a successful event for the crypto industry!

  Devcon kicked off with Day 0 and a UX Workshop called, “Designing for Humans,” hosted by Coinbase’s Director of Design, Connie Yang and IDEO CoLab’s Tara Tan. It was incredibly energizing to see so many people thinking about how sound design is necessary to make highly technical applications useable. It shows that we’re at the stage of the maturation cycle for crypto where developers want their products to be easy and intuitive to use. Perhaps a leading indicator for a larger number of widely used products coming in a few months, it was great to see UX become an official track all throughout the conference.

  

  The next day, Sid Coelho-Prabhu, Product Lead for Coinbase Wallet, gave a widely attended talk titled “Getting to a Million Dapp Users.” Decentralized apps (dapps) are recognized as one of the main ways in which crypto and blockchains will be used by millions of users, but we’re not quite there yet. He covered some of the specific challenges the industry needs to tackle in order to bring these tools to more users. He highlighted finding the right use case, usability of dapps, and increasing scalability as the three key challenges. He also talked about what we at Coinbase Wallet are working on to help with these issues and get the millions of users through the gateway.

  

  Our next talk was on how Coinbase safely handles detecting contract transfers on Ethereum for its millions of users everyday. Coinbase’s Jake Craige shared some of our learnings from the past years and best practices with the audience in a session called, “Smart Contracts: Approach with Caution.” Running such an operation at this scale truly leaves some battle scars and we’d like to make sure others learn from our mistakes and have a far easier job!

  

  We wrapped up the week with a panel titled, “Integrating Ethereum at Scale,” hosted by Coinbase’s Eric Scrivner and Jake Craige. Along with the other panelists, Morgan from ShapeShift and Ben Chan from BitGo, we covered the biggest challenges for companies running large scale operations and mitigations. It was a deeply engaging conversation for the panel and the audience.

  

  It was a blast to be at Devcon this year! The event served as another reminder that there are a lot of amazing teams and minds building in this space. Crypto may have a lot of big and hairy technical challenges ahead of it, but we have no doubt that the community that’s forming will tackle and solve them one-by-one.

  

  

  We hope to see everyone again next year. Thanks for coming by, saying hi, and creating an open financial system with us! If you’re as energized about this new financial future as we are, come help us build it. We have openings across the board, so be sure to check out our open positions.

  Unless otherwise indicated, all images provided herein are by Coinbase.

  This website may contain links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.

  

  ---

  Wrapping up Devcon4 was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

  Read more on Coinbase
• 

  View all news of Coinbase
  
  Posted on December 19, 2017

  Bitcoin Cash Trading Now Available on GDAX

  

  We’re happy to announce that Bitcoin Cash (BCH) is now listed and available for trading on GDAX.

  We made the decision to list BCH by considering such factors as customer interest, developer support, network security, market capitalization, trading volume, and our Digital Asset Framework. You can read more about Bitcoin Cash on our FAQ page.

  The following order books have been created and will remain in post-only mode until there is sufficient liquidity for trading:

  • BCH–BTC
  • BCH–USD
  • BCH–EUR

  Bitcoin Cash was created by a fork of the Bitcoin network on August 1st, 2017. All customers who held a bitcoin (BTC) balance on GDAX at the time of the fork have been credited an equal balance of Bitcoin Cash (BCH) in their GDAX account. Your BCH balance will reflect your BTC balance at the time of the Bitcoin Cash fork, which occurred on August 1, 2017 at 13:20 UTC (block #478559). You can read more about what a bitcoin fork is here and our previous update on Bitcoin Cash here.

  

  ---

  Bitcoin Cash Trading Now Available on GDAX was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

  Read more on Coinbase
• 

  View all news of Coinbase
  
  Posted on December 8, 2017

  Please invest responsibly — an important message from the GDAX team

  

  Please invest responsibly — an important message from the GDAX team

  We at GDAX couldn’t be more excited by the explosion of interest in digital currencies. The last few weeks has seen an unprecedented increase in the price of digital currencies. More people are engaging with our platform than ever and that bodes well for the future of the digital currency. At the same time, it does create extreme volatility and stress on our systems. We take this very seriously and wanted to share some important thoughts.

  We’re continuing to invest heavily to scale our platform

  Over the course of this year we have invested significant resources to increase trading capacity on our platform and maintain availability of our service. We have increased the size of our support team by 640% and launched phone support in September. We have also invested heavily in our infrastructure and have increased the number of transactions we are processing during peak hours by over 40x.

  There may be downtime which can impact your ability to trade

  Despite the sizable and ongoing increases in our technical infrastructure and engineering staff, we wanted to remind customers that access to GDAX services may become degraded or unavailable during times of significant volatility or volume. This could result in the inability to trade for periods of time. Limit and stop-loss orders may not execute in periods of high volatility if there is not sufficient liquidity on the other side. Despite ongoing increases in our support capacity, our customer support response times may be delayed, especially for requests that do not involve immediate risks to customer account security. You can read more in our GDAX User Agreement.

  Be an educated investor

  We also wanted to remind customers of some of the risks associated with trading digital currency. Digital currencies are volatile and the prices can go up and down. Due to the rapidly changing price of digital currencies, some customers may not have withdrawal limits that are sufficient relative to the value of total digital currency they are storing on GDAX.

  As a proactive measure, we encourage customers to check the following items on their accounts:

  1. Ensure your email address is properly receiving all communications and notifications from GDAX. To learn more about ensuring email delivery, please refer to this support article.
  2. Ensure your two-factor authentication is updated and functional. If you have recently switched mobile devices, your two-factor authentication needs to be properly migrated to the new device. In addition, please migrate from SMS two factor to Google Authenticator to enhance the security on your account, if you have not already done so. To learn more about two-factor authentication, please refer to this FAQ.
  3. Familiarize yourself with your trading limits. They can be found here.
  4. Expect payments to take the maximum number of days indicated when making a deposit or withdrawal.

  Stay up to date

  We will continue to update customers on our website, our status page, via email, on our blog and on Twitter.

  We will keep you informed

  We are committed to safety, security and transparency. We are working tirelessly to provide the best service and support but we can’t promise perfection during the periods of extraordinary demand. We will continue to do our best to keep our customers informed.

  

  ---

  Please invest responsibly — an important message from the GDAX team was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

  Read more on Coinbase
• 

  View all news of Coinbase
  
  Posted on October 24, 2017

  Clarification on the upcoming Segwit2x Fork

  

  In our prior blog post we indicated that at the time of the fork, the existing chain will be called Bitcoin (BTC) and the Segwit2x fork will be called Bitcoin2x (B2X).

  Since then, some customers have asked us to clarify what will happen after the fork. We are going to call the chain with the most accumulated difficulty Bitcoin.

  We will make a determination on this change once we believe the forks are in a stable state. We may also consider other factors such as market cap and community support to determine stability.

  It’s important for us to maintain a neutral position in any fork. We believe that letting the market decide is the best way to ensure that Bitcoin remains a fair and open network.

  

  ---

  Clarification on the upcoming Segwit2x Fork was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

  Read more on Coinbase
• 

  View all news of Coinbase
  
  Posted on October 23, 2017

  Timeline and Support — Bitcoin Segwit2x and Bitcoin Gold

  Timeline and Support — Bitcoin Segwit2x and Bitcoin Gold

  

  We wanted to give customers another update on two upcoming Bitcoin forks — Bitcoin Segwit2x and Bitcoin Gold. You can read more about what a digital currency fork is here.

  We operate by the principle that our customers should benefit to the greatest extent possible from hard forks or other unexpected events. This is essential in our mission to make GDAX the most trusted and liquid digital asset exchange.

  Bitcoin Segwit2x

  The Bitcoin Segwit2x fork is projected to take place on November 16th and will temporarily result in two bitcoin blockchains. Following the fork, the current bitcoin blockchain will continue trading as Bitcoin (BTC) and the forked blockchain will trade as Bitcoin2x (B2X).

  All GDAX customers will be able to trade both Bitcoin (BTC) and Bitcoin2x (B2X) within 4 hours after the fork.

  Any customer with a Bitcoin (BTC) balance on GDAX at the time of the fork will be credited with an equal amount of the Bitcoin2x (B2X). No action is required — we will automatically credit your account.

  For more information about Bitcoin2x please see our FAQ page.

  Bitcoin2x Timeline

  • Approximately 24 hours pre-fork: GDAX will pause all BTC deposits and withdrawals. ETH and LTC deposits and withdrawals will not be impacted
  • Approximately 4 hours pre-fork: GDAX will pause trading on all BTC order books. ETH and LTC trading will not be impacted
  • Fork (block 494,784): A snapshot of all BTC balances will be taken at Block 494,784. All GDAX customers with a BTC balance at the time of the snapshot will be credited an equal amount of B2X.
  • Within 4 hours post fork: GDAX will re-enable trading on all BTC order books as well as trading on 3 new order books: B2X-BTC, B2X-USD, and B2X-EUR.
  • Approximately 24–48 hours post fork: Once we have ensured that the blockchains are stable, GDAX will re-enable deposits and withdrawals on both the BTC and B2X blockchains. Please be careful when depositing or withdrawing funds as some wallets and bitcoin services may refer to the two blockchains differently.

  We will update customers closer to the date of the fork with more exact timing.

  Bitcoin Gold

  The Bitcoin Gold fork is projected to take place on October 23. Information about this fork has been limited and there are concerns about its security and stability. As a result, we do not believe it is safe to allow support for Bitcoin Gold at this time. If the blockchain proves to be secure and valuable, GDAX may choose to support it and at that point credit your account with an amount of Bitcoin Gold equal to your Bitcoin (BTC) balance at the time of the fork.

  You can read more about Bitcoin Gold at our FAQ page.

  Over the coming weeks, we will keep you updated on this event through our blog, status page, and twitter.

  

  ---

  Timeline and Support — Bitcoin Segwit2x and Bitcoin Gold was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

  Read more on Coinbase

• Suggest|
• Articles|
• About Us|
• Links