#

software development

(17 articles)

Evaluating the Quantum Threat to Bitcoin

A common topic of discussion in the Bitcoin community is the potential threat that quantum computers may pose to Bitcoin. This issue is frequently raised by critics of Bitcoin, and sometimes it is used to dissuade people from converting their fiat paper into sound money. The purpose of this article is to provide an academically grounded explanation of how to evaluate the threat of quantum computing and its implications for Bitcoin. In general, quantum computers do represent a legitimate threat to certain aspects of Bitcoin and should be taken seriously by anyone who owns bitcoin. Specifically, the primary risk is to Bitcoin wallets and the cryptographic signatures used to authorize transactions. However, quantum computers do not pose the same threat to Bitcoin's network security. The integrity of the network, which is maintained through the distributed efforts of miners and node operators, is fundamentally different from the security of individual wallets and therefore requires a separate analysis. ### The Different Cryptography Behind Bitcoin To begin, it is important to understand that Bitcoin uses different forms of cryptography for different parts of its infrastructure, and quantum computers pose different risks to each. Bitcoin wallets are built on public-key cryptography, the system that allows users to control bitcoin with a private key while sharing a corresponding public key with the rest of the network. Your seed phrase ultimately derives these private keys, which are used to create digital signatures that prove ownership of your bitcoin without revealing the private key itself. Historically, Bitcoin has used the Elliptic Curve Digital Signature Algorithm (ECDSA) for this purpose, while newer Taproot addresses use Schnorr signatures. Although these signature schemes differ in design and efficiency, both rely on elliptic curve mathematics and would be vulnerable to a sufficiently powerful quantum computer running Shor's algorithm. Bitcoin mining, on the other hand, relies on an entirely different cryptographic primitive known as SHA-256 hashing. Hash functions serve a different purpose than digital signatures and are not vulnerable to Shor's algorithm. While quantum computers may provide a theoretical speed advantage when searching for hash values, they do not compromise SHA-256 in the same way they could compromise elliptic curve cryptography. This distinction is critical: the primary long-term quantum risk to Bitcoin is the security of wallet signatures and private keys, not the security of Bitcoin's proof-of-work mining system. ### The Vulnerability of Public-Key Cryptography The reason quantum computers pose a threat to Bitcoin wallets comes down to how public-key cryptography works. Under normal circumstances, it is computationally infeasible to derive a private key from a public key. This one-way mathematical relationship allows Bitcoin users to safely share public addresses while keeping control of their coins through a secret private key. However, Peter Shor demonstrated that a sufficiently powerful quantum computer could solve the discrete logarithm problems that underpin modern public-key cryptography, including elliptic curve systems (Shor 1995). Later work showed how this applies specifically to elliptic curve cryptography, including the type used by Bitcoin wallets (Proos and Zalka 2003). In practical terms, a cryptographically relevant quantum computer could potentially derive a private key from a publicly known key and use it to create valid signatures. This would allow an attacker to spend coins they do not own. Fortunately, this is a threat that can be managed. Bitcoin addresses do not always expose the underlying public key immediately. In many cases, the public key is revealed only when coins are spent from an address. For this reason, minimizing address reuse is generally considered a good security practice. The less frequently a public key is exposed on-chain, the smaller the potential attack surface should large-scale quantum computers eventually become available. ### Adapting Bitcoin to a Post-Quantum World The important takeaway is that the quantum threat is not an unsolved problem. If large-scale quantum computers become practical, Bitcoin users would likely need to migrate their funds to new address types secured by post-quantum signature schemes, much as the network has previously evolved from older address formats to SegWit and Taproot. The challenge is therefore not whether Bitcoin can adapt, but whether users migrate their coins to quantum-resistant wallets before quantum computers become capable of attacking existing signature systems. #### Keeping the Threat in Perspective It is also important to keep the quantum threat in perspective. While Shor's algorithm demonstrates that Bitcoin's signature schemes would be vulnerable to a sufficiently powerful quantum computer, current estimates suggest that the hardware required to perform such an attack remains far beyond what exists today (Aggarwal et al. 2018). Even optimistic forecasts for cryptographically relevant quantum computers place them years, and possibly decades, into the future. More importantly, the arrival of such systems is unlikely to be a surprise. Researchers, governments, and technology companies around the world are actively measuring progress in quantum computing, and the capabilities required to threaten Bitcoin are well understood. ### Which Bitcoin Is Most at Risk? If large-scale quantum computers do eventually become practical, some of the most vulnerable bitcoin would likely be older coins whose public keys have already been exposed on the blockchain for many years. This includes certain early Bitcoin outputs that reveal their public keys directly, such as the coins believed to belong to Satoshi Nakamoto. By contrast, many modern addresses provide an additional layer of protection because the public key is not revealed until coins are spent. While no one can predict exactly how a future quantum attack would unfold, the Bitcoin community would almost certainly receive advance warning through both developments in quantum computing and attempts to target the most exposed and valuable coins first. This would provide strong incentives for users to migrate their funds to quantum-resistant wallet standards long before the average holder faces a meaningful risk. ### Practical Takeaways for Bitcoin Holders The practical takeaway is simple: quantum computing is a real long-term issue, but it is not a reason to panic. Bitcoin holders should avoid keeping funds in addresses whose public keys have already been exposed, which means they should not store bitcoin in an address that has already been spent from. Users should stay informed as the Bitcoin ecosystem develops quantum-resistant wallet standards. When credible, well-reviewed quantum-resistant address types become available, users will have both the time and incentive to migrate. Until then, the core network remains secure. Bitcoin’s proof-of-work mining system is not the weak point in the quantum discussion. The responsible posture is to monitor developments, practice good wallet hygiene, and continue saving in bitcoin with confidence rather than fear. ## References Aggarwal, Divesh, Gavin Brennen, Troy Lee, Miklos Santha, and Marco Tomamichel. 2018. “Quantum Attacks on Bitcoin, and How to Protect against Them.” Ledger 3 (October). https://doi.org/10.5195/ledger.2018.127. Proos, John, and Christof Zalka. 2003. “Shor’s Discrete Logarithm Quantum Algorithm for Elliptic Curves.” arXiv [Quant-Ph]. arXiv. https://doi.org/10.48550/arXiv.quant-ph/0301141. Shor, Peter W. 1995. “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer.” arXiv [Quant-Ph]. arXiv. https://doi.org/10.48550/arXiv.quant-ph/9508027. # Postscript: Quantum Computing and the BIP-110 Discussion As an interesting aside, a current discussion within the Bitcoin community concerns how proposals such as BIP-110 could affect certain experimental approaches to quantum-resistant bitcoin custody. One such proposal, known as Quantum Signature Bitcoin (QSB), attempts to create quantum-resistant spending conditions without requiring a consensus change to Bitcoin itself. Rather than relying on elliptic curve signatures, which are vulnerable to Shor's algorithm, QSB derives its security from cryptographic hashing. This shifts security away from the same public-key cryptography used by Bitcoin wallets and toward a type of cryptography more closely related to the SHA-256 hashing used in Bitcoin mining. As discussed earlier, quantum computers are believed to pose a much smaller threat to hashing functions than they do to elliptic curve signature schemes. In simple terms, QSB works by embedding a large and highly specialized script directly into a Bitcoin transaction. Instead of proving ownership through a traditional ECDSA or Schnorr signature, the spender demonstrates knowledge of secret values that satisfy a series of cryptographic hash puzzles. This effectively shifts security away from the public-key cryptography that quantum computers are expected to break and toward hash-based cryptography, which is generally considered more resilient in a post-quantum world. The reason BIP-110 enters the discussion is that QSB relies on unusually large and complex scripts that fit within Bitcoin's current consensus rules but fall outside the design assumptions of standard modern address types. BIP-110 proposes stricter limits on script sizes and data pushes, which would prevent the creation of new QSB-style outputs after activation. As a result, supporters of QSB argue that proposals such as BIP-110 could unintentionally eliminate one potential path toward quantum-resistant bitcoin custody. Regardless of one's opinion on either proposal, the discussion itself illustrates an important point: Bitcoin developers are not ignoring the quantum challenge. Researchers are actively exploring multiple approaches to quantum-resistant wallets and transaction schemes. Increasingly, the debate is less about whether Bitcoin can adapt to a post-quantum world and more about which solutions are most practical, secure, and compatible with Bitcoin's long-term design goals.

สิ่งที่ Game Dev อยากบอก (แต่ตะโกนออกมาไม่ได้...) พร้อม 3 เคล็ดลับเอาตัวรอด! 💀⚡️

**เชื่อไหมครับว่า... เบื้องหลังฉากสวยๆ และเกมเพลย์ที่ลื่นไหล มันถูกยึดโยงไว้ด้วยเทปกาว สายไฟ และแรงอธิษฐานของ Developer ทั้งนั้น!** นี่คือ 3 เรื่องจริงที่คนทำเกมเจอ (แต่คนเล่นอาจไม่เคยรู้) “ แค่เพิ่มปุ่มเดียวเอง ” = ประโยคทำลายล้างที่แท้จริง เพราะภายใต้ปุ่มนั้นอาจหมายถึงการรื้อโครงสร้าง UI ใหม่ และต้องไล่เช็กว่ามันจะไม่ไปพังระบบ Save ที่ทำไว้ กฎ 90/90 = พัฒนาเกมไป 90% แรกใช้เวลาตามแผน... แต่อีก 10% ที่เหลือ (ช่วงเก็บงาน/แก้บั๊ก) กลับใช้เวลาอีก 90% ของเวลาทั้งหมด! The "Unpredictable" Players = เราสร้างทางเดินอย่างดีให้ไปทางขวา แต่ผู้เล่นจะพยายามปีนกำแพงออกนอกแมพทางซ้ายเสมอR 💡 [Bonus] 3 บทเรียนสำหรับคนที่อยากเริ่มต้น Game Dev ไหนๆ ก็บ่นแล้ว ขอแชร์เทคนิคที่ช่วยให้ชีวิต Developer ง่ายขึ้นจริงๆ ครับ > 1. Keep it Small (MVP): อย่าเพิ่งเริ่มที่ "Open World RPG" ในฝัน ให้เริ่มที่เกมเล็กๆ ที่จบใน 1 อาทิตย์ก่อน การทำเกมให้ "เสร็จ" สำคัญกว่าการทำเกมให้ "ใหญ่" > 2. Version Control คือชีวิต: อย่าตั้งชื่อไฟล์ว่า Game_Final_v2_RealFinal.zip ให้ใช้ Git ตั้งแต่วันแรก เพราะถ้า Code พังตอนตีสาม คุณจะกราบตัวเองที่ทำระบบ Backup ไว้ > 3. Community Over Competition: ในโลกของ Indie Dev เราไม่ได้แข่งกันเอง การเข้ากลุ่ม Discord หรือโพสต์ลง Nostr/YakiHonne เพื่อขอ Feedback จะช่วยให้คุณเห็นบั๊กที่ตัวเองมองข้ามไปเป็นเดือน การเป็น Game Developer คือศิลปะของการประนีประนอมระหว่าง "จินตนาการ" กับ "ทรัพยากรที่มีจำกัด" ใครที่กำลังนั่งแก้บั๊กข้ามคืน หรือกำลังงมกับ Code ที่ตัวเองเขียนเมื่อวานแต่จำไม่ได้แล้ว... คุณไม่ได้สู้ดวงเดียวครับ! 👨‍💻☕️ `$$printf("Hello, World!");$$` #GameDev #LearningToCode #IndieDevTips #Nostr #SoftwareEngineering #DeveloperCommunity #siamtrs

Reimagining the Product Development Life Cycle in 2025

The traditional product development lifecycle is undergoing a profound transformation. Powered by AI tools evolving at a scarcely believable pace, 2025 promises to revolutionize how we conceive, build, and iterate on products, offering unprecedented efficiency and innovation. In this post, I'm going to lay out how the seven traditional stages of the PDLC can be accelerated by 5-10x with existing tools. It's worth pointing out that these capabilities I'm listing are current as of February 11 2025. It is very possible that these all get upended by something even better by March or April! ## 1. Ideation and Market Research The first phase of product development is supercharged by AI's ability to analyze vast datasets and identify trends. Tools like AlphaSense and Google Gemini 2.0 can sift through financial reports, social media chatter, and market analyses to distill actionable insights in a fraction of the time it would take human researchers. This AI-augmented ideation process doesn't replace human creativity but amplifies it, allowing teams to explore a broader range of possibilities and make data-driven decisions from the outset. _[Note, I'm not even touching on OpenAI's Deep Research Model that was released last week, which from all the initial reaction, will likely be a massive improvement on the models above]_ ## 2. Requirements Gathering and User Story Generation AI models like Tara AI and Claude 3.5 Sonnet excel at translating abstract business objectives into detailed user stories and technical specifications. These tools can analyze workflows, integrate with existing systems, and generate comprehensive requirements documents. While AI streamlines this process, product managers still play a crucial (but perhaps diminishing over the next few years) role in refining and validating these AI-generated outputs, ensuring alignment with business goals and human needs. ## 3. Design and Prototyping The design phase is revolutionized by tools like Adobe Firefly and Neurons Predict AI. These AI systems can generate high-fidelity prototypes based on text prompts and even simulate user behavior to optimize UI/UX designs. Human designers remain essential, infusing prototypes with creativity and emotional resonance that AI alone cannot provide. ## 4. Development and Implementation AI coding assistants like GitHub Copilot X and Claude 3.5 Sonnet, and more recently, DeepSeek R1 and o3-mini, are transforming the development process. These tools can generate code, assist with debugging, and accelerate development workflows. However, human developers are still crucial for overseeing critical logic, ensuring security compliance, and making high-level architectural decisions. ## 5. Quality Assurance AI-driven QA tools like ACCELQ Autopilot and Appvance IQ automate test case creation, execution, and maintenance. These systems can adapt to application changes in real-time, significantly reducing the manual effort required in testing. Human QA engineers focus on validating critical test cases and ensuring overall product reliability. ## 6. Deployment Deployment is streamlined with AI-powered tools like Harness CI/CD and AWS SageMaker. These systems automate deployment pipelines and use machine learning to detect potential failures proactively. Human DevOps teams oversee these processes, ensuring smooth rollouts and managing any unforeseen issues. ## 7. Post-Launch Monitoring and Iteration AI excels in post-launch monitoring, with tools like Arize AI and Weights & Biases providing real-time insights and actionable analytics. These systems can detect usage patterns, identify areas for improvement, and even suggest optimizations. Product teams use these AI-generated insights to prioritize updates and guide the product's evolution. By leveraging AI throughout the product development lifecycle, teams can dramatically reduce time-to-market while maintaining or even improving product quality. This AI-driven approach doesn't eliminate the need for human expertise but rather enhances it, allowing teams to focus on higher-level strategic decisions and creative problem-solving. The future of product development lies in this symbiosis between human ingenuity and AI capabilities. As these AI tools continue to evolve, we can expect even greater efficiencies and innovations in the PDLC, ultimately leading to better products that more closely align with user needs and market demands.

Contributing to FOSS as a Product Person without Permission

### a practical intro to contributing to FOSS for product people, and other non-devs So you want to contribute to FOSS, but don’t know where to start. There are many paths to FOSS, but you must find your own. Here’s some advice based on personal experience to help you get started. ### 0. Find your motivation FOSS requires a lot of giving, and better aligns with those that are missionaries, as opposed to the mercenaries. Perhaps you are unfulfilled in your fiat job, maybe you are currently unemployed, or perhaps you are excited about a particular bitcoin project. Why you’re exploring contributing to FOSS, is a question that only you can answer. ![image](https://yakihonne.s3.ap-east-1.amazonaws.com/17538dc2a62769d09443f18c37cbe358fab5bbf981173542aa7c5ff171ed77c4/files/1727887860405-YAKIHONNES3.webp) Are you a missionary? ### 1. Discover what excites you So you’ve found motivation and have a list of various FOSS projects you could contribute to. This is the equivalent of the “I need a job” stage and you’re figuring out where to apply. It’s time to narrow it down. What are you excited about? A multi-year pilgrimage of learning how to contribute to Bitcoin Core? A lightning wallet, perhaps? Free speech Nostr? A hardware signing device? Or maybe finding a FOSS projects that is not “Bitcoin” in name, but happens to support Bitcoin, and Lightning. A great first step is to take some time and explore the Bitcoin Design Community (https://bitcoin.design/) to discover FOSS projects. ![image](https://yakihonne.s3.ap-east-1.amazonaws.com/17538dc2a62769d09443f18c37cbe358fab5bbf981173542aa7c5ff171ed77c4/files/1727887833560-YAKIHONNES3.webp) Are you excited anon? ### 2. Identify the skills you have or want to develop Chances are that if you follow the Bitcoin Product Community, you’re skills are in Product Management, Product Marketing, and/or Project Management. But contributing to a bitcoin project requires contributors with skills of many backgrounds such as marketing, documentation, community building, and more. What’s important to know is that most FOSS teams start with a motivated developer, who then may attract other devs. But many of them may not advertise that they need non-developer help such as a PM. Therein lies the opportunity for you as an eager bitcoin contributor. See what the needs of a project are and see if you can fill in those gaps with your skills. It may be as simple as coordinating meetings for the team. But doing the “dirty work”, or the work no one else wants to do, is exactly the way you can make an immediate impact to a FOSS project. In fact, this is why members of the Bitcoin Product Community affectionately refer to product managers as “[janitors](https://medium.com/all-things-product-management/product-manager-you-are-664d83ee702e)”! ### 3. Make a list of projects Now that you have narrowed down your FOSS search, it is time to start building a list of, and evaluating various FOSS products. Some questions you can ask yourself: Is the project active? Is it a new project? How many team members are there? How many are devs? Is there already a PM? Is there a need for multiple PMs? Is there designer participation? What is the pace of development? Is there enough development activity for this to satisfy your want to contribute? Is there opportunity for a PM? Github is the defacto standard for FOSS products. Check the activity. Read up on issues. See who is contributing PRs, and creating issues. Check if there is a Github Project instance. It’s OK, and best for you to check out out multiple FOSS projects concurrently to see which team is the best fit for both parties. ### 4. Use the thing(s)! Another thing you can do to help you choose a project is to use the thing! Download the OS. Run the software. Use it. As you’re interacting with the product, some things you can ask yourself are: What do you love about the product? What can be improved? Are there bugs? Jot down your notes. Take screenshots. Do screen recordings. Document your experience. Create a video onboarding walkthrough, or a feature tutorial. What you are actually doing is documentation and this will be useful for the project, even if you don’t decide to actively contribute. As you use the thing, take note of how you’re reacting to it. Are you getting more or less excited? Are you more or less confident in contributing to the project? ### 5. Find out where the team works Another factor to consider is to figure out where the team works. By now you have already explored their github to collect your FOSS intelligence. Now check nostr, twitter, telegram, or whatever other comms tools the team might be using. Some teams may have calls, and call recordings. Consider listening in to a recording, and/or joining a call to check the team dynamics. As you do, assess whether you might be a good culture fit. Also see where there might be some gaps in their workflow that you can help improve. ### 6. Start small Once you found a project that interests and excites you enough. It’s time to roll up your sleeves and get involved by starting small. One easy place to start is to go through the github issues list. Some examples of issues in dev heavy teams are e extremely technical bug reports. For FOSS products with an active user base, there might be “customer” centric feature requests. Start by logging the bug(s) you found. Examine issues, and fill in the blanks if there are unclearly defined reports & requests. You don’t have to ask for permission to contribute. That said, evaluate team dynamics and who owns what role so you are not stepping on anyone’s toes. You are there to help. Also take note of how your help is received. It may take time for you to build up your credibility. Don’t throw in the towel on the first week. Keep finding ways to add value. ### 7. Show up consistently Keep contributing in small things day in and day out. As you do so, communicate with the team to ramp up your learning, and also start building rapport, and your reputation. You may not have time or opportunity to contribute full-time. With the state of asynchronous communication tools in 2023, you can flexibly contribute when you have time. An exception to the asynchronous communication may be team meetings. As you continue to show up consistently, you will build up your FOSS proof-of-work, and reputation. This will show FOSS devs, and contributors that you bring value. ### 8. Find and meet the “customer” Find, and interact with the project’s users a.k.a “customers”. What do they care about? What are their pain points? What needs are customers using the product for? Become the “voice of the customer” to the dev heavy team. Is there a conference where your team is presenting, and customers present? These are invaluable opportunities to observe the customer’s behavior, and also to help answer questions, and troubleshoot on the spot. ### 9. Increase your involvement After some time starting small and working on bugs, you may eventually find yourself submitting feature requests. Maybe there is an opportunity to create user flows, or mockups. As you consistently contribute, continue seeking more responsibility. Maybe you offer to facilitate and lead the next team call. Maybe you try creating a roadmap and backlog from scratch. Maybe you host a product & design thinking session. Maybe you will level up and learn how to check out a dev’s PR in a yet-to-released branch. No matter what you do, be sure to always bring value to the project. ![image](https://yakihonne.s3.ap-east-1.amazonaws.com/17538dc2a62769d09443f18c37cbe358fab5bbf981173542aa7c5ff171ed77c4/files/1727887803685-YAKIHONNES3.webp) Testing an unreleased Damus branch checked out on XCode ### 10. Prune, Commit, Repeat Congratulations! By now you’ve been doing a “trial run” with several projects. It’s time to focus and choose one(s) that you can commit to. As you contribute to the project on an ongoing basis, continuously reevaluate if there is opportunity for you to increase your contributions. If you feel that you’ve maxed that out, it may be time to look for a different FOSS product to contribute to. Perhaps a complementary product to your initial one. As you embark on this journey, it can be exhilarating at times and in other times thankless. To find a community of peers, and perhaps a mentor check in with the Bitcoin Product Community [Discord](https://discord.gg/Ztvwn8fycA), and introduce yourself. The beauty of open source is people are willing to help FOSS products, and to answer your questions. [https://youtu.be/ZUgQPR6ecuo ](https://youtu.be/ZUgQPR6ecuo )“FOSS is the way” - Rockstar dev, @ Advancing Bitcoin Conference London 2023. The author thanks Rockstar for inspiration, and guidance through my FOSS journey. As you continue to sweep the FOSS floors with your product [mop](https://medium.com/all-things-product-management/product-manager-you-are-664d83ee702e), remember that you are contributing to the mission that you believe in. You are working in the open, with even less authority than a PM at a company might have, and as a result leveling up. You build up your reputation in FOSS, and you show others your capabilities in the FOSS world (and also prospective employers, and co-founders) by doing. Hopefully this helps you get started. Reach out to [elsat on nostr](https://njump.me/npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5) if you have questions about the FOSS journey, and join the Bitcoin Product Community Discord.