bitcoinops / bitcoinops.github.io Goto Github PK

We've always been transparent about our funding model in interviews and podcasts (eg https://bitcoinmagazine.com/articles/chaincode-devs-google-alumni-create-industry-group-help-bitcoin-scale/ and https://talesfromthecrypt.libsyn.com/tales-from-the-crypt-36-john-newbery). We should put that information on the website so it's easier for people to find.

Hello everyone

The bitcoin subreddit mods try to sticky important and high-effort content roughly once a week. We'd like to sticky something about bitcoinops next. If you agree, then one of you should post a reddit thread linking to the page, then me or another mod will sticky it.

This has been done for projects like btcpayserver and it usually leads to much more traffic and interest.

It's good to use your reddit accounts because if people have comments or questions then you get a notification so you can answer. Naturally if trolls or spammers appear then they should be reported and the mods will deal with it.

In #167 (comment), @bitschmidty found a broken internal link (anchor) on a PR that passed tests---but the tests are supposed to find broken links to anchors (and they have on many occasions). My best initial guess is that this is because the brokeness is just a capitalization issue, but I need to investigate when I get a moment and see if I can make the test more strict.

It would be nice if there bitcoinops could be subscribed to with an RSS feed as well as an email address.

Benefits:

• RSS feed don't require the user to give out their email address (which could potentially be leaked and be flooded with spam).

• Users may be more willing to subscribe if they feel its easier to unsubscribe (to unsubscribe from an RSS feed just remove the feed from your aggregator)

• Because RSS feeds are pull not push, they usually have much less spam. Which means users are much more likely to actually read them.

https://bitcoincore.org/ only offers an RSS feed, it doesn't offer email at all.

Many mail readers like Thunderbird already understand the RSS format, so the user experiance is actually very similar to email.

https://bitcoinops.org/about/

@bitschmidty would you like to provide a quote for why you're contributing to Optech?

This issue doesn't actually touch the bitcoinops site itself.

The newsletter footer includes:

Our mailing address is:
Bitcoin Optech
27 W 24th St Ste 1101
New York, NY 10010-3250

Is this address still the correct one or should it be updated to Lex 450?

Opening an issue to follow-up on #296 (review):

It may be good here to increasingly put spotlight on the importance of review, which I've found tends to be in practice very much under-appreciated outside the small circle of developers working on the protocol who describe it as most needed and lacking. The larger world seems to value and reward making PRs, BIP proposals, mailing list emails and StackExchange answers. Which is fine, but review needs recognition and encouragement too if we want to see more of it, particularly from industry sponsors and the larger ecosystem. This is even more true for deeper review and research on the harder issues that matter and require a heavy commitment of time. It seems to me that Optech is well-positioned to provide that perspective to those who don't follow the daily interactions on GitHub.

For the reasons mentioned, and because much interesting discussion happens on GitHub:

I'd like to propose a section that regularly covers highlights of the past week's interesting review comments and discussions, similar to the coverage of mailing list discussions (and sometimes IRC discussions).

In addition, quality reviews on difficult or high-priority PRs of interest could be cited as well as a monthly ranking of the top ten reviewers of the past month. Not only might these be interesting for readers, they may have the benefit of helping people who are doing outstanding and/or frequent review and whose names don't come up often in the more visible channels of merges, mail lists, BIPs, and SE.

Finally, I believe the review club notes and discussions can at times be a useful resource for readers (cf Dave's CPFP carve-out/ancestor fee mining notes or my recent notes on P2P network attacks and on mitigating uninitialized values) and mentioned/linked to when helpful in the newsletters and the topics (or added to the topics).

This feature would need to be written (or have frequent input) by someone who spends a lot of time following reviews on the relevant GitHub repositories. Dave is already doing a great job following the merges, mailing lists, and IRC; it might be (probably is) too much additional time commitment to place on him.

Thoughts?

Hi, first thanks for your efforts maintaining this newsletter. I started BitcoinTechWeekly.com magazine around a year ago to cover all technological progress in bitcoin excluding the price, ico and speculation talk.

I would like to reuse parts of your newsletter on my weekly issues especially the notable commits. Would you guys mind if I did it providing I attribute this work to you of course ? I am not sure how does this work regarding the LICENSE part. I am currently releasing all content under CC BY SA 4.0

Reported by @andrewtoth:

Also it looks like you tested Mycelium for iOS. Their Android wallet is far more popular and better maintained, and I believe it also supports sending to P2WPKH and P2WSH addresses.

John:
"I started Optech because if Bitcoin is to be successful, then one of the fundamental challenges facing Bitcoin services and businesses will be how to maximize customer utility by making efficient use of the blockchain. Helping Bitcoin ecosystem players adopt scaling techniques and technologies is one of the most effective ways we can help Bitcoin scale today."

James:
"If Optech succeeds, the Bitcoin ecosystem will have higher rates of technical coordination and understanding; businesses will gain technical insight from the opensource community, and opensource engineers will understand the challenges that industrial users of Bitcoin face. This may benefit everyone working with and relying upon Bitcoin."

Steve:
“I am excited to help Bitcoin Optech Group make a meaningful contribution to Bitcoin. I’m looking forward to working with businesses to develop implementation best practices and to build a bridge between businesses and the open source community.”

Suggested by @harding here: #20 (comment)

As suggested in #183 (comment) (and following comments) PNG's displayed on the site can and should be optimized. @harding and I would opt to use the tool optipng. The tool offers different optimization levels. Using the level -o7 can be slow, but results in presumably the best optimization.

Based on the previous comments I propose following next steps:

• PNG files currently included or added in open PRs should be manually optimized with -o7 in one or more PRs. (addressed in #199)
• A Travis test should be introduced that checks PNG's. The test should fail if a PNG is not optimized. (addressed in #200)

@moneyball - you said you'd take this one in yesterday's call. Ping me if you need any help with Jekyll.

The RSS feed being generated is not generating unique id fields for each post entry. Each month has its own "id"s which each post of that month seems to get, instead of a unique id.

For example, for June 2019, all posts are getting this id:

<id>/en/newsletters/2019/06/newsletter</id>

Instead of the expected:

<id>/en/newsletters/2019/06/05</id>
<id>/en/newsletters/2019/06/12</id>

One example of how this manifests to a feed reader (newsblur), is that only one post per each month is shown in the feed:

@naumenkogs reports that the last sentence of https://bitcoinops.org/en/newsletters/2019/09/11/#bitcoin-core-15759 ("For details on how an adversary could potentially attack a node in this way, see the TxProbe paper.") is incorrect, since the TxProbe paper is about mapping the topology of the network and not the attacks that an adversary could perform once they know the topology.

I suggest changing the wording of the last sentence to "For details on how an adversary could map the network topology, see the TxProbe paper." What do you think, @naumenkogs?

I'm hoping to have some of the company logos be above the fold on a 13" display in order to make the landing page a bit more attention-getting and catchy. There seems to be quite a bit of unnecessary vertical whitespace between the subscribe button and the Member Companies header. I took a quick look at the HTML/CSS and didn't see an obvious way to reduce it.

@harding do you know how?

Please comment on this issue if you have suggestions for the Optech style guide. I'll update a list in this issue description as we go and then merge all agreed changes in one PR/commit.

• add flags/graphics/drop-down menu to make this a bit more pleasing on the eye
• add a localized https://bitcoinops.org/<code>/newsletters/ page so international readers have a place to find all newsletters translated to their language
• add documentation/contrib scripts to make it easier for people to contribute translations.
• add language specific xml feeds

Our twitter stream right now is visually dull: https://twitter.com/bitcoinoptech. There's no image for the links so twitter just defaults to its default grey doc image. We should make it a bit more appealing to the eye with some twitter card markup: https://developer.twitter.com/en/docs/tweets/optimize-with-cards/guides/getting-started.html

I'm open to suggestions about what we put there, but some things we could consider:

• default to the Bitcoin Optech logo:

• default to just the newsletter number in the Optech grey font, eg:

• occasionally have a different image if there's a special issue (eg end-of-year, Scaling Bitcoin special, segwit 2-year anniversary, etc)

There are certain conventions that we've adopted in our newsletters over the last year. For example:

• onchain over on-chain (#86 (comment))
• light client over lite client (#105 (comment))
• merkle tree over Merkle tree (#113 (comment))
• k-of-n multisigs over m-of-n multisigs

We should document all of these somewhere.

The Optech newsletter is very highly regarded. I expect other authors would want to follow the style conventions we use if they were documented somewhere.

The style guide is mature enough that other people/groups refer to it. Turn it into a properly rendered page on our website (instead of https://bitcoinops.org/STYLE.md), and write short blog post announcing it.

Thanks to @harding we now have a basic website that tells the world who we are and what we're doing.

We'll want to put more content on there as we start delivering our objective. This list is taken from @moneyball's comms draft. It can be updates and items added/removed.

• Branding
  • Name
  • Logo
  • Color scheme
  • Tagline/brief description
• About
  • About us
    • Mission
    • No business model, profit motive, etc.
  • Team
    • Give each of us a voice as to why we’re involved
    • Sponsors/supporters such as Wences, JP, AB, AM
  • Member companies
  • Contact us
• Content
  • Quotes / support from Wences, JP, AB, AM
  • Blog
  • Cookbooks
  • Dashboard
  • Research
  • Newsletters
  • Workshops

After bitpay/bitcore#2219 was merged into Bitcore latest release https://github.com/bitpay/copay/releases/tag/v6.1.0 supports sending to P2WPKH and P2WSH addresses.

Add this blurb (or similar) to some future newsletter. Not time sensitive.

## Optech recommends

If you want to start contributing to the Bitcoin Core review process but find the prospect daunting, then check out the [Bitcoin Core PR Review Club][]. Each week, a different Bitcoin Core PR is covered, and new contributors are encouraged to ask questions in a weekly IRC meeting. The weekly IRC meeting has been hosted by Bitcoin Core contributors John Newbery and AJ Towns, with regular appearances from other regular contributors. Optech recommends that any engineer who'd like to get more involved in the Bitcoin Core process should attend and ask questions. The IRC meetings are held at 17:00 UTC on Wednesdays.

[Bitcoin Core PR Review Club]:https://bitcoin-core-review-club.github.io/

After launch craziness is over, payoff technical debt by moving CSS rules specified in style tags to a SASS/CSS file.

I volunteer to do this.

https://dashboard.bitcoinops.org/d/xVQwtADiz/segwit-usage-trends?refresh=1h&orgId=1

• RSS link does not show on /en/publications/
• RSS link for en shows up on /ja/blog/
• RSS feed for ja language

Two issues (one is more of a question) found during translating newsletter 73

• Topic page update : the NL 73 includes links to Topic page such as "Trampoline payments" and "Multipath payments" but on "Optech newsletter and website mentions" section of these pages, the newsletter 73 is not mentioned. Not quite familiar with Jekyll's functionality but it'd be better to check if the Topic page can dynamically pull all the mentions to it or if not, making sure to update the topic page on every NL release. FYI reading the topic page source code it looks like pretty manual. If it's a known issue then I can make a PR to add NL73 to these pages.

• Topic page translation : Do we have a plan to translate the Topic pages too? I saw the en directory under _topics which is same structure as _posts hence was wondering if it's the case. Can I create a ja directory for topics and make a PR?

Similar to https://bitcoincore.org/en/meetings/

bcoin (https://github.com/bcoin-org/bcoin, https://bcoin.io/) is the backend full node and wallet used by Purse.io. They could be listed together or separately (or just one or the other). bcoin offers a range of options, but Purse has been configured with specific settings. I'm happy to make a PR to this repo with details but I'm not sure if the services explicitly need to be tested by an OpTech associate?

Here's the quick details:

SegWit:

• bcoin and Purse support SegWit in all forms: native, nested, send and receive.
• Purse default receive address is bech32 with option for nested.
• Change address type is either legacy or bech32 depending on wallet witness setting, Purse always uses bech32 for change.
• bcoin default wallet type is still legacy until bcoin-org/bcoin#827 is merged.

RBF:

• bcoin and Purse reject RBF transactions by default (they do not enter the mempool or wallet until confirmed) meaning they will "show replaced" but not "show original" assuming the replacement is not itself signaling RBF.
• The wallet by default can not send replaceable transactions or replace RBF transactions.
• Mempool replacement for the bcoin full node is in review: bcoin-org/bcoin#811. After merge we'll begin work on adding RBF options to the wallet although RBF will likely remain rejected by Purse, since deposits aren't credited before confirmation anyway.

Screen shots:

Purse -- illustrating bech32 and nested deposit addresses:

bcoin -- from our API docs illustrating legacy and SegWit wallet account types with receive, change, and nested addresses:

How about using online spreadsheet?
Contributions could be made by commenting cells. Maybe even by unregistered users.

The historical newsletters are really creating a treasure trove of information that increases in value each week. I did a quick google site search to demonstrate that a user can relatively easily search for content. It would be great to add site search.

https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fbitcoinops.org%2Fen%2Fnewsletters%2F+bech32&oq=site%3Ahttps%3A%2F%2Fbitcoinops.org%2Fen%2Fnewsletters%2F+bech32&aqs=chrome..69i57j69i58.3638j0j7&sourceid=chrome&ie=UTF-8

From #120:

"I do think that in the future, as a separate PR, we can either (a) reduce the size of the Optech logo to better match the now-much-shorter text at the top of the home page or (b) add a bit more text description back before Learn More. But, there is so much goodness in this PR, that I think we should merge now. I'll file a separate Issue for my comment above, and we can discuss it there."

Once we complete the 24 weeks of bech32 in August, we should consider putting all of the content in a single post linked from our web site, so that it becomes an easy reference for future readers.

@jamesob - this one's with you!

I'll try to get around to this in the next week or so.

ie next to newsletters, workshops

https://dashboard.bitcoinops.org/

I think we can tidy up the workshops page https://bitcoinops.org/workshops/.

Suggestions:

• start with a more general introduction on our workshops, and then have summary details of the SF workshop below
• emphasize that the workshops are Chatham House rules to encourage open and candid conversations, but that general findings may be published and fed back to the open source community (we've already had two requests to info@ asking for recordings/streamings, which is a reasonable request. It'd be helpful to explain our reasoning for not offering those).
• add a call to action.
  • companies to be involved
  • companies to host
  • open source developers to attend (or perhaps speak if we change the format)
  • suggestions for locations/topics

Announcement page https://bitcoinops.org/en/announcing-bitcoin-optech starts with "Today we’re announcing our new project.." but the date of announcement (July 20) doesn't appear anywhere on the page. Ideally the page would have a byline with date so the text is sensible in the future.

github pages can support https

Should include:

• dates
• venue
• topics

@jamesob

Check out GitLocalize for managing community translations. It's a free platform that integrates with Github and syncs content to and from the repo directly.

Per #261 (comment)

Started receiving Travis build errors in the last day regarding bundler version conflicts.

BIP 179 suggests using Bitcoin invoice address instead of address, to reduce confusion around whether addresses should be reused.

It was suggested here: #171 (comment) that we update the style guide to use. That suggestion was withdrawn because it seems to early for us to make this style change.

Use this issue to track whether we do want to adopt the bitcoin invoice address at some point.

“We're excited to work with Optech on the effort to scale and improve Bitcoin. By collaborating with leading engineers in this space, we'll be able to achieve more than we could have by tackling these problems alone." - Brock Miller, lead Bitcoin Engineer at Coinbase

“We’re proud to be participating in Optech to help further contribute to the crypto community. At Square we continue to explore ways cryptocurrency can expand financial access and we’re excited to help foster a collaborative ecosystem for the benefit of all.” -- Mike Brock, Strategic Development Lead at Square.

Short blog post explaining what the exec briefing was, why we did it, and summaries of the three talks with links to the videos and slides available for download.

We can re-use the summaries from the newsletters and publish this after the 2019-06-12 newsletter.

I prefer to publish this on a different day from the newsletter so it doesn't get buried in the news.

The homepage says, "all materials and documentation produced are placed in the public domain". This is fine with me, but my non-lawyer understanding is that public domain grants are not valid in all jurisdictions (particularly in the EU), so it's better to use a public domain grant with an explicit backup license like CC0.

Although CC0 has a no-warranty clause, my (again non-lawyer) interpretation is that it doesn't necessarily apply if the court decides to enforce the public domain grant, possibly opening dedicators to lawsuits for inaccurate documentation. For that reason, I slightly prefer MIT, which is almost as liberal as public domain but requires the no-warranty statement be retained with all copies.

For comparison, Bitcoin Core, Bitcoin.org, and BitcoinCore.org all use the MIT license for their documentation, and the Bitcoin Wiki uses CC-SA for most content. My personal preferred license is CC-SA, but I think I'm probably in the minority there in the Bitcoin community and any FSF-vetted free license is ultimately fine by me.

(This issue arose in my mind as I'm about to reuse a couple sentences I wrote for previous newsletters on BitcoinCore.org.)