docs: Fix link

two1/bitrequests/docs/README.md

@@ -4,7 +4,7 @@
 
 BitRequests wraps the python HTTP [Requests](http://docs.python-requests.org/en/latest/) library, adding a simple API for users to pay for resources. It enables a client (also referred to as a customer) to pay a server (also referred to as a merchant) for a resource.
 
-![402 flow](https://github.com/21dotco/two1/blob/devel/two1/bitrequests/docs/bitrequests.png)
+![402 flow](https://github.com/21dotco/two1/blob/master/two1/bitrequests/docs/bitrequests.png)
 
 The 402 payment-resource exchange adds an intermediary negotiation step between a standard HTTP request/response session. The following is how the transaction would occur for a `GET` request.
 

two1/bitserv/README.md

@@ -2,12 +2,12 @@
 
 ## Overview
 
-The BitServ library adds a simple API for servers to create payable resources in both Flask and Django frameworks. It enables a server (also referred to as a merchant) to receive payment from a client (also referred to as a customer) for a resource. See the [bitrequests readme](https://github.com/21dotco/two1/blob/devel/two1/bitrequests/docs/README.md) for more information on the `402 payment-resource exchange`.
+The BitServ library adds a simple API for servers to create payable resources in both Flask and Django frameworks. It enables a server (also referred to as a merchant) to receive payment from a client (also referred to as a customer) for a resource. See the [bitrequests readme](https://github.com/21dotco/two1/blob/master/two1/bitrequests/docs/README.md) for more information on the `402 payment-resource exchange`.
 
 
 ## Payment Methods
 
-The bitserv library provides a base set of [payment_methods](https://github.com/21dotco/two1/blob/devel/two1/bitserv/payment_methods.py) that framework-specific decorators can use to accept different payment types (e.g. `OnChain`, `Payment Channel` and `BitTransfer` types). Payment methods should implement the following methods:
+The bitserv library provides a base set of [payment_methods](https://github.com/21dotco/two1/blob/master/two1/bitserv/payment_methods.py) that framework-specific decorators can use to accept different payment types (e.g. `OnChain`, `Payment Channel` and `BitTransfer` types). Payment methods should implement the following methods:
 
   * **get_402_headers()** provides a list of headers that the *server* returns to the client in the initial `402 PAYMENT REQUIRED` response.
 
@@ -100,9 +100,9 @@ python manage.py migrate
 
 ## Payment Server
 
-[payment_server.py](https://github.com/21dotco/two1/blob/devel/two1/bitserv/payment_server.py) is concerned with managing the server side of payment channels. The `PaymentServer` object is generic enough to be used by various communication protocols, though it is presently only implemented over HTTP REST as a core part of the `bitserv` library.
+[payment_server.py](https://github.com/21dotco/two1/blob/master/two1/bitserv/payment_server.py) is concerned with managing the server side of payment channels. The `PaymentServer` object is generic enough to be used by various communication protocols, though it is presently only implemented over HTTP REST as a core part of the `bitserv` library.
 
-The `PaymentServer` - and to some extent, each `PaymentBase` method - relies on state being maintained by the application. It consumes the [models.py](https://github.com/21dotco/two1/blob/devel/two1/bitserv/models.py) API in order to store and retrieve channel state. The default database implementation uses the `sqlite3` standard library to communicate with an SQLite database. The django-specific database implementation provides an adapter that hooks into the django ORM to allow payment methods to keep their data with the rest of the django application.
+The `PaymentServer` - and to some extent, each `PaymentBase` method - relies on state being maintained by the application. It consumes the [models.py](https://github.com/21dotco/two1/blob/master/two1/bitserv/models.py) API in order to store and retrieve channel state. The default database implementation uses the `sqlite3` standard library to communicate with an SQLite database. The django-specific database implementation provides an adapter that hooks into the django ORM to allow payment methods to keep their data with the rest of the django application.
 
 The `PaymentServer` also uses a custom `wallet.py` wrapper to provide added transaction-building functionality. You can set up a barebones payment server by passing it a two1 wallet instance
 

two1/channels/docs/README.md

@@ -6,7 +6,7 @@ The payment channel protocol allows for fast, high-volume payments to occur from
 
 Payment channels consist of negotiating an `open` stage, an active `ready` stage where many payments can be made, and a `closing` stage where a final transaction is broadcast.
 
-![Payment Channels Protocol](https://github.com/21dotco/two1/blob/devel/two1/channels/docs/PCs.png)
+![Payment Channels Protocol](https://github.com/21dotco/two1/blob/master/two1/channels/docs/PCs.png)
 
 #### Channel open
 
@@ -120,15 +120,15 @@ Payment channels consist of negotiating an `open` stage, an active `ready` stage
 
 ## Architecture
 
-Each payment channel is modeled by a state machine `PaymentChannelStateMachine` class ([two1/channels/statemachine.py](https://github.com/21dotco/two1/blob/devel/two1/channels/statemachine.py)), which provides an interface to manipulating all of the client-side channel state. This state is stored in a `PaymentChannelModel` ([two1/channels/statemachine.py](https://github.com/21dotco/two1/blob/devel/two1/channels/statemachine.py)) object, which can be stored and restored to and from the channels database. The `PaymentChannelStateMachine` class provides the low-level transition functions on the channel state and is responsible for creating and returning the underlying refund, deposit, and payment transactions. It uses a `WalletWrapper` class ([two1/channels/wallet.py](https://github.com/21dotco/two1/blob/devel/two1/channels/wallet.py)) to sign transactions, but otherwise has no interaction with the outside world.
+Each payment channel is modeled by a state machine `PaymentChannelStateMachine` class ([two1/channels/statemachine.py](https://github.com/21dotco/two1/blob/master/two1/channels/statemachine.py)), which provides an interface to manipulating all of the client-side channel state. This state is stored in a `PaymentChannelModel` ([two1/channels/statemachine.py](https://github.com/21dotco/two1/blob/master/two1/channels/statemachine.py)) object, which can be stored and restored to and from the channels database. The `PaymentChannelStateMachine` class provides the low-level transition functions on the channel state and is responsible for creating and returning the underlying refund, deposit, and payment transactions. It uses a `WalletWrapper` class ([two1/channels/wallet.py](https://github.com/21dotco/two1/blob/master/two1/channels/wallet.py)) to sign transactions, but otherwise has no interaction with the outside world.
 
-The `PaymentChannel` class ([two1/channels/paymentchannel.py](https://github.com/21dotco/two1/blob/devel/two1/channels/paymentchannel.py])) provides an internal API (open, pay, sync, close, and properties) to a payment channel, operates transitions on the state machine, and is the the glue between state machine and the outside world -- the database [two1/channels/database.py](https://github.com/21dotco/two1/blob/devel/two1/channels/database.py), the blockchain [two1/channels/blockchain.py](https://github.com/21dotco/two1/blob/devel/two1/channels/blockchain.py), and the payment channel server [two1/channels/server.py](https://github.com/21dotco/two1/blob/devel/two1/channels/server.py). Its logic is described in [two1/channels/docs/channel-logic.txt](https://github.com/21dotco/two1/blob/devel/two1/channels/docs/channel-logic.txt).
+The `PaymentChannel` class ([two1/channels/paymentchannel.py](https://github.com/21dotco/two1/blob/master/two1/channels/paymentchannel.py])) provides an internal API (open, pay, sync, close, and properties) to a payment channel, operates transitions on the state machine, and is the the glue between state machine and the outside world -- the database [two1/channels/database.py](https://github.com/21dotco/two1/blob/master/two1/channels/database.py), the blockchain [two1/channels/blockchain.py](https://github.com/21dotco/two1/blob/master/two1/channels/blockchain.py), and the payment channel server [two1/channels/server.py](https://github.com/21dotco/two1/blob/master/two1/channels/server.py). Its logic is described in [two1/channels/docs/channel-logic.txt](https://github.com/21dotco/two1/blob/master/two1/channels/docs/channel-logic.txt).
 
-The `PaymentChannelClient` class ([two1/channels/paymentchannelclient.py](https://github.com/21dotco/two1/blob/devel/two1/channels/paymentchannelclient.py])) provides the top-level API for applications to `open()`, `pay()`, `sync()`, `status()`, `close()`, and `list()` payment channels by  URL.
+The `PaymentChannelClient` class ([two1/channels/paymentchannelclient.py](https://github.com/21dotco/two1/blob/master/two1/channels/paymentchannelclient.py])) provides the top-level API for applications to `open()`, `pay()`, `sync()`, `status()`, `close()`, and `list()` payment channels by  URL.
 
-Finally, the `channels` cli is click-based cli implemented in [two1/channels/cli.py](https://github.com/21dotco/two1/blob/devel/two1/channels/cli.py).
+Finally, the `channels` cli is click-based cli implemented in [two1/channels/cli.py](https://github.com/21dotco/two1/blob/master/two1/channels/cli.py).
 
-The `ChannelRequests` class ([two1/bitrequests/bitrequests.py](https://github.com/21dotco/two1/blob/devel/two1/bitrequests/bitrequests.py]) takes in a wallet and creates a `PaymentChannelClient` in its constructor. It uses the `PaymentChannelClient` and `PaymentChannel` APIs to lookup and operate payment channels, subject to an overridable hard-coded policy (initial deposit amount = 100000, expiration time = 86400 seconds, and close out amount = 1000).
+The `ChannelRequests` class ([two1/bitrequests/bitrequests.py](https://github.com/21dotco/two1/blob/master/two1/bitrequests/bitrequests.py]) takes in a wallet and creates a `PaymentChannelClient` in its constructor. It uses the `PaymentChannelClient` and `PaymentChannel` APIs to lookup and operate payment channels, subject to an overridable hard-coded policy (initial deposit amount = 100000, expiration time = 86400 seconds, and close out amount = 1000).
 
 
 ## Developer Testing