roles
roles copied to clipboard
bisq-network
Bitcoin Node Maintainer
This @bisq-network/btcnode-maintainers role is responsible for maintaining the shared configuration for @bisq-network's federation of @bitcoin nodes, as hard-coded in https://github.com/bisq-network/exchange/blob/master/core/src/main/java/io/bisq/core/btc/BitcoinNodes.java.
This role should maintain a shared bitcoin.conf file in this repository, and work with @bisq-network/btcnode-operators to make sure they run the same configuration there.
This role is responsible for responding in a timely fashion to GitHub issues added to this repository, questions asked in the #bisq-btcnode channel, and to ensure that monitoring notifications in #alerts get handled in a timely fashion.
Docs: none, other than the above Team: @bisq-network/btcnode-maintainers Primary owner: @sqrrm Secondary: @wiz
2018.06 report
Took over role as maintainer halfway through the month. Nothing to report on nodes.
@ManfredKarrer @cbeams Regarding maintaining the issue, is there a way for me to update the initial issue https://github.com/bisq-network/roles/issues/66#issue-287266942 to keep it relevant?
@sqrrm wrote:
Regarding maintaining the issue, is there a way for me to update the [issue description] to keep it relevant?
In short, yes, but it'll work a little differently than that. I'll have instructions for all role owners about this soon. Thanks.
@sqrrm, regarding keeping the description for this role (and the Tor Relay Operator role at #72) up to date, I mentioned above that I'd have instructions for all role owners on this soon, but what I'd actually like to do, if you're willing, is to have you try out the instructions first and provide feedback about it before I send out a broader request to have everyone do the same.
I'll provide a little context here, so that hopefully everything makes sense, but in the end, it should be a fairly simple task, one that will probably take 30 minutes or perhaps an hour for most roles.
First it's a good idea to read through the new Roles doc at https://docs.bisq.network/roles.html if you haven't already. It provides (hopefully) everything that contributors need to know about how roles work.
The relevant section of that doc that I want to focus on here is the Docs section at https://docs.bisq.network/roles.html#docs:
To follow those instructions for this role, you'd put together a pull request against the bisq-docs repository that adds a btcnode.adoc file. That file would include:
- an
Introductionsection that explains what the Bisq federation of Bitcoin Core nodes is for, how it helps protect user privacy, etc. - an
Infrastructuresection that mentions thebisq-btcnoderepository andbtcnodeslack channel. - a
Rolessection that details the Duties, Rights, GH Issue and GH Team for both the btcnode Maintainer and Operator roles. - if appropriate, a
Processessection that details any processes involved with btcnodes, e.g. upgrades.
The Proposals doc at https://docs.bisq.network/proposals.html provides an example for what such a doc should look like; please treat it as a template.
You'll also want to add an entry to index.adoc to make sure that your new btcnode.adoc doc is discoverable. For right now, you can just put it at the bottom of the list in the Contributor Docs section. I plan to revise the index page soon to better accommodate these kinds of docs.
One of the effects of having these docs is that the descriptions in role issues like this one become simple, uniform, and largely unchanging. There's little need to "keep them up to date", and that avoids permissions problems like the one you had where you were unable to edit this issue (because I was the one who created it). The description ends up being as simple as this:
Docs: https://docs.bisq.network/btcnode.adoc#maintainer
Team: @bisq-network/btcnode-maintainers
Primary owner: @sqrrm
So, please let me know if it works for you to do this, and I'll look out for your PR. Thanks!
@cbeams I'll try to get that done, hopefully by the end of this week. Will let you know.
@cbeams I tried writing this up but three times I gave up. It's in principle not a hard task but I find administrative tasks energy draining so I just push it as long as I can. This is probably not the case for everyone but for me I would waste days of energy on something that, as you say, should take 30 minutes for someone with the inclination. The issues I face are:
- I don't enjoy writing documentation and thus lack motivation but I don't mind the technical details of the role
- There is process that needs to be followed and learned but the benefit seems small for the energy spent
- The need to learn adoc notation to write a reasonable document
I think it would be better to get someone to write these docs up in a minimal fashion for the maintainers to fix if need be. I suspect someone might actually enjoy doing this whereas I and perhaps others with a similar aversion to administrative tasks would be turned off and even avoid taking on roles that could otherwise be taken.
Yeah @sqrrm I don't blame you. I'm willing to write the doc if you're willing to provide the details.
But in order to start, I need basic details covering the required content. Let me know if that already exists somewhere.
Otherwise, we could proceed in 2 ways:
- you produce quick written notes that cover the items @cbeams mentioned above. They don't need to be remotely well-formed or even readable (i.e., a "brain dump").
- we have a quick 10-15 minute phone conversation where we talk through the content.
Let me know what you think, or if you've got any other suggestions.
2018.07 report
During the month there has been no noticeable events.
There is a new minor bitcoind version out but we have earlier decided to only try to move quickly to new major versions. There is also a question if we actually want to move to 0.17.x when it arrives, to be discussed separately when it's more relevant.
The process of moving to new role management and documentation has been slow, partially due to me and partially due to the process. I will try to get this done for the bitcoin nodes next month with the help of @m52go That should work as a template for the other roles.
2018.09 report
This month there was a bug in bitcoind https://bitcoincore.org/en/2018/09/20/notice/ requiring urgent attention. All bisq bitcoin nodes were upgraded urgently.
2018.10 report
A new major version is out, 0.17.0. Some have upgraded and no issues have been seen so I think it's good if all node operators upgrade at this point.
2018.11 report
The documentation for bitcoin node is getting closer to completion, @m52go is working on it with my input.
There is a new minor bitcoind version, no need to upgrade but those that want to can do it.
bisq-network/compensation#173
2018.12 report
Bitcoin Core 0.17.1 has been released but I see no urgent need for nodes on 0.17.0+ to upgrade.
Nothing more to report for December
https://github.com/bisq-network/compensation/issues/190
I see the helpwanted tag on this role, is this still the case? If so what is needed?
@KanoczTomas What's needed is the secondary role as node maintainer. I'm not exactly sure what the secondary role entails, but something like a backup for the primary I guess. There is a better role description in the works, don't think it's published yet but it's almost done I think.
2019.01 report
Nothing to report for January
https://github.com/bisq-network/compensation/issues/213
@sqrrm ok I will wait for the docs. I manage several bitcoin nodes and statically build core then distribute it to my nodes. Maybe I might help with something in the future. We will see.
@KanoczTomas This is the role as maintainer which is about keeping up to date with node software, config and make sure that the nodes that we run are adequate. The doc is actually ready but not linked, see https://github.com/bisq-network/bisq-docs/blob/master/btcnode.adoc#maintainer
To run a node there is a role for that as well https://github.com/bisq-network/roles/issues/67
Since you build and run nodes you probably keep up to date with bitcoin core developments and taking over the secondary role from @ManfredKarrer as maintainer might be appropriate.
@KanoczTomas @sqrrm Would be great if you could take over secondary role. Thanks!
@sqrrm @ManfredKarrer I can take the secondary role, what I lack from the document is how is the proper version of bitcoind shared and how is the confederation bitcoin nodes status "looked over" by this role.
I suggest adding the minimal version to https://github.com/bisq-network/bisq-btcnode (like minimal_version.txt ot whatever) ... any thoughts on this?
@KanoczTomas We currently don't have a strict policy on how the nodes are run. The main idea has been that the operators upgrade to the latest main version reasonably fast. The minor version are optional unless otherwise discussed. So for 0.16.3 it was obviously urgent that everyone upgraded.
How the operators get their binaries and deploy them has not been discussed but I welcome a minimal doc. Anything you add will likely be an addition to what we're currently doing.
There is a monitoring tool to check on node status at http://seedmonitor.0-2-1.net/
On CVE-2018–20587
A summary can be found at https://medium.com/@lukedashjr/cve-2018-20587-advisory-and-full-disclosure-a3105551e78b
I don't think any action is needed from our side as long as the nodes are running in a safe environment with only one user. It's up to node operators to handle their individual op sec. Perhaps we could add some recommendations on this to make sure everyone is more aware? @Emzy @KanoczTomas ?
@sqrrm I agree, besides the node operator should be running the node without a wallet (disablewallet=1, or disabling it during compilation). This would lover financial loss risk. To mitigate for dual stack issues operators that do not use ipv6 should disable the complete stack, hence bitcoind will not try to bind to it. We could recommend having bind and rpcallow only to localhost. I can create a document with best practices for bitcoin node operators, will send for review once ready.
I agree, there is no direct action needed. Best practice would be to have only the seed node + bitcoind on the server running. You could check if there is something else listening on the bitcoind rpc port (8332) before staring the bitcoind.
netstat -lpnt | grep 8332 The output should be empty if bitcoind isn't running.
@KanoczTomas @Emzy Great, let's add a section to the doc on some reasonable best practices on how to run a node. I think we can update the bitcoin.conf template and add a build section to https://github.com/bisq-network/bisq-docs/blob/master/btcnode.adoc as well.
2019.02 report
CVE-2018–20587 reported, decided that no action was needed. @KanoczTomas planning on taking over as secondary node maintainer
https://github.com/bisq-network/compensation/issues/228#issue-415543390
2019.03 report
Nothing to report for March
https://github.com/bisq-network/compensation/issues/253