Scaling Bitcoin workshop : Montreal 2015
There should be a SNARK wiki. Any website that is better than someone saying "you know, check the June July 2014 bitcoin-wizard logs". We need to research gmaxwell scalability. We should probably fix that.
Let's talk about what some of the goals are that we might get out of this. We have some different ideas for approaches to systematizing knowledge. There are at least three camps here. I think Bryan's paper repositories.. whenever you search for papers on Google Scholar, you always find Bryan mirrored on his website. I assumed it was a university, but no it was also his website. The title of this group probably came from the title of the paper that 4 of us here work. Jeremy, Joe, Arvin, myself as well as Josh pearl who is not here. Bitcoin is relevant to academic literature, and it involves exciting ideas not generated by academic circles but by the bitcoin community. There is underrepresentation in the academic literature, in academia I think there is an assumption that most of the other ideas come from, so one of our goals was to try to break that.
Whenever we say systematizing knowledge, there's always a recipient of that knowledge. We can't systematize it for knowledge. That paper was very directed at academics. There's also person-to-person scaling problems. How do you pick an audience? When I'm trying to remember how this works, I don't want to remember it from the bitcoin-wizards logs. It would be way more useful to write small summaries.
What's the best forms of these? We could complain about the old IRC logs and mailing lists. There are many sources of knowledge, and many recipients of knowledge. It should funnel in all direction. Systematize the different systemizations by which audience they are targeted at. We have the academic side, we have the whitepaper, in some way that doesn't scale because you get academic credit for doing it once, there's no incentive to keep updating it. It's not community-updateable or anything like that. Developer community.
- policy makers, like coincenter has 300 word explainers that explain each topic, bitcoin primer paper, which was directed at the regulator and policy audience, that was one of the first bitcoin surveys
- academics, researchers
- general public, not necessarily users
- economics people, finance people (not necessarily banks)
Telling the bankers that the MOOCs exist, has been very helpful for legitimacy reasons. Students are an important audience because you want people who are coming into the community for the first time to be able to get up to speed faster. The SK paper was aiming at academics. There are other efforts. Educational materials is for undergrad-level or high-school-level students. And then there's finance industry, market reports.
Gavin and Greg are probably the closest two who are interacting with academics.
Look up so that -- everyone knows about the cypherpunks movement, and it was the proto-bitcoin kind of ideas. Most of those mailing lists have visible logs.
liberationtech, libtech, and another liberationtech...
Archival activity. gmaxwell/bryan has a project to index technologies and proposals.
- IRC logs
- forum posts
- mailing list posts
- bitcoin wiki
- bitcoin.org developer docs
Committed effort to improve the bitcoin wiki?
For devs and for anyone that might run a full node or wallet, what the various pros and cons are of different proposals. Proposal summaries with greppable form, with different proposals linked to why we want this point, because we want this other feature. Argument map. Mind maps. Could be done as a wiki.
You could see developer debate that happens on BIPs so that people could catch up faster. Systematizing whatever's not quite knowledge yet, like on the edge of controversy. We had to filter when writing a paper, we had to drop stuff that was brand-new ideas that had not percolated yet.
Vitalik often writes blog posts.
The source code should be more commented. You can serialize a bunch of these structured data types into a wiki. Every time someone has an argument, just add a link to the argument about bip57, it could be a caption to the page. And then someone can come on later and add a deeplink to a line of code. Semantic web and structured data on the wiki. They can independently host it or something. Wiki Data runs on Wikibase, which is beyond the version of semantic mediawiki.
Lawyers have said insightful things about bitcoin. "Let's automate property ownership" has been tried, but things always come back to the way things are currently, lessons from previous attempts. There is a legal markup language and it is based on arguments. Reddit tells you about things you didn't know existed sometime. Byzantine altruistic systems or something like that. You can look at random posts and find cool information. Random entry points for learning about bitcoin. Random wiki page.
Law is a source that is underrepresented for knowledge getting to devs. Needs to filter out. There's some nice annular essay events where a publication will send out an email to a few hundred people. edge.org is a good example. Invited articles on some topics. Annular process, these are all the topics. Maybe crowdfunding. Regular interviews.
webshows, podcasts, interviews. Those end up being really nice. Stackexchange has answered many questions and answers.
Ideal communication method might be based on what the community is comfortable with.
Real-time debate systemization, get short statements and show how they are related.
We have been talking about SNARKs now in -wizards for years. It has been spread across years of bitcoin logs. It is rare that we have a single thread about it. We had a chance to talk earlier today about SNARKs.
Point of reddit and stackexchange AMA style- to vote for questions that need answering, not for the answers. Perhaps that should be picked for what the topics are more effort to collect. "What are SNARKs" might pop up.
What's the difference between #bitcoin-dev and #bitcoin-wizards? Which ideas should go to one or the other? Somewhat unfair to send broken theoretical crypto to people working on mempool optimization.
Structured data can be submitted to a wiki.
Having a place to ask questions and filter them up, can someone please improve the public version of a SNARKs article. The general public usually gets left out.
Experts might be okay with looking up what the demand is for certain forms of knowledge. This may not be too burdensome.
Information might be too diffuse; some people prefer reddit, irc, stackexchange, people will miss things on each. Have a canonical authority, have a place where anyone can post links to other places.
Twitter has users with good cross-sections where they look at other users. In the bitcoin subreddit, you can't really subscribe to posts with a certain tag. Tag-based filtering would suffice for that. Not content tags, but person tags. That's the "who you get your data from" problem. What kind of data do I want you to send me? I want you to send me, some structured data, ... indicate a person, only relative to you, wihch topics tags you want, ... structure of the data that you receive, then the data will bloom and we will find ways to get parts that you like.
bottleneck of knowledge creation signal-noise
Signal-to-noise could work if there were more people that knew everything about bitcoin.
bitcoin.ninja has a bunch of old links- anyone can submit pull requests on github.
There's this social problem of creating or currating it. We can solve it through superheroes, data formats, or structure. Academia solved this problem by moving to a boring way of writing papers. The one thing that it does really well is if some idea is wrong, it's reported as wrong. All of that goes into that boring way of writing papers, it's for creating a graph of ideas and seeing what ideas survive to the next round. I think that has been super helpful. The way we do things in bitcoin is very helpful, things can happen on hours and days. But in the long-term maybe it would be better if we could find something in the middle. Even a tiny amount of gatekeeping, not as much as in academia. Peer review can be helpful, related work must be mandatory. Standard format. Every academic is supposed to demarcate where you are building on something already known, and where you are contributing a new idea. Most of the bitcoin community is like go straight to VHS video.
In academia there is a strong standard on pointing out how your work is different, and it's a cardinal sin to not point out that someone's work was not your own. Academic community also does mentorship, maybe the bottlenecks is how many people know this thing, count the bus factor. Every academic conference, some soul searching discussion about peer review, it's one of the biggest thing that people are upset about. Articulate your assumptions,
More contributors. Fewer people publishing ideas in bad formats. Way to measure signal-to-noise ratio, how do you measure it? half-written forum post, textbook chapters are usually relatively polished and you don't feel like you're wasting their time. Don't waste people's time. See an end of the phrase "check the logs". Time-consuming to check the logs.
in -wizards have a way to tag timestamps with the bot, just ask ".timestamp" and tag it.
don't waste people's time, "check the logs" but only once.
Academic committees are mostly arbitrary. Whether the reviews are rolling or have a fixed deadline wont matter. The way things are is because of inertia. Not too much of this needs to be imported. What do a couple of other people in the community think of this idea? This should be attached to the idea itself.
A more extreme example of that is the patent system, where there's an extreme format cost. It aciheves it through formatting and the patent office, some party vetting the idea. Paper rejected for the same format. Patents must have a specific format. Ideas should be standardized in the same format, like less formal than BIPs. or RFCs. Idea index. Style guide.. Everything in the index gets a page... we need a template for an idea that makes the problems we want to solve more clear, what the related work is, criticism.
Copy-and-paste from a wikipedia style guide.