bitcoindev  

Messages by Thread

• • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Ethan Heilman
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Matt Corallo
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Alex
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Matt Corallo
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms waxwing/ AdamISZ
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Matt Corallo
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Matt Corallo
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms waxwing/ AdamISZ
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Matt Corallo
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms 'Brandon Black' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Ethan Heilman
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms 'moonsettler' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Ethan Heilman
  • Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms 'moonsettler' via Bitcoin Development Mailing List
• [bitcoindev] New bitcoin backbone code release: BIP152, outbound tx support + libbitcoinkernel API feedbacks Antoine Riard
• [bitcoindev] BIP-352: Limiting the number of per-group recipients (K_max) Sebastian Falbesoner
  • [bitcoindev] Re: BIP-352: Limiting the number of per-group recipients (K_max) Sebastian Falbesoner
  • [bitcoindev] Re: BIP-352: Limiting the number of per-group recipients (K_max) Sebastian Falbesoner
  • [bitcoindev] Re: BIP-352: Limiting the number of per-group recipients (K_max) Sebastian Falbesoner
• [bitcoindev] SImple quantum security, at the expense of slower tx time Erik Aronesty
• [bitcoindev] libsecp256k1 0.7.1 released Pieter Wuille
• [bitcoindev] SLH-DSA verification can compete with ECC 'conduition' via Bitcoin Development Mailing List
  • Re: [bitcoindev] SLH-DSA verification can compete with ECC 'Mikhail Kudinov' via Bitcoin Development Mailing List
• [bitcoindev] Garbled Circuit and Channel Jamming Antoine Riard
• [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal Giulio Golinelli
  • [bitcoindev] Re: Falcon Post-Quantum Signature Scheme Proposal waxwing/ AdamISZ
  • Re: [bitcoindev] Re: Falcon Post-Quantum Signature Scheme Proposal Giulio Golinelli
  • Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 'conduition' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal Giulio Golinelli
  • Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 'Mikhail Kudinov' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal waxwing/ AdamISZ
  • Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal cassio gusson
  • Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 'Mikhail Kudinov' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal waxwing/ AdamISZ
  • Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 'conduition' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal Giulio Golinelli
  • Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 'conduition' via Bitcoin Development Mailing List
• [bitcoindev] Re: [bitcoin-dev] Unbreaking testnet4 'Angelo' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Re: [bitcoin-dev] Unbreaking testnet4 Saint Wenhao
  • [bitcoindev] Re: [bitcoin-dev] Unbreaking testnet4 'Angelo' via Bitcoin Development Mailing List
  • [bitcoindev] Re: [bitcoin-dev] Unbreaking testnet4 'Angelo' via Bitcoin Development Mailing List
  • [bitcoindev] Re: [bitcoin-dev] Unbreaking testnet4 'Angelo' via Bitcoin Development Mailing List
• [bitcoindev] QRAMP addition: Alternative to legacy freeze: “quarantine-mode” legacy spends via two-phase destination commitment 'bnv' via Bitcoin Development Mailing List
  • [bitcoindev] Re: QRAMP addition: Alternative to legacy freeze: “quarantine-mode” legacy spends via two-phase destination commitment Giulio Golinelli
  • Re: [bitcoindev] Re: QRAMP addition: Alternative to legacy freeze: “quarantine-mode” legacy spends via two-phase destination commitment 'bnv' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Re: QRAMP addition: Alternative to legacy freeze: “quarantine-mode” legacy spends via two-phase destination commitment Giulio Golinelli
• [bitcoindev] Safe Redaction: an early draft BIP Lazy Fair
• [bitcoindev] Bitcoin Core v30.2 Released fanquake
• [bitcoindev] Bitcoin Core v30.2rc1 Released fanquake
  • Re: [bitcoindev] Bitcoin Core v30.2rc1 Released /dev /fd0
• [bitcoindev] BIP Idea: incrementalrelayfee in feefilter? Matthew Husák
  • Re: [bitcoindev] BIP Idea: incrementalrelayfee in feefilter? Murch
  • Re: [bitcoindev] BIP Idea: incrementalrelayfee in feefilter? Matthew Husák
• [bitcoindev] Follow-up regarding Motion to Activate BIP 3 Murch
  • Re: [bitcoindev] Follow-up regarding Motion to Activate BIP 3 Chris Stewart
  • Re: [bitcoindev] Follow-up regarding Motion to Activate BIP 3 Jonas Nick
  • Re: [bitcoindev] Follow-up regarding Motion to Activate BIP 3 Murch
  • Re: [bitcoindev] Follow-up regarding Motion to Activate BIP 3 Ruben Somsen
  • Re: [bitcoindev] Follow-up regarding Motion to Activate BIP 3 Bryan Bishop
  • Re: [bitcoindev] Follow-up regarding Motion to Activate BIP 3 Coperbyte Solutions
  • Re: [bitcoindev] Follow-up regarding Motion to Activate BIP 3 Tim Ruffing
  • Re: [bitcoindev] Follow-up regarding Motion to Activate BIP 3 Murch
• [bitcoindev] Wallet Migration Failure May Delete Unrelated Wallet Files In Bitcoin Core 30.0 and 30.1 'Ava Chow' via Bitcoin Development Mailing List
• [bitcoindev] Bitcoin Core v30.1 Released fanquake
• [bitcoindev] Re: Funding model question — unpaid exploratory work at intake Able One
  • Re: [bitcoindev] Re: Funding model question — unpaid exploratory work at intake Chris Stewart
• [bitcoindev] Addressing remaining points on BIP 54 'Antoine Poinsot' via Bitcoin Development Mailing List
  • [bitcoindev] Re: Addressing remaining points on BIP 54 Antoine Riard
  • Re: [bitcoindev] Addressing remaining points on BIP 54 Sjors Provoost
  • Re: [bitcoindev] Addressing remaining points on BIP 54 Matt Corallo
  • Re: [bitcoindev] Addressing remaining points on BIP 54 Antoine Riard
  • Re: [bitcoindev] Addressing remaining points on BIP 54 Mubarek Juhar
  • Re: [bitcoindev] Addressing remaining points on BIP 54 Matt Corallo
  • Re: [bitcoindev] Addressing remaining points on BIP 54 Antoine Riard
  • Re: [bitcoindev] Addressing remaining points on BIP 54 Murch
  • Re: [bitcoindev] Addressing remaining points on BIP 54 Sjors Provoost
  • Re: [bitcoindev] Addressing remaining points on BIP 54 'Antoine Poinsot' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Addressing remaining points on BIP 54 Murch
  • Re: [bitcoindev] Addressing remaining points on BIP 54 Antoine Riard
  • Re: [bitcoindev] Addressing remaining points on BIP 54 'Antoine Poinsot' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Addressing remaining points on BIP 54 Antoine Riard
• [bitcoindev] BIP idea: Timelock-Recovery storage format 'Oren' via Bitcoin Development Mailing List
  • [bitcoindev] Re: BIP idea: Timelock-Recovery storage format waxwing/ AdamISZ
  • [bitcoindev] Re: BIP idea: Timelock-Recovery storage format 'Oren' via Bitcoin Development Mailing List
  • [bitcoindev] Re: BIP idea: Timelock-Recovery storage format 'Oren' via Bitcoin Development Mailing List
  • [bitcoindev] Re: BIP idea: Timelock-Recovery storage format 'orenz0' via Bitcoin Development Mailing List
  • [bitcoindev] Re: BIP idea: Timelock-Recovery storage format 'orenz0' via Bitcoin Development Mailing List
• [bitcoindev] QRMVL: Modular Verification Layer for Post-Quantum Hash-Based Signatures Karin Eunji
• [bitcoindev] CTV activation meeting #1 Notes /dev /fd0
• [bitcoindev] Major BIP 360 Update Hunter Beast
  • Re: [bitcoindev] Major BIP 360 Update Erik Aronesty
• [bitcoindev] Secondary mailing list for moderated emails /dev /fd0
• [bitcoindev] [BIP Proposal] Peer Feature Negotiation Anthony Towns
  • [bitcoindev] Re: [BIP Proposal] Peer Feature Negotiation Antoine Riard
  • Re: [bitcoindev] Re: [BIP Proposal] Peer Feature Negotiation Anthony Towns
• [bitcoindev] Perhaps the simplest possible quantum-security upgrade Erik Aronesty
  • [bitcoindev] Re: Perhaps the simplest possible quantum-security upgrade Erik Aronesty
  • Re: [bitcoindev] Re: Perhaps the simplest possible quantum-security upgrade 'conduition' via Bitcoin Development Mailing List
• [bitcoindev] [BIP Proposal] Add PSBT_IN_SP_TWEAK field 'nymius' via Bitcoin Development Mailing List
• [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? Josh Doman
  • Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? Greg Maxwell
  • Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? Josh Doman
  • Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? Antoine Riard
  • Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? 'Russell O'Connor' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? Josh Doman
  • Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? Henry Romp
  • Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? 'Antoine Poinsot' via Bitcoin Development Mailing List
• Re: [bitcoindev] The Cat, BIP draft discussion. Greg Maxwell
  • Re: [bitcoindev] The Cat, BIP draft discussion. Nona YoBidnes
  • Re: [bitcoindev] The Cat, BIP draft discussion. Greg Maxwell
  • Re: [bitcoindev] The Cat, BIP draft discussion. Pepe Hodler
• Re: [bitcoindev] Re: The Cat, BIP draft discussion. Greg Maxwell
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. Ataraxia 009
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. Melvin Carvalho
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. Jonathan Voss
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. Greg Maxwell
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. John
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. Greg Maxwell
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. waxwing/ AdamISZ
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. Antoine Riard
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. Claire Ostrom
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. Pepe Hodler
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. Galois Field
  • Re: [bitcoindev] Re: The Cat, BIP draft discussion. Chris Riley
• [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction defenwycke
  • [bitcoindev] Re: Draft BIP: DustSweep – policy-only UTXO dust compaction Jonathan Voss
  • Re: [bitcoindev] Re: Draft BIP: DustSweep – policy-only UTXO dust compaction Defenwycke
  • Re: [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction Murch
  • Re: [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction defenwycke
  • Re: [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction Murch
  • Re: [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction Defenwycke
• [bitcoindev] Feedback on a simple 2-path vault design (2-of-2 + CLTV recovery) and use of pruned nodes for UTXO retrieval victor perez
  • Re: [bitcoindev] Feedback on a simple 2-path vault design (2-of-2 + CLTV recovery) and use of pruned nodes for UTXO retrieval 'Antoine Poinsot' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Feedback on a simple 2-path vault design (2-of-2 + CLTV recovery) and use of pruned nodes for UTXO retrieval victor perez
  • Re: [bitcoindev] Feedback on a simple 2-path vault design (2-of-2 + CLTV recovery) and use of pruned nodes for UTXO retrieval 'Antoine Poinsot' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Feedback on a simple 2-path vault design (2-of-2 + CLTV recovery) and use of pruned nodes for UTXO retrieval victor perez
• [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration אושר חיים גליק
  • Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration Possibly
  • Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration Ethan Heilman
  • Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration Henry Romp
  • Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration 'Russell O'Connor' via Bitcoin Development Mailing List
  • Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration Garlo Nicon
  • Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration Henry Romp
• [bitcoindev] A safe way to remove objectionable content from the blockchain (now on GitHub) Lazy Fair
• [bitcoindev] Q-Lock: Quantum-Resistant Spending via ECDSA + Hash-Based Secrets Amarildo
  • [bitcoindev] Re: Q-Lock: Quantum-Resistant Spending via ECDSA + Hash-Based Secrets Alex
• [bitcoindev] Reducing RAM requirements with dynamic dust 'uuowwpevskfcordh' via Bitcoin Development Mailing List
  • [bitcoindev] Re: Reducing RAM requirements with dynamic dust Eric Voskuil
  • Re: [bitcoindev] Re: Reducing RAM requirements with dynamic dust Erik Aronesty
  • Re: [bitcoindev] Re: Reducing RAM requirements with dynamic dust Eric Voskuil
  • Re: [bitcoindev] Re: Reducing RAM requirements with dynamic dust 'uuowwpevskfcordh' via Bitcoin Development Mailing List
• [bitcoindev] CTV activation meeting on IRC - Thursday 18 December 17:00 UTC /dev /fd0
• [bitcoindev] Request for early peer review of two BIP drafts (BUDS and segOP) Callum
• [bitcoindev] Hash-Based Signatures for Bitcoin's Post-Quantum Future 'Mikhail Kudinov' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Hash-Based Signatures for Bitcoin's Post-Quantum Future Greg Maxwell
  • Re: [bitcoindev] Hash-Based Signatures for Bitcoin's Post-Quantum Future 'conduition' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Hash-Based Signatures for Bitcoin's Post-Quantum Future Olaoluwa Osuntokun
  • [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future Boris Nagaev
  • Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future 'Mikhail Kudinov' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future 'Mikhail Kudinov' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future 'Mikhail Kudinov' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future 'conduition' via Bitcoin Development Mailing List
  • Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future Jonas Nick
  • Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future Olaoluwa Osuntokun
  • Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future Jonas Nick
  • Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future 'conduition' via Bitcoin Development Mailing List
  • [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future Erik Aronesty
  • Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future Jonas Nick
  • Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future Erik Aronesty
  • Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future david torrealba
• [bitcoindev] Splitting more block, addr and tx classes of network traffic Antoine Riard
  • [bitcoindev] Re: Splitting more block, addr and tx classes of network traffic defenwycke
  • [bitcoindev] Re: Splitting more block, addr and tx classes of network traffic Antoine Riard
• [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 Craig Raw
  • Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 Oghenovo Usiwoma
  • Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 Craig Raw
  • Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 Oghenovo Usiwoma
  • Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 pyth
  • Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 Craig Raw
  • Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 Oghenovo Usiwoma
  • Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 Sebastian Falbesoner
• [bitcoindev] op_ctv still has no technical objections Erik Aronesty
  • [bitcoindev] Re: op_ctv still has no technical objections 'conduition' via Bitcoin Development Mailing List
  • Re: [bitcoindev] op_ctv still has no technical objections /dev /fd0
  • Re: [bitcoindev] op_ctv still has no technical objections Erik Aronesty
  • Re: [bitcoindev] op_ctv still has no technical objections 'moonsettler' via Bitcoin Development Mailing List
• [bitcoindev] SLH-DSA (SPHINCS) Performance Optimization Techniques 'conduition' via Bitcoin Development Mailing List
  • Re: [bitcoindev] SLH-DSA (SPHINCS) Performance Optimization Techniques Tim Ruffing
  • Re: [bitcoindev] SLH-DSA (SPHINCS) Performance Optimization Techniques Nagaev Boris
  • Re: [bitcoindev] SLH-DSA (SPHINCS) Performance Optimization Techniques 'conduition' via Bitcoin Development Mailing List
• [bitcoindev] Re: AI-assisted drafts and disclosure 'nt yl' via Bitcoin Development Mailing List
  • [bitcoindev] Re: AI-assisted drafts and disclosure Oghenovo Usiwoma
• [bitcoindev] Announcing Penlock v1: Paper-Based Secret Splitting for BIP39 Seed Phrases 'Rama Gan' via Bitcoin Development Mailing List
• [bitcoindev] A safe way to remove objectionable content from the blockchain Lazy Fair
  • Re: [bitcoindev] A safe way to remove objectionable content from the blockchain Greg Maxwell
  • Re: [bitcoindev] A safe way to remove objectionable content from the blockchain Saint Wenhao
  • Re: [bitcoindev] A safe way to remove objectionable content from the blockchain Ethan Heilman
  • Re: [bitcoindev] A safe way to remove objectionable content from the blockchain Peter Todd
  • Re: [bitcoindev] A safe way to remove objectionable content from the blockchain waxwing/ AdamISZ
  • Re: [bitcoindev] A safe way to remove objectionable content from the blockchain Erik Aronesty

• Earlier messages
• Later messages