Notes from the review meeting 2022-05-17

[kallerosenbaum]

I noted a few things that were said during the meeting (Nice to meet you all BTW). Please fill in all the stuff I missed.

• Highlight that it's important to read the linked resources and not just the summaries and quotes in the book.
• Some things can feel out of place and should be moved out, for example
  • Many paragraphs in "Miner decentralization" could be moved to a separate section.
  • https://github.com/kallerosenbaum/btcphilosophy/issues/25
• Maintainability over time. Small changes here and there will over time generate complex interactions that are hard to keep track of, for example, various configuration options. Another example of a maintainability issue are the Boost libraries that everyone wants to get rid of, but can't because external signing depends on them. Major headache. Things you put in there might have bad long-term effects.
• Translations and code comments: These can get outdated, and even dangerous if they are not up-to-date.
• Where does Bitcoin fit in the larger context, in the real world? A good example, is Maxwell's: a far bigger risk is that users don't care enough about decentralization.
• How do you keep knowledge between generations of developers? btcphilosopy is of course a help, but when it comes to specific code areas and such, knowledge in these areas will fade if their champions retire.
• Comments on PRs and issues are extremely valuable. They need to be preserved and used for a long time to come. How can we transfer that data in case we want to move the project from Github?
• How do we get rough consensus on consensus changes. How do you measure suppoort for a certain change?

[adamjonas]

hebasto: -- what does "verify" mean? weird coming from banking/other background? -- bitcoin is money, not just tech --> There should probably be some mention of soundness and the fact that money shouldn't break -- "you lose your keys; can't just reboot, your money is gone" -- money -> controlled supply -> accounting -> ledger -> ... -- would like to see this in book form

stephan: -- what are we trying to build here? -- what is the mission statement? -- prescriptive/descriptive -- asking questions/giving answers may risk becoming dated

aj: -- motivation, good to pose the problem a bit better before presenting the solutions -- utxos vs accounts; bitcoin script vs ...?, verification vs computation?

• The role of psudenonymnity
• dhruv - for the culture shock section: yes, this is a technology innovation but it requires social consensus before anything else. That's why people are so adamant and get so worked up about changes.
• also for that section the importance of patience in the development process

Format suggestions:

• put a short summary at the start of each chapter
• put discussion questions at the end of each section instead of only at the end

Why do we want miner decentralization? Mention selfish mining or why pools came to be (i.e. the centralizing effects) The definition of censorship was narrow

• what kind of censorship? Why does it matter?

• Should other things like energy usage and criminality be diffused in this doc or maybe there is a disclaimer that it won't be addressed?

• in https://rosenbaum.se/btcphil/#_layered_scaling section address the FUD that Bitcoin can’t do much - it’s boring and old and then use robot judge quote to address how much do you do on the base layer and where to do other things

[kallerosenbaum]

Thanks @adamjonas !

I'm going to need help prioritizing this. The big things we look for are severe omissions and fact errors, and among the above I find the following the most relevant, somewhat ordered by importance:

• Maintainability over time. Small changes here and there will over time generate complex interactions that are hard to keep track of, for example, various configuration options. Another example of a maintainability issue are the Boost libraries that everyone wants to get rid of, but can't because external signing depends on them. Major headache. Things you put in there might have bad long-term effects.
• How do we get rough consensus on consensus changes. How do you measure suppoort for a certain change?
• How do you keep knowledge between generations of developers? btcphilosopy is of course a help, but when it comes to specific code areas and such, knowledge in these areas will fade if their champions retire.
• Translations and code comments: These can get outdated, and even dangerous if they are not up-to-date.
• Mention selfish mining or why pools came to be (i.e. the centralizing effects)
• utxos vs accounts; bitcoin script vs ...?, verification vs computation?
• in https://rosenbaum.se/btcphil/#_layered_scaling section address the FUD that Bitcoin can’t do much - it’s boring and old and then use robot judge quote to address how much do you do on the base layer and where to do other things

Would you agree with this list and its ordering? I'm not sure any of these are particularly "severe omissions", but they are at least nice-to-haves.

Among the rest, I find these the most nice to have:

• motivation, good to pose the problem a bit better before presenting the solutions (same as "Why do we want miner decentralization?")
• put a short summary at the start of each chapter
• put discussion questions at the end of each section instead of only at the end

The definition of censorship was narrow

I need help understanding this. Could someone please expand on this?

[kallerosenbaum]

put a short summary at the start of each chapter

Fixed by https://github.com/kallerosenbaum/btcphilosophy/commit/2fdf1ecdb47f73baca9d5b36e701b75a98c581f4 thru https://github.com/kallerosenbaum/btcphilosophy/commit/fd870197dc9cffd1d055d4e8e1a021d412f1fd36

[adamjonas]

Adding some further notes from my own reading for posterity:

• the chapter about finite supply is really about the fact that we are building something for the long haul and we don't know the answers but we've got lots of time to deal with it. That's referenced in the summary of the chapter but I think that can be more explicitly emphasized throughout.
• in the Segwit upgrade section there asic boost story is worth mentioning. Segwit ultimately was a clever solution to a lot of problems and the motivations for the opposition were often unclear.
• In the speedy trial section, I think there is a good opportunity to reference the cultural shock section and refer to the conservative nature of the upgrades.
• in the conclusion of Finite supply I think there is an important point to make about security without centralization being new to humans but not to nature (see oak trees and schools of fish)
• regarding privacy - I think there needs to be mention of its difficulty privacy because "information wants to be free". Privacy is a one way door, you mess up once and it's broken.

[adamjonas]

I think pseudonymity is probably a must have to be added to the privacy section.

I've ordered the following by my own subjective criteria but maybe some of things from the comments above I made above are also interesting. I think these are all wants rather than needs though.

• verification vs computation approach - maybe in https://rosenbaum.se/btcphil/#_layered_scaling section?
• Maintainability over time - in culture shock
• Mention selfish mining or why pools came to be (i.e. the centralizing effects) - always be coming up with new solutions like compact blocks, FIBRE and stratum v2
• How do we get rough consensus on consensus changes. How do you measure support for a certain change? -This is a nice doc for that.
• in https://rosenbaum.se/btcphil/#_layered_scaling section address the FUD that Bitcoin can’t do much - it’s boring and old and then use robot judge quote to address how much do you do on the base layer and where to do other things
• utxos vs accounts - not sure this is philosophy
• Translations and code comments: These can get outdated, and even dangerous if they are not up-to-date.
• How do you keep knowledge between generations of developers? btcphilosopy is of course a help, but when it comes to specific code areas and such, knowledge in these areas will fade if their champions retire. -I don't think there is an answer for this

[kallerosenbaum]

I think pseudonymity is probably a must have to be added to the privacy section.

@adamjonas I added a section on pseudonymity in https://github.com/kallerosenbaum/btcphilosophy/commit/7cd22249d447ca9b7236118b060b587a7f7762b2, see https://rosenbaum.se/btcphil/#pseudonymity

[adamjonas]

I think what you have is a good addition but I was actually talking about contributing under a pseudonym to avoid legal/social pressures and to avoid attaching one's identity to one's code. Maybe this doesn't belong in this section but I think it belongs somewhere.

[kallerosenbaum]

Ok, that probably belongs in the open source chapter or under the neutrality section in decentralization.

[adamjonas]

Sorry. I should have been clearer.

[kallerosenbaum]

That's ok, but I'm not sure I can get that in this week.

[kallerosenbaum]

@adamjonas PR #35 adds pseudonymity to the "Permissionless development" section in the open source chapter. Please have a look if you have time.