Wondering whether we still have a public Bitcoin testnet node running and what's its address @shannona ?

I'll add it to and update the website.

5E6Nqfa1SdofeXjVgtyAr4wRb7bJkf3275q6YtdTD27R5M5C[tbellmoney.business.site

Our current standard developer contract is oriented toward submission to open source repos, but some of our efforts are research that is shared with Patrons and may not be available in a repo. Investigate how to solve this, initially for @shannona.

• Contact IP Lawyer

To fully function as a mainnet Bitcoin mobile wallet, FullyNoded 2 needs to have price data. Right now this means we've had to turn off locking the wallet down to only speak to hidden .onion addresses, as there doesn't appear to be any free APIs for price data.

In addition, we'd like to users being able to support adding price data history to your transactional data in your personal wallet. For instance, to allow export to a personal Beancount accounting database.

Thus at minimum we'd like to host our own hidden .onion service with current price data, and in the principle of self-sovereignty, allow people to host this service themselves if they want on their own VPS, VM or personal node.

Other features are the price history, possibly scraped from multiple sources, various forms of validation (public lists of price servers, data is signed by the .onion servers keys, is this the same in 3 or more sites, etc.)

Right now Cooper Kernan (@cprkrn) has the most background about price data, and is likely the intern lead on this project. But he'll need support to design how to do this portably so that we can can potentially host this at multiple .onion sites at multiple locations.

As with all of these, this conversation is open to better ideas and solutions.

cc/ @fakhrulKhir @TheBlueMatt

Our Apple Developer certificate for Blockchain Common's is expiring in a few days.

As we have a number of new TestFlight versions coming out now, we probably should to go ahead an convert over to the new one now. There are a number of us building with it (@ChristopherA @Fonta1n3 @wolfmcnally @shannona) so we should coordinate the switch over on the Gordian Core Test Team on Signal.

Your Distribution Certificate will no longer be valid in 30 days. To generate a new certificate, sign in and visit Certificates, Identifiers & Profiles.

Certificate: Distribution
Team ID: YZHG975W3A

To learn more about expired certificates, visit the certificates support page.

Best regards,
Apple Developer Program Support

• Choose Different Ones for Community?
• Add to Community
• Are people actually using labels?
• [ ]
  Since we have have so many repositories, we should come up with a reasonable set of standard labels that are suitable for our needs. The trick will be not to have TOO many labels. We don't tend to host giant projects with lots of contributors and complex automated CI scripts, instead for most it is typically a lead and some contributors. However, some repos like this one and the Airgapped Community also need some labels suitable to our community as whole and the cross-repo project management work we do.

First do some research: look at some other cryptocurrency repos, in particular Bitcoin-Core. I also found some good links:

• https://robinpowered.com/blog/best-practice-system-for-organizing-and-tagging-github-issues
• https://docs.saltproject.io/en/latest/topics/development/labels.html
• https://seantrane.com/posts/logical-colorful-github-labels-18230/
• https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63

We should make some decisions on if we want to use emoji in Labels and how non-Label tags might be used (in particular, Milestones and Projects)

I'd suggest starting with the Secure Template as it is what is used to create new repos as the base set, and then add some additional labels to this Community repo. Then seek feedback. Once a set it finalized, it needs to be brought into our other repos, which can either be done by hand, or automated or use gitlabelmaker.

See below (from #143) for categories for community discussion, that might then be dovetailed into labels.

We need some help with better discussion categories for our Community Discussions.

https://github.com/blockchaincommons/community/discussions

Resolving this has a few steps. We need the first three or maybe four right now:

• Identify most active GitHub Discussions community.
  • Not sure how to do this. Maybe Github has publicized some of the better github sponsor repos?
  • Maybe IPFS?
• Research Categories used by top communities.
• Produce a list of categories.
• Suggest changes to standard labels used in the Community Repo
• Get Feedback
• Implement

As previously discussed with @ChristopherA and @gorazdko, we should document the PR opening, reviewing/editing, and merging process. Blockchain Commons does use Github Flow, but often times the PR reviewing process can get cumbersome and/or time-consuming. So, here are some ways to make it work more seamlessly, assuming the contributor is a new contributor:

1. Using Github CLI gh [Best IMO]:

   • Contributor forks the repository
   • Contributor creates an issue in base repository to start the discussion or a draft PR (for the latter, the branch would have to be created first)
   • Contributor signs CLA and either issues a separate PR or sends via email to Christopher
   • Contributor creates a new feature-branch from master
   • Contributor works on that branch through atomic, signed commits
   • Contributor finishes work and issues a PR to master, checking the "allow edits from maintainers" box
   • Contributor requests review
   • Maintainers can do gh pr checkout <number> in CLI to review and work on that PR, also through atomic, signed commits. This alleviates Maintainer from doing a review through comments on the PR which the Contributor would later need to manually edit and adjust for, having then to tell Maintainer the review was made, etc. Basically making it simpler and streamlined
   • Maintainers finish reviewing/editing and can just do git push for all changes to be pushed to Contributor's fork and therefore to the PR as well
   • If non-maintainers would want/need to work on reviewing/editing that PR, they wouldn't have permission to do git push. So Contributor would have to invite each non-maintainer to Contributor's fork for them to have the necessary permissions to push directly to that fork and therefore to the PR as well
   • After the necessary edits and reviews, Maintainers of the base repository can merge to master and delete the feature-branch

2. Using Pure Github Flow

   • The seven first steps from number one also work here. What changes is beginning on item number eight. Also, here it doesn't matter much whether the reviewer is a Maintainer or a Non-maintainer, so both will be used interchangeably:
   • Maintainer branches off of the PR's Contributor branch through a git clone from Contributor fork and branch into a new branch
   • Maintainers then work on their branch through atomic, signed commits
   • Maintainer finishes working, issues a PR to Contributor's fork
   • Contributor merges Maintainer's PR into his fork, updating his own initial PR into base repository
   • Maintainer marks base repository PR as ready for merge
   • PR can be merged by Maintainer
   • Note: this is basically what has been done in PRs for portuguese translation of LBftCL. IMO it's already an improvement on reviewing with comments and requiring Contributor to edit etc.

In any case, we can rapidly notice how 1 is quicker and easier than 2. But it uses gh and requires Contributor to invite non-maintainers to his fork so edits can be streamlined and pushes allowed.

Number 2 doesn't require that, but it does require Contributor to merge a PR into their own fork which effectively creates duplicity in terms of work needed -- merge a PR onto a fork so another PR can be updated, only then to merge that PR onto base repo master. Phew!

But there might also be other ways to go about this.

Thoughts?

Lead: @wolfmcnally

Define a UR-based QuickConnect standard for TorGaps, that handles multiple services and replaces current JSON based version.

Likely required for Gordian Recovery #80 as that app should point to a full node (or Esplora) and a seperate Spotbit instance.

#QuickConnect #UR #TorGap

In order to be able to implement certain kinds of architectures that leverage commitments (for instance Key Transparency, Kademilia, CONIKS) we need an implementation of Verifiable Random Functions.

There does exist a C fork of bitcoin-core/secp256k1 at https://github.com/aergoio/secp256k1-vrf that implements VRF to the IETF standard, which likely is close to what we need. There is also one in Rust that is more questionable: https://github.com/debasish-raychawdhuri/vrf_on_secp256k1

See also #88

A command-line app written in RUST for experimenting with Simplex, UR, and CBOR concepts.

https://hackmd.io/@wolfmcnally/By2kv1uXc

We need a tool to make this sort of thing easier:

https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/crypto-request-test-vectors.md#appendix-standard-process-for-creating-test-vectors

To do this both directions, making and reading test vectors.

Volunteers for our advocacy absolutely needed. And not only coders, but requirements, UI, testing, documentation, fund raising, foundation proposals, law & regulatory review, marketing, graphics, etc.

See also #109

@maaku @tuurdemeester @waynevaughan

I wanted to have something to point to at end of today's twitter thread, so I have posted a first pass at a document describing #BlockchainCommons, and I have mentioned your names and your background. Could you review it and confirm here if it is ok or if changes are required? Thanks!

PENDING: Commitment to 25159, Ristretto

Current notes at https://hackmd.io/ea_Y7AvySOOo5sESVFX1hA but needs updating with more details of multisig problems, FROST, etc.

Do before, or as a followup to, a cryptowatch article?

Why 25519 HD-Keys are bad

Dependency: Identity Sponsor using 25519

• Review Issue
• Create Subtasks
• Determine if LetheKit Needs to Be Updated

LetheKit v0 is an open source DIY hardware box with offline cryptographic tools. It can use dice for entropy, import seeds in a variety formats, and exports derived keys using UR-based QR codes.

However, it can't support crypto-request QRs, or sign transactions as it does not have a camera.

SeedSigner is another open source DIY device that does have a camera and a better display but it does not support UR QRs.

The goal would be to evaluate if we can submit patches to @SeedSigner to add all the UR functionality that LetheKit has, and if not, port the LetheKit code to that hardware as an alternative to the seedsigner code base.

Sub-projects could be to understand requirements (for instance, LetheKit forgets when powered off, I'm not sure with seedsigner) and use cases, evaluate their code, update the existing LetheKit v0 code for recent UR features, write docs, create a video tutorial, update the LetheKit web page, etc.

Suitable as a possible internship project. See Discussion

@ksedgwic or @gorazdko, fomer leads on LetheKit project might be persuaded to be mentors.

• Investigate: Can We Do Reproducible Builds with our CLI Tools?
  • Determine Scope of Work

https://reproducible-builds.org/docs/

CKM is a Blockchain Commons architecture that leverages Schnorr, FROST, Distributed Key Generation, and other modern cryptography to reduce correlation, SPOC, SPOF and SPOD.

Early Draft at: https://hackmd.io/hb538SOJT8e3gS2nRerT9Q

• Say this is 2023, forward looking, want to achieve by end of 2023. Lots of things
• Say: Key it in mind for CSR Work, which is our main focus, and is foundation for this as next step
• (More than napkin sketch, not spec)
• Release
  Related to #92 #93

We need review of the text for our demo Torgap stackscripts (initially the Torgap demo and the open time stamp demo). In particular, at the bottom it needs to credit blockchain commons, and link to the appropriate repo if they want to hose their own, and a call for support.

Longer term, we need to add a spot for the "host" of one of these services can advertise they are hosting it (for instance Bitmark), but that it was written by Blockchain Commons and to support us.

• Write Standard Text: "This a Proof of Concept. Use at Own Risk. See Repo. See Blockchain Commons."
• Flag It in Issues for current projects

See also #142
/cc @shannona
@nochiel

We are looking to fill out Chapter 18 of Learning Bitcoin from the Command Line by offering up six short sections which each describe how to command bitcoind via RPC with a popular programming language.

We have six options:

• Go (unwritten)
• Java (needs revision & standardization)
• NodeJS (needs completion, standardization, and revision)
• Python (unwritten)
• Rust (unwritten)
• Swift (unwritten)

Each of these sections will include how to set up a developer environment for programming Bitcoin in the language of choice; how to issue RPC commands and get results; how to do basic wallet manipulation; and (ultimately) how to send a transaction. The object is not to create any sort of complete program for the users (as we sort of do in the C sections), but just to show these short fragments to get users the barest of foundation.

Each section needs to be standardized into the same format, shown below, so that anyone can jump from one section to another and see the exact same code in different libraries.

We don't have this precise format anywhere, but take a look at the Java section which is 75% of the way there. The first and second chapters of C may also be of use for the general categories of what we want to do, but do note that (1) it's more in-depth than we want here, and (2) it shows how to write a complete program, which we're not doing here.

The overall concept here is simplicity and brevity. We want to do the minimum necessary to show this functionality, in brief, but leave the readers with enough knowledge to move forward on their own. Obviously, the scope of each chapter is intended to be much smaller than the large-scale C work in Issue #11

Here's the standard section names:

Setup [Language]

Setup the complete IDE for the user to program Bitcoin on a Debian machine using the language of choice. Assume they have none of it at start.

1. Install anything necessary to code with the library

Setup [any sublibraries]

2. Install any libraries necessary for accessing RPC
3. Install any chosen Bitcoin libraries

Remember that our object here is to teach RPC-focused Bitcoin programming. Bitcoin libraries are good to use if that's their paradigm. Maybe the user isn't making the RPC callout themselves, but the functions should still be each tightly connected to an RPC command. If a Bitcoin library is higher level and obscures the RPC functionality, we should not be using it (but it's OK to reference it, below).

Build Your Connection

Make an RPC Call

Using "getmininginfo" as an example

Output Your Response

1. Get the results
2. Output the results
3. Close the connection

Make an RPC Call with Arguments

Is it notably different to send an RPC call with arguments? If so, explain/demonstrate it here with the abstract methodology for encoding and setting parameters. (We'll use it more completely in some of the next section.)

Manipulate Your Wallet

Look Up Addresses

Look Up Funds

Create an Address

Create a Transaction

For More Information

[if there are links to how to do more programming in Bitcoin with this language, this is where to put them; we can link multiple sites, reference books, whatever you think will help people learn more.]

Summary

Just a few sentences on how you set things up and how they worked. See the summaries elsewhere in the course.

We have a release path for projects https://github.com/BlockchainCommons/Community/blob/master/release-path-standards.md

• Should we revise our categories to be more like COSS (as per https://specs.status.im). For instance, we don't have a deprecated category. [ALSO APPLY THAT TO OLDER Release Path]

But for projects like the Psuedonymity Guide, which have both, we may want to a different naming standards.

@shannona @namcios

Lead: @shannona

Create logo, text, associated graphics and trademarks, and legal. Get buy-in from patrons & wallet ecosystem partners. Initially Bitmark, Foundation Devices, but also ideally one bitcoin service/non-wallet vendor.

Current draft: https://hackmd.io/KFIw-SUnRGyv3A8c6VpTXQ

#Gordian #seal #wallet #specifications #interoperability #airgap #community #standards

• See what Joe thinks now

Use cases exist because the hard part of programming is not writing the code, but rather knowing what code to write. They help to identify the right code to write, and what code not to write.

• Rewrite Issue
• Investigate What It Would Involve
  • What Exists? Is It Refactor? What is Needed? Is it worthwhile?

I'm volunteering to take lead on adapting the Linux scripts for Bitcoin Standup into a single script which allows for standalone installation on Windows.

Per discussion with Christopher, the current process on windows requires the user to install developer tools manually, setup Homebrew, and then download the script from Blockchain Commons.

We'd like to enable a easier/less technical workflow to reduce the technical barriers to running a node for Windows users.

The rough requirements are:

• Install tools for Bitcoin Core
• Set it up so it runs through Tor
• Set up some way for user to see QR code/corresponding info to connect devices to their node
• Put wrappers around it for simple UI

@ChristopherA this is my understanding from notes on our call, please clarify or add anything I'm missing at this early stage!

At #RWOT9 in Prague @ChristopherA and @JoeAndrieu shared as a topic paper What’s in Your Wallet? on the topic of architecture for digital wallets.

A more complete, but slightly older version is available in a private google doc at https://docs.google.com/document/d/1fbYVhiVd0ES2lHZ6zjYUfj9kVp_HOED6ROmY7ULpUWc

We need to update and publish this document given the latest thinking given Gordian Principles, our reference architecture given our reference apps, Smart Custody 2.0, our Silicon Salon, etc.

Milestone at https://github.com/BlockchainCommons/GordianSeedTool-iOS/milestone/2

Lead: @wolfmcnally

Currently the linux scripts for Bitcoin Standup Scripts are fairly simple, and establish just a single node.

This script was originally based on the script in Learning Bitcoin from the Command Line as I found it very inexpensive and easy for a novice to install a Bitcoin testnet full-node with tx-index on Linode by simply pasting a single stackscript and waiting a half-day. This node would be free for the first month (and Blockchain Commons gets a $10 credit if they use the referral code), and only $5 - $10 a month thereafter. When I had taught it before with people laptops we had all kinds of problems, and this solved it.

However, for purposes of a Bitcoin mainnet full node, especially one that is not pruned, hosting a VPS using this script is expensive. On Linode a single VPS that can hold a full node is $160 a month, but that includes 32GB RAM and SSD which is overkill. So we should research the cheapest way to host the bitcoin data on various VPS service separate from the VPS itself.

This will also help us in the future as hosting a Lightning Network requires a full node. See Issue #7.

There are other improvements that can be made to the Bitcoin Standup scripts, including:

• Review @ NicolasDorier scripts in the @btcpayserver community, both code and docs https://docs.btcpayserver.org/ManualDeploymentExtended/ for best practices for our use as well as submit changes back.
• Consider adding option for Tor .onion based BitcoinFibre https://github.com/bitcoinfibre to allow faster sync between Bitcoin Standup full nodes (this is also used by Blockstream Satellite).
• Review Blockstream Satellite https://github.com/Blockstream/bitcoinsatellite/ code and docs. * [ ] hosting multiple bitcoin networks like the yesterday's version of Bitcoin Standup MacOS.
• Allowing alternative versions of Bitcoin-core to be installed, such as @luke-jr's Bitcoin Knots https://github.com/bitcoinknots/bitcoin or @kallewoof's Signet https://github.com/kallewoof/signet-platform. In particular, the latter can help simulate adversarial conditions on the Bitcoin network to better test future versions of FullyNoded against.
• Supporting some form of pre-signed download of pruned full-node data like BTCPay offers as an option.
• The ability to host some other simple bitcoin-related services using the nodes .onion
• Can the new bitcoin-core Hardware Wallet Interface (HWI) https://github.com/bitcoin-core/HWI code can't be used on a VPS (I don't think) but could be useful for people installing on their own machine.
• We need some process for testing and keeping these scripts updated as new releases are announced, as well as updating existing nodes.

We also should release scripts to work standalone for Mac (for those who don't want to use the Bitcoin Standup Mac app) and Windows (a big challenge).

Eventually, after thorough testing, these scripts should audited formally by people in the bitcoin-core community.

What other features am I missing?

-- Christopher Allen

Simplex is our long-term architecture for structured data that is self-describing, self-authenticating, and support progressive trust architectures.

Early draft at https://hackmd.io/@wolfmcnally/BJWPhJhQc

PENDING: someone actively working on this & giving us requirements

Requirements for, evaluation of existing practices & in general how do we assess security standards for cold storage vaults. In particular how do we store tokens (fungible, NFTs, ocaps, DIDs, etc) given a Gordian Architecture?

Write Appendix I, "Compiling Bitcoin", for Learning Bitcoin from the Command Line.

Use a Debian 10 machine, install the full development environment required to compile Bitcoin, pull 0.20 from the GitHub, and compile it.

Document and explain all the steps.

Investigate various options:

https://github.com/square/beancounter

Gordian Recovery

Implement and release Gordian Recovery for multiple platforms. Focused on archiving transactions (for instance beancount) & then sweeping transactions to new descriptor, in particular for legacy bitcoin accounts, and moderns multisig accounts.

Closely related in features to Gordian Coordinator but focused on sweeping.

#gordian #recovery #sweep.

https://github.com/BlockchainCommons/Community/projects/1#card-58978605

Possible #internship project.

Explore use cases and requirements to support international human rights advocates and health care professionals, including a possible user engagement model.

See community discussion: for more details #76 (comment)

Todo

• Make Q2 and Summer Virtual Internship plan for features to be added:
• Document which issues have already been solved by the 2022 refactor.

A summary of changes made in the 2022 refactor:

• See BlockchainCommons/spotbit#55 for details on the refactor.
• Spotbit no longer stores an offline database. Instead, we prefer to fetch data from exchange APIs on demand. This fixes BlockchainCommons/spotbit#41 and BlockchainCommons/spotbit#16.
• Use of FastAPI instead of Flask allowed us to be more flexible in
  • refactoring and automatically documenting the API.
    • BlockchainCommons/spotbit#51
  • improving uptime/reliablity.
  • improving perfomance using FastAPI's async-first features.
    • Ref. https://flask.palletsprojects.com/en/2.2.x/async-await/#when-to-use-quart-instead

Previously, @watersnake1 wrote:

I am preparing to back off from the lead developer of spotbit role - I am now back to school full-time and managing another internship, so this isn't really something that I can maintain any longer. Spotbit itself is a functioning system for managing current data, both from a database and directly from exchanges, and for providing averaged price info based on sets of 5 exchanges.

The next phase of Spotbit is naturally historical data. The first challenge in this process is backfilling gaps in the database that can be caused by downtime. I've detailed that in an issue here BlockchainCommons/spotbit#41

There is also some great js code written by Javier that needs to be moved to a clearnet website: BlockchainCommons/spotbit#40

And finally, recently there have been responsiveness issues with the server. I suspect its a tor issue, as I have seen it happen in other onion services I run: BlockchainCommons/spotbit#39
@Fonta1n3 I am convinced its not an optimization issue, but perhaps an issue with how tor is set up.

My next priority is to migrate the linode server to control of Blockchain Commons, which I will complete tomorrow.

@ChristopherA thank you very much for this internship opportunity this summer. It has been a truly great experience working with everyone at blockchain commons these last few months!

Post here if you have questions or are interested in participating in the fall 2020 cohort of the @BlockchainCommons 2nd cohort of our virtual internship program. Email me your CV, some highlights of some of the things you like to work on, and what you’d like to get out of an internship with Us. Also what platforms you develop on, and what kind of smart phone and development environment you use.

We also welcome applications outside of the developer community, as not all projects are code. In particular, we are seeking library science students to help us organize our links, references and work, education specialists to work on tutorials, and pre-law students to help with our advocacy in the creation of new laws in places like Wyoming where our advice has been well respected and is turning into law.

At whatever level of development skill you do have (or not) we do hope that you'll at least have worked through the first chapters of the https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line course and have gotten to as far as you can, or that have tried out the Gordian Wallet TestFlight beta https://github.com/BlockchainCommons/GordianWallet-iOS even if you don't have development skills. Command line isn't easy, but it isn't hard either!

interns can expect to participate in a private Signal chats with fellow interns and members of the @BlockchainCommons community, as well as weekly open "intern office hours" video chats with open questioins and sometimes guests from the industry. In addition, each intern is offered 3 personal "mentorship" calls with @ChristopherA to discuss their education and career plans for the future.

We do offer a small honorarium in bitcoin over the course of the program as interns meet 3 milestones. If you agree to participate in our internship program we'll need you to work with you on a work order to describe the your project you'll be leading, and you'll need GPG sign our internship agreement and any CLAs our projects use for contribution assignments.

Deadlines for the October through November internship program is September 28th and starts October 5th through December 18th. When your 3 internship milestones are complete we can offer you a certification of completion.

If you can't participate in this fall's program, we will likely offer one on the spring and summer of 2021.

We look forward to collaborating with you!

-- Christopher Allen

Lead: TBD

This topic continues to haunt the bitcoin ecosystem with some proposed approaches that are likely bad long-term architecture.

Goal: define legacy best practices to avoid reuse of xpubs when creating multisigs for stateless wallets (for instance for single key signer), and higher standard for stateful wallets (Sparrow Wallet, Gordian SeedTool, etc.) but also start dialogue in community about architectures to do this right (probably xpub private commitments related to commitments also needed for FROST).

See: BlockchainCommons/Gordian-Developer-Community#53

#wallets #airgap #standards

Lead: @shannona

Possibly based on IEEE https://www.ieee.org/about/corporate/governance/p7-8.html, but nothing as large as https://www.acm.org/code-of-ethics

Currrent draft at https://hackmd.io/SJbeoXaFScmGM4_-AmNZeQ

• Review RWOT's for improvements (more current?)
• Update current draft
• Puzzle to simplify to best practices for small open source org.
• Circulate to staff & key patrons first, then community.
• Publish for us
• Write article as as possible minimal best practices for small open source

@shannona

We have a separate static web site for our #SmartCustody project, as its audience & patrons are a bit different than the broader Blockchain Commons audience & patrons.

• Website: https://www.SmartCustody.com
• Github Repo: https://github.com/BlockchainCommons/www.SmartCustody.com

We are currently leveraging the native GitHub static website features of Jekyll remote which means that simply by committing the changes to the repo, the website is updated.

We are using one of the more sophisticated Jekyll themes called HydeJack Pro, however, it almost but doesn't quite work perfectly with remote-theme and in general requires some relatively sophisticated knowledge of Jekyll's various templating tools (significantly more complex than the default themes used by Github which are quite easy to understand). After paying for the license to HydeJack Pro the author refunded our payment when we asked for help with remote-theme and other advanced Jekyll features.

Thus we are in a situation with a difficult to configure and sometimes problematical static website and theme, and we are not able to get support and updates from the theme author.

In the long run we probably should change theme to one we can self-support, but in the meantime, here is a list of some updates that we need to do, and some our problems.

• Add new blog post about seeking sponsor for update of book.
• We need to add link to sponsors.md to sidebar #ThemeProblem
• We need to link sponsors.md elsewhere
• We need to add book download links to project pages
• Investigate if there are some other ways to update the theme #ThemeProblem

We need to update our internal community standards, repo policies, and related templates for 2022. Especially given new Internship projects.

This includes:

• When you want to move a project to BC

  • When? Why? (Why Not?)
  • CLA Requirements
  • README.md Standardization

• Standardize repo issue tag name, descripts, and colors (update all and put in security-template).

• More detail on versioning, releases, git branch strategies:

  • Examples:
    • https://github.com/bitcoindevkit/bdk/blob/master/DEVELOPMENT_CYCLE.md

• Adapt CII Best Practices for our needs, identify key ones to try to document and achieve, and begin practice.

  • Do we want to strive to badge? https://github.com/rsp/cii-best-practices-badge

Some of these might make good intern projects.

There is a need for a reasonable long-term "staging" ground branch for sep256k1 related crypto that might ultimately be brought into the bitcoin ecosystem, not just at the L1 level but also at L2.

The problem is that Bitcoin Core's secp256k1 library tends to not merge branches until they are extremely mature and are ready to use in an upcoming L1 release.

Until recently, Blockstream's Elements [secp256k1-zkp] has unofficially served this purpose, with early versions of Segwit, Schnorr, Taproot, etc. being first implemented there first and ultimately merged into the upstream master. Most recently, Musig 2 has been implemented in Elements -zkp branch and is under evaluation for merging upstream, and work toward quorum threshold FROST has started on Elements -zkp.

However, Blockstream and the Elements team are not sure that their Elements -zkp branch should be used this way, unless it is specifically for a Blockstream project. This causes problems as there are other important cryptographic functions that need tight integration with the secp256k1 library, but are not currently important to Blockstream, that ought to be supported by the larger community. Currently having to support multiple branches of the secp256k1 library is problematic.

I'm not sure if the right answer is to persuade Blockstream to broaden their support of other cryptographic code into Elements -zkp, or to try to build community support in the broader bitcoin-core community for an official long-term experimental staging branch hosted there, or if this is something that Blockchain Commons should try to offer the ecosystem. In the latter case, we don't have a sufficient level of cryptographic engineers to support a project like this, but we could possibly encourage some to commit to support a project like this hosted by Blockchain Commons.

• Discussion about this in [Bitcoin Core issues](https://github.com/bitcoin-core/secp256k1/issues/997#issuecomment-949463114]
• Discussion about this topic at Elements issues
• Related:
  • Adapter Signatures for Schnorr
  • VRF for secp256k1

/cc @kanzure @jesseposner @maaku @wolfmcnally @kanzure

Need a proposal from @wolfmcnally

A cryptographic predicate language for use with Simplex Objects #92

Early draft at https://hackmd.io/@wolfmcnally/rkM-SJpHc

On Fri, Jun 5, 2020 at 7:06 AM @ ksedgwic wrote:

I think we've outlined 4 different project areas:

• bc-lethekit - export XPUB as QR

I think the addition of export XPUB as QR on bc-lethekit looks pretty straightforward:

• An initial version likely doesn't need animated QRs etc because simple XPUB should fit in single QR.
• I think the most challenging  part of the project is the "editor" where the user specifies the desire HD path (eg: m/84'/0'/0')

I think the first priority should be:

• The ability to export XPUB as raw text (mostly so you can compare it against your own records, not that you'd write them down from the LetheKit display in this form).
• As QR encoded text (some wallets may already accept this form).
• As QR encoded UR format (as I hope this will be an emerging standard).

Chris - are we missing any?  Which would you like to see?

I'd like to see along the way to XPUB that seeds can be export as QR encoded UR format as well, for the purpose of reference implementation as some wallet vendors would like to interchange/backup seeds, not that LetheKit's user model needs it (LetheKit's user model is keep master key forever secret).  But adding QR seed export doesn't hurt LetheKit's model.

Though I feel that XPUB is the first priority, the ability to export a Shamir shard  (note that our bc-shamir >= slip-39 as it can support encoding private metadata) as a QR  encoded UR format is my second in priority. This is because this feature DOES fit into LetheKit's user model — you can bring 5 mobile phones or other QR readers into a vault, give each one a different shard, and the master key never leaves the original LetheKit.

I think this XPUB project would be a great 8-12 week internship project, and quite doable, with some extra credit if the seed QR and shard QR export can also be added.

• bc-lethekit - add camera

Thoughts about the bc-lethekit camera:

• I've had trouble w/ some alixpress merchants.  I've had good luck w/ Waveshare (many orders).
• The https://www.waveshare.com/barcode-scanner-module.htm unit looks pretty interesting.

Adding a camera to LetheKit (aka v1) is obviously really important longer-term, but I think it could exceed the scope of an good internship project. 

• Overall size of the lethekit is not critical.  It's important that it fits in a safe-deposit box, briefcase, small shipping box etc.  But it is not a "pocket carry" kind of use case.

For LetheKit the compatibility with small safe deposit box size is my highest priority, plus maybe an optional 9-volt battery adapter so you can bring power in and not charge from USB. I eventually might like to see USB locked just behind the screws in the case.

• lightning-pos - config API via phone
• lightning-pos - touch-to-pay invoices

I am quite interested in these as well, but they also feel more long term (Fall?).

First off, adding NFC and any network go beyond the LetheKit model (i.e. it's a LetheKit because it forget the keys), so the compatibility with LetheKit form factor and feature set is less important. Larger transaction sizes and requirements for Lightning metadata are also more important for Lightning Network, so animated QR support may be required, which is still evolving.

I also would like to first see Bitcoin Standup support Lightning (a possible other summer internship project) along with some mobile phone talking to Bitcoin Standup Lightning first (another possible summer internship project). 

All of these additional projects I can see us doing, but I'd like to focus on the initial LetheKit QR ones first as they approachable, doable, and supportable this summer in the internship program.

— Christopher Allen

We've got a listing of "Additional Sponsors" who have sponsored Blockchain Commons through the "Sponsor" page. It's here: https://www.blockchaincommons.com/sponsors.html

It'd be nice if that was automated, and even nicer if it was attractively laid out with GitHub user names and icons.

Here's an example of someone who's done that:
https://karabiner-elements.pqrs.org/

They appear to be doing so in JavaScript code, which suggests there's either a library or an API.

This short project would be to update our Sponsors page ( https://github.com/BlockchainCommons/www.blockchaincommons.com/blob/master/sponsors.md ), replacing the "Additional Sponsors" section with an automated, graphical display like this.

Last year Blockchain Commons helped Matt Corallo (@TheBlueMatt) to establish a new, long-term Tor exit node at NYC Mesh.

The was announced last August https://twitter.com/BlockchainComns/status/1161310976030867456:

Blockchain Commons was founded to support blockchain infrastructure, security & privacy. One project we are supporting & funding are @TheBlueMatt & @ChristopherA to stand an @torproject relay exit node with bandwidth provided by @as397444 via @nycmesh https://metrics.torproject.org/rs.html#details/644074F47257F9A906F9AA5C6B8926C1540A1DA8

We'd like to establish two more Tor exit nodes, one internet topologically near Asia, and then one as topologically far from both as possible (South Africa?). The Tor team may have advice on a better way to choose. Also relevant is access to Blockstream Satellite, mesh networks, etc.

There are multiple parts of this project (needs to be broken apart):

• Pick an intern lead
• Scope the work & milestones
• Budget the upfront and ongoing costs to Blockchain Commons for hosting additional nodes.
• Obtain an ASN for Blockchain Commons
• Work with @TheBlueMatt to return the two unused Swamp C's for use with Tor
• We have been offered the possibility of VM container space at various colo's by Bill Woodcock (@mwoodcock) of Packet Clearing House (@Packet-Clearing-House) to host the Tor exit. We should identify if this offer is still open and what their requirements are.
• Establish and document a standard VM or Docker container that can do Tor exit nodes. Goal: make it easier for others to replicate what we do. Host repo at Blockchain Commons or submit to @torproject.
• Setup ASN, Swamp C address space, routing and transit at colo.
• Turn on tor exit and test
• Long-term support checklist
• Repeat for 2nd solo

There will be interaction of this project with other projects this summer, including that Blockchain Commons hopes help document and support Tor better, hopes to host some other services via hidden .onion services, etc.

All of the above is open — this first message in this issue is to start the discussion.

cc/ @cprkrn @fakhrulKhir

-- Christopher Allen

We need to create a new README.md for this fork explaining the concept.

@maaku originally wrote describing the opportunity:

secp256k1 is defined using arithmetic over the prime field of order p.
Point addition is a group operation with order n, where n is also
prime and nearly but not exactly equal to p. With bulletproofs we are
able to make and check in zero knowledge assertions about integer
arithmetic modulo the order of the curve n, of values inside a
Pedersen commitment (vG+rH). As an intuition pump, you can see how
this arises as adding two Pedersen commitments is the same as adding
the underlying committed values and blinding factors modulo the group
size: c1+c2=(v1+v2 mod n)G+(r1+r2 mod n)H.

However what if we want to check curve operations in zero knowledge?
E.g. proving in zero knowledge that you have a signature for a given
message and public key, or the pre-image of a given Pedersen hash.
Such curve operations are over the field Fp, so this proof is of
arithmetic "mod p" not "mod n". Bulletproofs on secp256k1 are ONLY
able to check assertions about integer assertions (technically,
arithmetic circuits) where the computation is done mod n, where n is
the order of the generator of the curve.

So to do a bulletproof of a secp256k1 curve operation we would need to
use a curve whose generator has order p. As it happens, if one took
the equation and parameters for secp256k1 and merely definitionally
swap the values for n and p, you get a totally unrelated curve (no
homomorphisms between them), but for which n and p are swapped. This
curve is given the cutsy name "secq256k1" -- mind your p's and q's! --
and is sortof a "mirror" curve to secp256k1. Adding to Pedersen
commitments in secp256k1 is the same as adding the underlying values
modulo n, whereas the same operation in secq256k1 is modulo p. So
field arithmetic in secp can be represented as arithmetic over
committed values in seq, and vice versa. This allows us to now prove
things about secp curve operations -- signatures, Pedersen hashes,
etc. -- by using a bulletproof in secq.

[Aside: And since the relationship is symmetrical, we can even do
recursive bulletproofs in secp, which prove the existence of a proof
in secq, of an operation that happened in secp, etc. What utility this
has, if any, remains to be seen however.]

[Addendum: secq proofs are not strictly speaking necessary in order to
evaluate statements mod-p instead of mod-n, as you could of course
create a mod-n circuit interpreter for mod-p statements, but we'd
expect that to be hideously inefficient by comparison to native
support. And zero knowledge proofs are already barely efficient enough
to work with natively as it is.]

I'm finding I'm having to tell some potential collaborations something along of the lines of

We don't want to be a hardware company or a consumer wallet company. Our goal is to support blockchain ecosystem with research, best practices, reference code and implementations, etc. We want to coordinate these into helping the whole community.

We need to integrate this into how we say what we do.

cc/ @shannona @vinaytaylor

Someone particularly comfortable with bare C programming could update and complete the sections on C code in Learning Bitcoin from the Command Line.

This comes in four parts that need to be done in order, but the project could be handed back after completing either part 1, part 2, part 3, or part 4.

1. Edit existing 15.0, 15.1, and 15.2 sections. Make sure that all commands and descriptions remain accurate, and update as necessary for changes in C libraries or Bitcoin code.

2. Write 15.3, demonstrating how to use C code to receive bitcoind notifications (or, if this isn't a good option, let us know). The partial Java chapter has an example of what we're looking for at the bottom, but you can go into more depth here in this "C" section. The ultimate object is to create a short program that readers can use as a building block, as was done in the previous chapters.

3. More fully outline, then write most of chapter 16, demonstrating how to integrate with libwally. This should show how to install libwally, how to use its cryptographic functions, and how to use its wallet functions. If this can link back to the code in chapter 15 to create a larger library for the readers to continue using, great.

4. Figure out if there's a way to meaningful integrate this libwally work with the scripts that are being used in chapters 1-11 of the book. If so, great, scope it out and then write it, and if not, let us know why we should cut this.

Generally, part 1 of this could be done quickly, but the rest all need a bit more effort to scope and outline what's desired.

Obviously, this is intended to be larger-scale work than the short other-language sections proposed in Issue #10 .

At sometime we're also going to want to produce one more chapter, on programming with Lightningd using C, but I need to write the command line sections first, so that's going to be a future project.

Lead: @ChristopherA
Overall Due: 2022-05-12 (Friday)

• Get patronage (@hrf, etc.)
• Announce and publicize
  • In bc-community (DONE: https://github.com/blockchaincommons/community/discussions
  • On Twitter (DONE: https://twitter.com/ChristopherA/status/1496912289722560513 )
  • Press? (DONE: https://bitcoinmagazine.com/business/blockchain-commons-announces-bitcoin-internship-program )
• Suggest possible intership projects
  • In bc-community (DONE: #74)
  • On Twitter: (DONE: https://twitter.com/ChristopherA/status/1511765254744682499 )
• done: https://twitter.com/ChristopherA/status/1511765254744682499)
• end email to all internship applicants.
• Invite bc-community for mentorship
• Interview candidates on Signal, update spreadsheet
• Add accepted candidates to bc-intership-2022 Signal
• Doodle poll for first meeting, on 2022-05-16 or 17 Tuesday or Wednesday.

See https://github.com/orgs/BlockchainCommons/discussions/198

Below was based on internship program, it needs to be revised base on it.

• First meeting
• Office Hours
  • Schedule guests
• Intern Projects
  • Selected (1 lead, 1+ support)
  • Defined & Scoped
  • Use Cases
  • Intern Deliverable Contract
  • Final Code/Peer Review
  • Promotion of Projects
  • Certificate of Completion
• Post-mortem
• Career 1 on 1

Several interns were interested in adding Lightning to Bitcoin Standup, and ultimately to FullyNoded 1 & FullyNoded 2. There was also interest by one intern in possibly some limited FullyNoded 1 like functionality to BitcoinStandup for Android, which could be a start toward a Fully Noded 2 for Android as well.

The biggest problem with this project is that it is too big and insufficient scoped to an internship project. In fact, it is so big if it was fully funded by our Patron's that I'd still have reservations about the large scope.

There are some sub-projects that might be good internship projects, but one of the first issues is which version of Lightning?

@shannona and I always planned to add C-Lighting to our Learning Bitcoin from the Command Line course. This version of Lightning we felt was well aligned with the goal of the course to teach how Bitcoin really worked, in ways that they could leverage people getting jobs in the industry. I still feel that C-Lightning is more the "industrial" and "cash register" version of Lightning for use in bigger projects. There are some advantages also that is is written in C++ and uses LibWally which are used by other Blockchain Commons projects.

However, I believe Lighting Labs lnd tends to be more of a leader in new approaches. In particular, there is something called LSATs that is of interest to a couple of Patron's of Blockchain Commons that could lead to real paid work from Blockchain Commons.

So I think the first step is to look at both of these implementations from the perspective of the command-line course, and from the perspective of advances like LSATs (for instance, maybe LSATs are on the C-Lightning roadmap), and post it to our Research repo.

It is also relatively trivial to fork one of the linux standup scripts to also install lightning. A challenge is that this require a full node (and likely tx-index). This is not inexpensive to host. So another project is to discover the cheapest way to host the bitcoin data on a VPS service separate from the VPS itself. For instance, on Linode a single VPS that can hold a full node is $160 a month, but that includes 32GB RAM and SSD which is overkill.

Once that is addressed in Bitcoin Standup linux scripts, then we can try out both Lightning implementations.

Other ideas? Again, we want to scope things such that the intern leading the project can complete something meaningful in 8-12 weeks.

-- Christopher Allen

Review oldest BC repos, update, identify new leads, deprecate, archive, delete as appropriate.

• Write Deprecation/Sunset/Leadless/Archive standard text in README —SA
  • Include State of Repo (Research/Draft/Alpha/etc)
  • Write Issue/PR Templates for States (to warn people about what expected response/lag time is/etc).
• Write Policies/Standards for Deprecations/Sunset/Archive
• BC Swift LibBitcoin Repos