conduition

Pseudonymous freelance cipherpunk :: https://conduition.io

Public Key

npub1l6uy9chxyn943cmylrmukd3uqdq8h623nt2gxfh4rruhdv64zpvsx6zvtg

NIP-05 Address

Profile Code

nprofile1qqs0awzzutnzfj6cudj03a7txc7qxsrma9ge44yrym6337tkkd23qkgpr3mhxue69uhkummnw3ezumt4w35ku7thv9kxcet59e3k7mgpp4mhxue69uhkummn9ekx7mq56jslf

Publishing to

nostr.mutinywallet.com

nos.lol

offchain.pub

relay.damus.io

Author Public Key

npub1l6uy9chxyn943cmylrmukd3uqdq8h623nt2gxfh4rruhdv64zpvsx6zvtg

Show more details

Last Notes

2026-08-02 00:56:25 UTC

I would like to present DropKick, a minimal commit/reveal rescue protocol which allows efficient recovery of pre-quantum UTXOs after Q-day.
https://conduition.io/bitcoin/dropkick/
The user experience in a post-quantum wallet would look roughly like this:
- Click "Import a legacy wallet"
- Enter your legacy seed phrase
- Wait 1000 blocks and your legacy coins will be available to spend securely 😇
https://blossom.primal.net/fa40cfdd5f48785c8f6655f5001bd07aa986b0f9611464c72d147f7d68bb820c.png

2026-06-03 20:03:44 UTC

Brink is funding my PQ research!
https://conduition.io/bitcoin/my-first-grant/

2026-03-18 15:53:56 UTC

If we someday want to replace quantum-vulnerable ECC, we want something compact, flexible and fast. Isogenies seem like the only candidate so far: 66 byte pubkeys, 148 byte sigs. I wrote a thing explaining isogenies, aimed at people who already know ECC.
https://conduition.io/cryptography/isogenies-intro/

2025-08-05 21:24:25 UTC

What is the fastest known vanity address generator?

2025-07-21 22:36:36 UTC

- reply

Thanks man! i'm glad to see the library is going to get some use 😃

2025-01-12 04:19:39 UTC

Do you love bitcoin smart contracts?
Sick of constantly renewing your DLCs with on-chain transactions?
Wouldn't you prefer your adorable lil' smart contract to live forever?
Now it can.
https://conduition.io/scriptless/dlc-factory/

2025-01-12 02:58:57 UTC

- reply

A numeric DLC oracle publishes a set of nonces, one per digit, for some future price/time/asset-pair event. Then when that time rolls around in the future, it signs each digit of the price using one of those pre-announced nonces, plus the oracle's static signing key. I think @nprofile…43nv 's approach here is to simply sign a price inside by virtue of its inclusion in a signed nostr event object.
I really like the NIP88 proposal you linked, i've done some work on it and the draft seems like it'd fit most people's needs. I'd be in favor of standardizing the oracle events (kind 88 and 89), but not the DLC offer/accept events (kind 8888, 30088). I think we should spend more time improving the performance and privacy of the dlc specs before standardizing those messages downstream in Nostr.
The oracle messages are important to get started on right away, because without a vibrant market full of trustworthy oracles, nobody is going to use DLCs. Walk before you run, right?
https://github.com/nostr-protocol/nips/pull/919
perhaps one day, my nostr client can fetch announcements for tomorrow's bitcoin price from 9 different oracles, and use it to create a multi-oracle DLC offer which anyone on the same relays can accept. But for now i'd be happy with simply having nostr as an oracle platform which other apps can build off.

2024-12-17 03:35:18 UTC

- reply

I definitely agree, taproot approach is much better. I updated my post to point to yours. DASK is neat but I don't think we need to be that fancy, and your Taproot approach is more soft-fork friendly.
I do still think using a lighter-weight signature scheme like WOTS for certification would be better and more future proof than committing directly to SPHINCS right now.
If we do end up wanting to use SPHINCS in 20-30 years, it'd still be an option: Just enforce that the WOTS key must sign a SPHINCS pubkey, and verify everything else against the certified SPHINCS key. That would only add a kilobyte to the already-huge SPHINCS signature data.
Think of it this way: if you're correct and this is just an edgecase fallback opcode that only a few people ever end up using, then do we really want the huge kitchen-sink of bringing SPHINCS into the bitcoin consensus layer, just for it to be barely ever used?
On the other hand, if this PQ fallback opcode is used a LOT, then we stand to save a LOT of witness space by biding our time and seeing where the cards fall on the landscape of many-time post-quantum signatures, rather than committing to huge SPHINCS signatures today.

2024-12-16 03:02:15 UTC

- reply

Hey @npub185h…wrdp, I can't reply on google groups but you should check out my article on hash-based signatures and my DASK proposal, it's very similar to your idea, in the way clients can opt into future quantum resistance without any consensus changes.
https://conduition.io/cryptography/quantum-hbs/#Upgrading-Bitcoin
I chose a different mechanism for my approach. Instead of an opcode in a tapscript leaf, DASK uses a PQ signature scheme pubkey as an secp256k1 secret key, and assumes future PQ bitcoin clients will validate against that PQ pubkey.
I think your proposal has a major benefit over mine in that it makes soft-fork compliance way easier. My DASK idea seems like it would need a hard fork on Q-Day, but yours would seem to be fully compatible with old clients. Big props 🎉
One idea from my post which I think you might want to consider copying is: Instead of committing to a SPHINCS key on-chain, commit to a hash-based certification key with shorter signatures, like WOTS.
Yes, it's a one-time signature scheme so we can't reuse the key, but we can be pretty sure than post-quantum cryptography will progress a long way in the coming decades, and we can use that one-time signature (which we are highly confident is secure today) to endorse a post-quantum key for a signature algorithm that might not exist yet, or that might exist today but that we don't know is secure, like Kyber.
Your opcode soft-fork would have to specify the exact validation semantics later, but the WOTS authentication key has already been committed to, so the coins are safe.

2024-12-05 04:09:44 UTC

What's amazing to me is that despite crossing into six figures of USD per bitcoin, median on-chain transaction fees are still at single-digit sats-per-byte rates.

2024-12-05 03:55:04 UTC

$100k Bitcoin guys and girls. Inevitability makes it no less awe inspiring. Clever purposeful dev teams are the reason why it happened. When people ask me why i'm so confident in Bitcoin, I say it's because i know how many brilliant minds are actively working out the kinks and making Bitcoin practical. With so much 🧠 power we can't help but succeed at least a little bit.
Anyways, tick tock next block, I'll see you tomorrow internet.

2024-11-03 07:23:19 UTC

- reply

Article fixed, now I'm assuming transparent setup ZKPs only (e.g. STARKs). Thanks for pointing this out 😄

2024-11-03 06:09:08 UTC

- reply

Great catch, thank you! Will fix this

2024-11-03 06:03:00 UTC

- reply

ahah! I was sure someone must've thought of this idea before me, but I didn't have the right search terms. "ZKCP". This is great background reading, thank you @npub1vad…nuu7!
Interesting to learn that the SNARK setup is more sensitive than I had thought. I'll be sure to correct my article to reference the original idea and fix the flaw which I unwittingly duplicated.
As for performance, so far I've only tested the PTLC-bridging program here shown in this section: https://conduition.io/bitcoin/zkpreimage/#Optimizing
With that, it took 3 minutes to generate a proof with the RISC0 STARK prover. Not great but also not completely impractical. I'd like to test other prover programs too

2024-11-02 21:59:25 UTC

"Sell me this preimage."
You can verifiably purchase the solution to any NP-Complete problem using Bitcoin (and Lightning), combined with zero-knowledge proofs.
- Buy the solution to a sudoku puzzle
- Buy the prime factors of an RSA key
- Bridge HTLCs with PTLCs
- Buy a valid proof-of-work
- and more...
https://conduition.io/bitcoin/zkpreimage/

2024-10-23 14:13:28 UTC

- reply

That's completely true! The transition to PQ crypto is a slow march across all digital industries. I know for sure OpenSSH is actively working on this. https://linuxiac.com/openssh-9-9-released/
The most important part of the overall migration IMO will be TLS. Almost all TLS traffic today is basically plaintext to a quantum computer (incl passwords sent to log into online services, and access keys downloaded over TLS). Cloudflare has a good post about that here: https://blog.cloudflare.com/pq-2024/

2024-10-22 23:26:05 UTC

- reply

First time for me hearing of Dark Skippy, but it sounds like a pretty obvious idea: Malicious firmware causes compromise of hardware wallets. That idea applies to pre and post quantum signatures of any algorithm.

2024-10-22 20:02:20 UTC

I went on a deep dive into post-quantum hash-based signatures and tried to apply them to bitcoin. At the end of the article I propose a way to insure today's Bitcoin wallets with a quantum-resistant fallback key, without any consensus changes needed.
https://conduition.io/cryptography/quantum-hbs/

2024-10-10 04:53:25 UTC

- reply

Just sent you a few sats to test, seems like it's working

2024-10-10 04:39:37 UTC

- reply

@npub1vwl…zfhz That's because LNURL specifies that the min/max sendable fields in the LNURL response are in millisatoshis (thousands of a sat). 1000 msat = 1 sat, so everything should be working correctly for you there 😎

2024-10-10 04:34:51 UTC

- reply

I agree about the DoS and scaling risks for websockets. Publishing data about spent proofs intermittently sounds more realistic to me, but I don't see any point in using Nostr to do that. A cashu mint is itself an always-on server already. What is gained by pushing that data to other people's servers besides offloading the DoS/scaling problems onto someone else? Instead the mint should just make that data available directly to clients via a new API endpoint.
Publishing one data point per spent proof wouldn't scale well - the mint needs some kind of accumulator or filter which compresses the information about spent proofs while allowing client-side validation. This seems like a use-case for Golomb-Coded sets (GCS), as used in BIP158 compact filters.
https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki
The mint computes a GCS which compresses all proofs spent recently, and updates the filter regularly. If the mint keeps the GCS hash representations sorted in memory, it could easily perform this update atomically for every single swap/melt without much of a performance hit (it'd be O(log n) insertion complexity).
If the filter gets too big, the mint compresses and archives it, and starts building a new one from scratch, or else evicts older GCS members (spent proofs) with a FIFO queue.
Clients can download and check the compact GCS filter at any time to see if their proofs have been spent recently, without revealing which ecash notes they're curious about. There's a chance for false positives but no chance of false negatives, so you might think your token was spent when it wasn't, but if your token was spent you'll always know about it.

2024-10-03 17:56:34 UTC

- reply

I just realized my lnaddrd server was configured not to accept zaps less than 500 sats... sorry to anyone who was trying to zap me on nostr for the past few months, i'm not that greedy, i swear!
#note1c4p…wl64

2024-10-03 15:47:44 UTC

- reply

@npub10vl…sp42's reply below is correct, FROST with trusted dealer would solve your use-case here.
Of course @npub1vad…nuu7's point is also valid: If you want true multisig security you'd need to be certain that you securely erase the distributed shares on your machine afterwards, and of course erase the original secret key (except for maybe keeping a paper backup). Still, it's a valid approach if you are OK with those assumptions.
I'm currently working on a BIP340 compatibility pull request into the ZCashFoundation's FROST implementation (Rust), I believe it should work to produce valid Nostr sigs.
https://github.com/ZcashFoundation/frost/pull/730
If you use a python stack, check out @npub1tr7…nc05's FROST implementation here
https://github.com/jesseposner/FROST-BIP340
@npub160t…yjc9 linked to my FROST BYOK article but that would only be practical if you wanted to create a joint key from existing (static) npubs. I don't think it's useful for splitting an existing key.

2024-09-06 20:32:31 UTC

- reply

I'm very happy to see these vulnerabilities fixed in a timely fashion, but Mercury went public releasing a patch and publishing my report without even asking me for a review first. The first I heard about this patch was Tom Trevethan's twitter post a few hours ago.
Mercury's bug bounty program offers only 800 GPB for a critical loss-of-funds vulnerability. Rather than chasing Mercury down again for another mediocre payout, after this experience i'm more inclined to just hold onto any new vulns I might find and exploit them later, if mercury ever sees wider use.
Oh well, it's their code i suppose. To be fair, Tom made clear they treat Mercury Statechains as unsafe prototype software, and clearly tell people not to use it with mainnet funds. Vulns like these are why.
Remember kids, if a dev tells you not to use their own code with real money, you should listen!
References:
#note13jc…hqmw
https://x.com/mercurylayer/status/1832062894428545114
https://conduition.io/code/mercury-disclosure/
https://github.com/commerceblock/mercurylayer/blob/07b2a4485187592ed24c642b7284b321aceaa8fe/disclosure.md

2024-09-06 19:57:41 UTC

- reply

The vulnerabilities are described in detail on my blog here: https://conduition.io/code/mercury-disclosure/

2024-07-14 17:36:12 UTC

I just found out... there's a NIP for publishing discreet log contract messages on Nostr?? This is a crucial step for DLCs on Bitcoin. The present bottleneck for DLCs seems to be: How do I become an oracle? How do I find trustworthy oracles? NIP-88 would let us build apps which answer those questions.
https://github.com/nostr-protocol/nips/pull/919
Combine this with ECash DLCs and we could have scalable, instant, completely private micro-contracts, which are discovered over Nostr and settled in ECash.
https://github.com/cashubtc/nuts/pull/128
But even if you don't like ECash, this NIP is still incredibly important. Kudos @npub1u8l…turz

2024-07-13 17:01:11 UTC

- reply

Articles like this are what happens when the "bored cipherpunk" and "frustrated customer" venn-diagrams overlap 🐒
Journalists have recently been contacting me about this article because of the big Ticketmaster hack recently. It's silly that they need some amateur like me to fact-check the erroneous PR statements issued by a multi-billion company.

2024-07-12 03:24:43 UTC

Had an idea for scaling submarine swaps into a multi-party protocol, and got some interesting results. Have a look:
https://conduition.io/scriptless/multi-party-submarine-swaps/

2024-06-20 17:28:26 UTC

I made a PR into electrs to improve transaction broadcasting privacy.
https://github.com/romanz/electrs/pull/1056

2024-06-02 22:46:37 UTC

I couldn't find any reliable spec-compliant DLC oracles for real-world events, so I made my own. Meet Cassandra 🕵️‍♀️
https://conduition.io/code/cassandra/

2024-05-30 18:06:50 UTC

- reply

Excited to see how it turns out! Ecash is a great opportunity to create a layer of fungibility on top of lightning. I for one will be ready to come aboard 🧑‍🚀

2024-05-27 16:20:05 UTC

I wrote a draft NUT for Discreet Log Contracts settled on Cashu
https://github.com/cashubtc/nuts/pull/128

2024-05-19 20:33:49 UTC

You can settle Discreet Log Contracts with Chaumian ECash!
https://conduition.io/cryptography/ecash-dlc/
@npub12rv…85vg and other ecash devs: Do you think this would make a candidate NUT extension on the cashu spec?
Feedback appreciated 😎
https://github.com/conduition/conduition.io/pull/6

2024-05-17 15:28:08 UTC

- reply

I've been working on FROST+taproot lately and the xonly nonsense easily accounts for 90% of the complexity.
https://github.com/ZcashFoundation/frost/pull/584
I'd be curious if anyone has actually done the math to compute how much xonly has saved us in block space.
...only for the inscription meme lords to slide in and use 100x that space for jpegs.

2024-05-10 14:33:50 UTC

- reply

If you can, i would suggest running your own lightning node. Then you can use a remote access wallet like Zeus to interact with it.

2024-05-08 15:58:00 UTC

Privacy and self-custody services with a central point-of-failure are not stable long-term.
https://www.nobsbitcoin.com/agoradesk-localmonero-shutting-down/
https://www.nobsbitcoin.com/zksnacks-to-suspend-its-coinjoin-coordination-service-on-june-1st/
https://www.nobsbitcoin.com/samourai-dojo-v1-25-0/
https://www.nobsbitcoin.com/phoenix-wallet-to-be-removed-from-us-app-stores-on-may-3/
https://www.nobsbitcoin.com/sparrow-wallet-v1-9-0/
https://www.nobsbitcoin.com/samourai-wallet-founders-arrested-and-charged-with-money-laundering/
The cull we're seeing in the past couple weeks is just the beginning, but it's a good sign: They're pushing back because we're gaining ground.
If you want to run a privacy business, i see 3 choices:
- Decentralize your business (no single PoF)
- Mask yourself (build pseudonymously)
- Comply (by KYCing)

2024-04-25 17:20:15 UTC

- reply

Did they seriously upload entire xpubs? Not just addresses?
Can i see a source on that?

2024-04-25 17:15:27 UTC

- reply

This scheme doesn't scale.
If every TX used paypal's approach, the 'green miners' would end up with thousands of dust UTXOs which they would need to clean up, every single block. Network throughput would drop significantly.
With standard bitcoin fee subsidy, all miner fees are automatically consolidated in the coinbase transaction: No dust to clean up.
Not to mention the fact that this approach doesn't necessarily require the miners to use green energy to mine the TX - it just incentivizes a particular arbitrary set of miners to mine the TX. Those miners could pay off a different non-green miner to mine the TX, because it is still consensus-valid.
Paypal's idea is just a roundabout way of reinventing the same open fee market which already exists, but with a lame attempt at green-washing.

2024-04-25 01:05:55 UTC

@npub1hea…g9v2 How do you feel working on Sparrow Wallet, now that we're seeing the US government prosecute the Samourai devs?

2024-04-25 00:22:11 UTC

- reply

No problem 😁 great choice

2024-04-25 00:21:16 UTC

- reply

I mean pseudonymously.

2024-04-24 22:59:04 UTC

- reply

Develop pseudonymously, or else.
#nevent1q…75hh

2024-04-23 14:39:49 UTC

- reply

Responded on github about this. For your particular case, using --no-rest-tls is unsafe. However generally speaking, i should probably add a flag to allow plaintext connections as there are some cases where it is safe

2024-04-21 03:35:37 UTC

I made a self-hosted Lightning Address webserver, because for some reason I couldn't find any good ones out there already.
https://github.com/conduition/lnaddrd
This is what powers my snazzy new `conduition@conduition.io` LN address 😇

2024-04-20 19:40:05 UTC

- reply

There's no such thing as unlimited money. Take a sip of patience. This too will pass. 😌
#nevent1q…ddnc

2024-04-09 14:53:34 UTC

The Noise protocol is to Web3 what TLS is to Web2.
Noise is used by Wireguard, the Lightning Network, I2P, even WhatsApp to enable secure communication with all kinds of different handshake styles. If you've never played with Noise before, I would encourage you to read the spec.
https://noiseprotocol.org/