From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 16 Oct 2024 17:55:27 -0700 Received: from mail-yb1-f184.google.com ([209.85.219.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t1EnW-0003ES-NB for bitcoindev@gnusha.org; Wed, 16 Oct 2024 17:55:27 -0700 Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e29135d1d0csf784108276.1 for ; Wed, 16 Oct 2024 17:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1729126520; x=1729731320; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=aAEQr2RbN4iP5pKnubWlD8ukpsmPjT9FdmL/ggPhHUg=; b=jBHffL5MNPhf/KSXXlMuZsn+pIF9aqtucKWFAEqensU+TPBKH35Ooi5IpvPQhQmwxG sy1njyrbgEYGIq5SSA/ioXDW/cSKorP2TGMt+V10x6pgnASk+9CD0CFRELBlYGv6oxI5 j7TvXedmhNcoFJ6Eoh1xJ/FLVeSpwY2wxfSivh9r+ZkUGTpTGtBj2yOO8wJS5VLxGCqA HKif2CtddbtImejwxzUEveGwGlIVgNAIS8QKw4f6phkY5Zq1YjJ/oZ9NRvzLJE5tLSMF 4JOBXA+GunaSCngFjrGUClflgETN5I8QCaarJ/7iLOzBGbJ0xSNcREsYQ8azoKxpIkFf UfcA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729126520; x=1729731320; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=aAEQr2RbN4iP5pKnubWlD8ukpsmPjT9FdmL/ggPhHUg=; b=fKdradQ1zrMele6SOzQl1oR5iGRyl2rzD3Gt6oXgkuTtPoZD+DcNed80mTxidfHdPM Pe1pA7unbsEJLj3UioEs92UD08KyXWtDFQoNsXuCYK06pgogVcQXTwsd92e5rzW/zV+6 22NB8PHSwpSRLEmZcyQVlaJxi/bcNJmY/9X36StQBBqVxD/Px3cUATdVfWEJgOOo4juD gmPUwSv+/GCqpafk4K+HHRvD+JUkYuGpnAm3QlwzwUdgUJoZ0LwTu3SmF39eF8PPqCTA tRw0s2k0tpJkYled8sOkRJFIoBTYglHW1gNTT9K5VTth1gLDdfaPpA+BeJIPk1IUNVXe FsMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729126520; x=1729731320; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=aAEQr2RbN4iP5pKnubWlD8ukpsmPjT9FdmL/ggPhHUg=; b=OHkTXSlaBfeqed3PuiJ+0KvAxJnKuFRLyCv+bjcj3ZQl4tPQrDrlONHFWptrZ9Yy8a 89H6S897KcgfVDuAi0S/Ds7iry+S/pXoUilt7a7K4K8aesH7Vomjvj0i/guPJIw/waIa Wzdb7ceuf/sQ9nSLaKh1drlyU/v6c7ctkygmFIwbRCtB7d3LnF6kUOShK5Z37lU+Ql3o r5zxHeGwC7RDe+ttPjkpHH4bLJ85lQGN454QBJJPeBU841OOX5EQ4Y2LtkvOrgKsSCan J/SMTqOPJ8mm0DiCFIM8EjNlm5iJv72hzUxFGi/aAJ9tO5j59IpqzmWpK2FcCRPrJAG1 Pz/A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUyPedqeZ/ZJINUb5PlT/X0E5C30+NLlH8l7LRHRU6Av+1KsAiXBBQDVh/XSCbkzUIqo8keSB9gF88o@gnusha.org X-Gm-Message-State: AOJu0YyfyFQZzGla+Zoiw+1zmu1Ggzon09h0bjP7LtpL5L9KaKy7DYOZ /ikfygVxcYhZ1Yg/yX8e8FJsK6FT5ghLtHDUJoiXoSxeE8e2KnMl X-Google-Smtp-Source: AGHT+IEqTzsV56+aCU69Tx/Nb5RoLEAEEIuLB6LlTiryU+FgyzWSdF9V0in7sy1PrWftc7JmQ8RJcQ== X-Received: by 2002:a05:6902:1611:b0:e29:948:55fc with SMTP id 3f1490d57ef6-e2919d61598mr19010823276.10.1729126520111; Wed, 16 Oct 2024 17:55:20 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:726:b0:e28:e985:da9 with SMTP id 3f1490d57ef6-e2b9ce33831ls534781276.2.-pod-prod-07-us; Wed, 16 Oct 2024 17:55:17 -0700 (PDT) X-Received: by 2002:a05:690c:d8f:b0:6e0:5d7:8432 with SMTP id 00721157ae682-6e3d407c534mr62311027b3.5.1729126517835; Wed, 16 Oct 2024 17:55:17 -0700 (PDT) Received: by 2002:a05:690c:dd0:b0:6dd:f386:13dc with SMTP id 00721157ae682-6e3d73b63d0ms7b3; Wed, 16 Oct 2024 17:45:30 -0700 (PDT) X-Received: by 2002:a05:6902:2003:b0:e29:20a5:8b26 with SMTP id 3f1490d57ef6-e2931bca88amr12862365276.43.1729125929997; Wed, 16 Oct 2024 17:45:29 -0700 (PDT) Date: Wed, 16 Oct 2024 17:45:29 -0700 (PDT) From: scott beeker To: Bitcoin Development Mailing List Message-Id: <0e40068e-6840-49a2-a800-a1f34a0ad9ccn@googlegroups.com> Subject: [bitcoindev] Hardforking Bitcoin to SLH-DSA (Future Proofing) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_114668_576186209.1729125929768" X-Original-Sender: devbythebay2@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_114668_576186209.1729125929768 Content-Type: multipart/alternative; boundary="----=_Part_114669_1085048807.1729125929768" ------=_Part_114669_1085048807.1729125929768 Content-Type: text/plain; charset="UTF-8" Hardforking Bitcoin to SLH-DSA Bitcoin's transition to a post-quantum cryptographic algorithm like SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) would be a significant and complex undertaking. Here's an analysis of the potential process and implications: Motivation for the Transition The primary reason for considering a transition to SLH-DSA would be to protect Bitcoin against potential threats from quantum computers. While quantum computers capable of breaking Bitcoin's current elliptic curve cryptography are not yet a reality, the cryptocurrency community is increasingly aware of the need to prepare for this eventuality. Technical Aspects of the Transition Signature Scheme Replacement The current Bitcoin protocol uses the Elliptic Curve Digital Signature Algorithm (ECDSA) for transaction signatures. Replacing this with SLH-DSA would require substantial changes to the core protocol[1]. Key and Signature Sizes One of the main challenges in implementing SLH-DSA for Bitcoin would be dealing with the increased key and signature sizes: Algorithm Public Key Size Signature Size ECDSA 33 bytes 71-73 bytes SLH-DSA 32-64 bytes 7,856-49,216 bytes The significantly larger signature sizes of SLH-DSA would have implications for block size, transaction throughput, and network bandwidth requirements[1]. Performance Considerations SLH-DSA is known for its strong security properties but comes with performance costs. It has longer signing times compared to ECDSA, which could affect transaction processing speeds[1]. Implementation ChallengesConsensus Changes Implementing SLH-DSA would require a hard fork of the Bitcoin network, as it involves fundamental changes to the consensus rules. This would need widespread agreement among miners, node operators, and users. Backward Compatibility The transition would need to address backward compatibility issues, potentially requiring a period where both ECDSA and SLH-DSA signatures are supported to allow users time to migrate their funds to new addresses. Wallet Software Updates All Bitcoin wallet software would need to be updated to support the new signature scheme, including key generation, signing, and verification processes. Potential BenefitsQuantum Resistance The primary benefit would be Bitcoin's resistance to attacks from quantum computers, ensuring the long-term security of the network[1]. Conservative Security Approach SLH-DSA is considered a conservative choice for post-quantum cryptography, as it relies on the well-studied security of hash functions rather than newer mathematical problems like lattices[1]. Potential DrawbacksIncreased Resource Requirements The larger signature sizes would increase the storage and bandwidth requirements for running Bitcoin nodes, potentially leading to increased centralization. Transaction Costs Larger signatures could result in higher transaction fees, as more blockchain space would be required for each transaction. Complexity The transition process itself would be complex and risky, potentially introducing vulnerabilities if not executed correctly. Conclusion While transitioning Bitcoin to SLH-DSA is technically possible, it would be a monumental undertaking requiring extensive planning, testing, and community consensus. The cryptocurrency community would need to carefully weigh the long-term security benefits against the short-term disruption and increased resource requirements. As quantum computing advances, this topic is likely to become increasingly relevant in discussions about Bitcoin's future. Citations: [1] We wrote the code, and the code won | Trail of Bits Blog https://blog.trailofbits.com/2024/08/15/we-wrote-the-code-and-the-code-won/ [2] SLotH -- An SLH-DSA/SPHINCS+ Hash-Based Signature Accelerator https://github.com/slh-dsa/sloth [3] Cryptographic Right Answers: Post Quantum Edition - Latacora https://www.latacora.com/blog/2024/07/29/crypto-right-answers-pq/ Is your feature related to a problem, if so please describe it. https://www.csoonline.com/article/3562701/chinese-researchers-break-rsa-encryption-with-a-quantum-computer.html/amp/ -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/0e40068e-6840-49a2-a800-a1f34a0ad9ccn%40googlegroups.com. ------=_Part_114669_1085048807.1729125929768 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hardforking Bitcoin t= o SLH-DSA

Bitcoin's t= ransition to a post-quantum cryptographic algorithm like SLH-DSA (Stateless= Hash-Based Digital Signature Algorithm) would be a significant and complex= undertaking. Here's an analysis of the potential process and implications:=

Motivation for the Transition

The primary reason for considering a transi= tion to SLH-DSA would be to protect Bitcoin against potential threats from = quantum computers. While quantum computers capable of breaking Bitcoin's cu= rrent elliptic curve cryptography are not yet a reality, the cryptocurrency= community is increasingly aware of the need to prepare for this eventualit= y.

Technical Aspects of the Transition=C2=A0
Signature Scheme Replacement

The current Bitcoin protocol uses the Elliptic Curve Digital Signa= ture Algorithm (ECDSA) for transaction signatures. Replacing this with SLH-= DSA would require substantial changes to the core protocol[1].

Key and Sign= ature Sizes

One of th= e main challenges in implementing SLH-DSA for Bitcoin would be dealing with= the increased key and signature sizes:


Algorithm
Public Key Size
Signature Size
ECDSA
33 bytes
71-73 bytes
S= LH-DSA32-64 bytes
7,856-49,216 bytes

The significantly larger signature siz= es of SLH-DSA would have implications for block size, transaction throughpu= t, and network bandwidth requirements[1].

Performance Considerations=

SLH-DSA is known for its st= rong security properties but comes with performance costs. It has longer si= gning times compared to ECDSA, which could affect transaction processing sp= eeds[1].

Implementation ChallengesConsensus Chang= es

Implementing SLH-D= SA would require a hard fork of the Bitcoin network, as it involves fundame= ntal changes to the consensus rules. This would need widespread agreement a= mong miners, node operators, and users.

Backward Compatibility

The transition would need to addr= ess backward compatibility issues, potentially requiring a period where bot= h ECDSA and SLH-DSA signatures are supported to allow users time to migrate= their funds to new addresses.

Wallet Software Updates

All Bitcoin wallet software would need to= be updated to support the new signature scheme, including key generation, = signing, and verification processes.

Potential Benefi= tsQuantum Resistance

The primary benefit would be Bitcoin's resistance to attacks from quant= um computers, ensuring the long-term security of the network[1].

Conservati= ve Security Approach

= SLH-DSA is considered a conservative choice for post-quantum cryptography, = as it relies on the well-studied security of hash functions rather than new= er mathematical problems like lattices[1].

Potential = DrawbacksIncreased Resource Requirements

The larger signature sizes would increase the stora= ge and bandwidth requirements for running Bitcoin nodes, potentially leadin= g to increased centralization.

Transaction Costs

Larger signatures could result in higher transa= ction fees, as more blockchain space would be required for each transaction= .

The tran= sition process itself would be complex and risky, potentially introducing v= ulnerabilities if not executed correctly.

Conclusion<= /span>

While transitioning B= itcoin to SLH-DSA is technically possible, it would be a monumental underta= king requiring extensive planning, testing, and community consensus. The cr= yptocurrency community would need to carefully weigh the long-term security= benefits against the short-term disruption and increased resource requirem= ents. As quantum computing advances, this topic is likely to become increas= ingly relevant in discussions about Bitcoin's future.

Citations:
[1] We wrote the code, and the code won | Trail of Bits Blog=C2=A0https://blog.trailofbits.com/2024/08/15/we-wrote-the-code-and-the-code= -won/
[2] SLotH -- An SLH-DSA/SP= HINCS+ Hash-Based Signature Accelerator=C2=A0https:= //github.com/slh-dsa/sloth
[3] C= ryptographic Right Answers: Post Quantum Edition - Latacora=C2=A0https://www= .latacora.com/blog/2024/07/29/crypto-right-answers-pq/

Is your feature = related to a problem, if so please describe it.

bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/0e40068e-6840-49a2-a800-a1f34a0ad9ccn%40googlegroups.com.=
------=_Part_114669_1085048807.1729125929768-- ------=_Part_114668_576186209.1729125929768--