Cleaned up README.MD and changelogs

.sfreleaser

@@ -0,0 +1,6 @@
+global:
+  binary: firebtc
+  language: golang
+  variant: application
+release:
+  goreleaser-docker-image: goreleaser/goreleaser-cross:v1.21.1

CHANGELOG.md

@@ -0,0 +1,12 @@
+# Change log
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this
+project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). See [MAINTAINERS.md](./MAINTAINERS.md)
+for instructions to keep up to date.
+
+## v1.0.0-rc.1
+
+### StreamingFast Firehose Bitcoin implementation
+
+* Bitcoin blocks are fully compatible with the RPC blocks
+* Bitcoin Block contains all transaction data, including `vins` and `vouts`*

CONTRIBUTING.md

@@ -0,0 +1,127 @@
+# Contributing
+
+Interested in contributing? That's awesome!
+
+## Reporting An Issue
+
+If you're about to raise an issue because you think you've found a problem, or you'd like to make a request for a new feature in the codebase, or any other reason... please read this first.
+
+The GitHub issue tracker is the preferred channel for [bug reports](#bug-reports), [feature requests](#feature-requests), and [submitting pull requests](#submitting-pull-requests), but please respect the following restrictions:
+
+* Please **search for existing issues**. Help us keep duplicate issues to a minimum by checking to see if someone has already reported your problem or requested your idea.
+
+* Please **be civil**. Keep the discussion on topic and respect the opinions of others. See also our [Contributor Code of Conduct](#conduct).
+
+### Bug Reports
+
+A bug is a _demonstrable problem_ that is caused by the code in the repository. Good bug reports are extremely helpful - thank you!
+
+Guidelines for bug reports:
+
+1. **Use the GitHub issue search** — check if the issue has already been reported.
+1. **Check if the issue has been fixed** — closed issues in the current milestone or try to reproduce it using the latest `develop` branch.
+
+A good bug report shouldn't leave others needing to chase you up for more information. Be sure to include the details of your environment and relevant tests that demonstrate the failure.
+
+### Feature Requests
+
+Feature requests are welcome. Before you submit one be sure to have:
+
+1. **Use the GitHub search** and check the feature hasn't already been requested.
+1. Take a moment to think about whether your idea fits with the scope and aims of the project.
+1. Remember, it's up to *you* to make a strong case to convince the project's leaders of the merits of this feature. Please provide as much detail and context as possible, this means explaining the use case and why it is likely to be common.
+
+### Change Requests
+
+Change requests cover both architectural and functional changes. If you have an idea for a new or different dependency, a refactor, or an improvement to a feature, etc - please be sure to:
+
+1. **Use the GitHub search** and check someone else didn't get there first
+1. Take a moment to think about the best way to make a case for, and explain what you're thinking. Are you sure this shouldn't really be
+   a [bug report](#bug-reports) or a [feature request](#feature-requests)?  Is it really one idea or is it many? What's the context? What problem are you solving? Why is what you are suggesting better than what's already there?
+
+## Working on the Code
+
+Code contributions are welcome and encouraged! Please follow these guidelines when submitting code:
+
+### Branching Conventions
+
+In all repositories:
+
+- **develop** is the development branch. All work on the next release happens here so you should generally branch off `develop`. Do **not** use this branch for a production site.
+- **master** contains the latest releases. This branch may be used in production. Do **not** use this branch to work on the source code.
+- **feature/something** contains feature branches where collaboration can exist, and is sync (rebased or merges) with `develop` from time to time.
+- **hotfix/something** for hotfixes.
+
+This generally reflects the seminal _git flow_.
+
+### Submitting Pull Requests
+
+Pull requests are awesome. If you're looking to raise a PR for something which doesn't have an open issue, please think carefully about [raising an issue](#reporting-an-issue) which your PR can close, especially if you're fixing a bug. This makes it more likely that there will be enough information available for your PR to be properly tested and merged.
+
+### Testing and Quality Assurance
+
+Never underestimate just how useful quality assurance is. If you're looking to get involved with the code base and don't know where to start, checking out and testing a pull request is one of the most useful things you could do.
+
+Essentially, [check out the latest develop branch](#working-on-the-code), take it for a spin, and if you find anything odd, please follow the [bug report guidelines](#bug-reports) and let us know!
+
+## Code of Conduct
+
+While contributing, please be respectful and constructive, so that participation in our project is a positive experience for everyone.
+
+Examples of behavior that contributes to creating a positive environment include:
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+Examples of unacceptable behavior include:
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others’ private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Contributor License & Acknowledgments
+
+Whenever you make a contribution to this project, you license your contribution under the same terms as set out in [LICENSE](./LICENSE), and you represent and warrant that you have the right to license your contribution under those terms.  Whenever you make a contribution to this project, you also certify in the terms of the Developer’s Certificate of Origin set out below:
+
+```
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+1 Letterman Drive
+Suite D4700
+San Francisco, CA, 94129
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.
+```

CONVENTIONS.md

@@ -0,0 +1,19 @@
+# Coding conventions
+
+In general, this project adheres to all the standard Go conventions,
+and is constantly on the look to make sure we have a uniform and
+coherent codebase.
+
+Here are things that might be useful to clarify nonetheless:
+
+
+## Error management
+
+* All `fmt.Errorf()` ought to start with a lowercase letter, with `:`
+  separating elements, from broadest to most refined.
+
+## Logging
+
+* Logging is done through the `zap` library.  All developer-centric logs ought to start with a lowercase, and provide sufficient context to aid in debugging.
+* Assume systems log at `Info` level by default, enabling `Debug` when needed (at runtime through port :1065 <- logs, you read that l33t?).
+* Assume systems trigger some sort of alerting when `Warn` and `Error` level errors are triggered.

README.md

@@ -5,4 +5,23 @@
 # Firehose for Bitcoin
 
 [![reference](https://img.shields.io/badge/godoc-reference-5272B4.svg?style=flat-square)](https://pkg.go.dev/github.com/streamingfast/firehose-bitcoin)
-[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
+[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
+
+`firehose-bitcoin` simply contains the bitcoin protobuf native types and the bitcoin poller binary. All services (merger, relayer, firehose, substreams, etc..) are ran via the [`firehose-core`](https://github.com/streamingfast/firehose-core) binary  directly.
+
+## Contributing
+
+**Issues and PR in this repo related strictly to the Ethereum on StreamingFast.**
+
+Report any protocol-specific issues in their
+[respective repositories](https://github.com/streamingfast/streamingfast#protocols)
+
+**Please first refer to the general
+[StreamingFast contribution guide](https://github.com/streamingfast/streamingfast/blob/master/CONTRIBUTING.md)**,
+if you wish to contribute to this code base.
+
+This codebase uses unit tests extensively, please write and run tests.
+
+## License
+
+[Apache 2.0](LICENSE)