conduition

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

Public Key

npub1l6uy9chxyn943cmylrmukd3uqdq8h623nt2gxfh4rruhdv64zpvsx6zvtg

NIP-05 Address

Profile Code

nprofile1qqs0awzzutnzfj6cudj03a7txc7qxsrma9ge44yrym6337tkkd23qkgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsy96xqv

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1l6uy9chxyn943cmylrmukd3uqdq8h623nt2gxfh4rruhdv64zpvsx6zvtg

Show more details

Last Notes

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-10 19:07:41 UTC

I made a Rust library for 2-way async TCP sockets with a Noise-powered authenticated encryption layer. Uses the NNpsk0 handshake protocol.
https://github.com/conduition/tokio-noise

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/

2024-03-23 16:47:37 UTC

I suppose bitcoin devs love #Rust for the same reasons they love Bitcoin.
The scarcity and careful auditing of variables passed around in memory mirrors the scarcity and careful auditing of UTXOs passed around Bitcoin's ledger. Allocating new memory is as much an event as mining new bitcoins: Regular, but noted and tracked.
In Rust, a value may be borrowed many times, but its value may be consumed only once. Bitcoins can likewise be IOU'd countless times, but ultimately only belong to one script-pubkey.
By comparison, languages like Go and Javascript feel very... inflationary. They have an opaque, centralized, bloated, and omnipotent garbage collector attached to every runtime which allocates and deallocates memory as it pleases. Memory can be needlessly duplicated thousands of times entirely by accident, or over-collateralized by shared mutable references.
Some languages are the opposite, like C: Total anarchy. "Sure, allocate as much memory as you'd like. Deallocate it whenever. Read whatever you want, write wherever. Just try not to segfault."
Only Rust, like Bitcoin, strikes the perfect balance of organized chaos: a rehearsed ballet, in which all the dancers know their movements by heart.

2024-03-22 18:54:46 UTC

As part of the #BackdropBuild Hackathon, I elected to commit myself to making a prototype of the 'Ticketed DLC' protocol I proposed a few months back.
37 days later, here I am with a working prototype. Setting a deadline for yourself can really make a difference - Who knew?
https://github.com/conduition/dlctix
There is certainly plenty of optimization and upstream-interop work left to do, and having PTLCs on Lightning would make this SO much more efficient on-chain. But as a proof of concept anyone can play with today, I'm incredibly happy with the result. Running against regtest, all tests are passing, and simulated players can buy into simulated DLCs simply by buying SHA256 preimages (e.g. via Lightning).

2024-03-20 22:39:07 UTC

- reply

It's hard. I can't talk about my work in real life, and i can't talk about my life with the people i work with. I could get so much more done if i didn't try so hard to obfuscate everything i do.
I don't think satoshi would've had to go to the lengths that we today have to go to, in order to retain privacy.
I just finished a hackathon, and they wanted me to upload a youtube video showing my work: Oops, cant do that, sorry, it's totally impractical over TOR.
Even still, it's worth it. In return for my effort i get the most perfect feeling of complete freedom to work on whatever i want to with no fear of persecution. I could publicly manage a bitcoin mixing service or a darknet market or a free speech discourse platform etc, and the worst that would happen is my web2 accounts might be taken down. If i ever feel like walking away from it all, it's as easy as deleting a few files.

2024-03-20 06:09:39 UTC

- reply

Sounds like IPFS to me. Why not just upload blobs to IPFS instead and skip the extra dev work?

2024-03-14 18:23:59 UTC

- reply

With scrypt and similar password-based key derivation functions, the salt is like a namespace which ensures an attacker has to start from scratch if they're trying to guess a key derived from a unique salt.
If a salt is reused for two different ciphertexts, then any guesses an attacker makes can be applied to both ciphertexts.
So it's not as bad as nonce or IV reuse, but still best practice is to create a unique random salt for every ciphertext.

2024-03-02 22:45:56 UTC

Hey @npub1j8d…26k2, zebra-lucky and I are trying to merge Bitcoin Taproot support into the ZCash Foundation's Rust implementation of FROST. Open to feedback or suggestions 😎
https://github.com/ZcashFoundation/frost/pull/584

2024-03-02 06:14:13 UTC

- reply

I'm halfway through the curve trees paper. I had a watershed realization moment when they described two-cycle curve (e.g secp256k1 and secq256kq). I had no idea such things existed! Wack.

2024-02-27 18:28:31 UTC

- reply

I would really hope so. I searched the name up on LinkedIn but didn't come up with anything concrete. It's probably a throwaway

2024-02-27 14:45:29 UTC

I can't put into words how good it feels to make ticketmaster engineers salty enough that they feel obliged to send me hate mail.
https://m.primal.net/HfcK.png

2024-02-26 16:08:00 UTC

- reply

I wonder if there exists some solution based on biometric key derivation which would turn the "hodl your own keys" requirement into a "be your own keys" situation.

2024-02-22 02:53:39 UTC

- reply

Woops, wrong link
https://github.com/conduition/musig2/pull/2

2024-02-22 02:52:44 UTC

- reply

I just added RFC6979 logic to my BIP340 implementation:
https://github.com/conduition/musig2/pulls/2
Seems reliable enough to me!

2024-02-21 03:14:38 UTC

- reply

You totally can use RFC6979.
BIP340 even says how to do it: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#alternative-signing

2024-02-19 20:21:47 UTC

- reply

Mostly it's an excuse to finally put some time and effort into turning this concept into reality. It also means a shot at some grant money, which doesn't hurt either 😁
And thank you!

2024-02-19 19:35:19 UTC

They picked me! My Ticketed DLC concept has been selected for the backdropbuild.com v3 cohort 😇
https://raw.githubusercontent.com/conduition/dlctix/main/img/backdrop-build-v3.png
Check out my repository here to watch the commits coming in over the next few weeks/months 👀
https://github.com/conduition/dlctix
My end goal is to execute a real ticketed DLC on mainnet with volunteers from Nostr and StackerNews.

2024-02-19 04:22:47 UTC

Prediction: headlines in 2040 will look like:
- "EU bans sale of 'non-approved' phones and laptops"
- "Australia cracking down on illegal computation"
- "New 'client-side safeties' mandated for all devices produced for sale in USA"
Governments can't tolerate our ability to circumvent them with code. The EU is already trying to force backdoors into E2EE messengers. Someday they will escalate to banning general-purpose computing hardware because it can do things they don't like: deepfakes, bitcoin, encryption, TOR.
Draconian laws will never stop coming, but we dont have to stop them - We need only slow them down enough that we can out-engineer their weak-ass laws.
Wanna help slow them down? Donate to the Satoshi Action Fund or the EFF today using Bitcoin.
https://www.satoshiaction.io/
https://supporters.eff.org/donate

2024-02-18 15:36:11 UTC

- reply

As much as i might agree that inscriptions are spam and should be blocked, the reality is that there's no way to actually enforce this. Even if we used mempool filtering, inscribers would simply send their txs direct to the miners (who are happy to take the fees) or they can use obfuscation techniques like Inviscriptions ( https://conduition.io/bitcoin/inviscriptions/ ) to bypass the filtering in an endless cat & mouse game.

2024-02-16 15:50:53 UTC

- reply

...Aaaaand their docs site is down 🥲

2024-02-16 00:00:15 UTC

- reply

Thank you! Their zkVM seems like exactly what i'm after

2024-02-15 16:13:43 UTC

- reply

No comment 😅

2024-02-15 16:06:56 UTC

Anyone with STARK experience know how to build and validate a simple proof of secp256k1 discrete logs and SHA256 hashes?
I know ZeroSync must be doing this as part of their blockchain sync proofs. But i'm looking for a self-contained way to build and validate the proofs in rust.

2024-02-14 04:23:33 UTC

- reply

@npub1j8d…26k2
#note1pr9…mkpy

2024-02-14 04:21:43 UTC

- reply

This question was too tempting.
#note15ns…qpgn
So I wrote this:
https://conduition.io/cryptography/frost-byok/

2024-02-13 06:37:49 UTC

- reply

Yep! I have some links to some more beginner-friendly ECC stuff here:
https://conduition.io/cryptography/ecc-resources/

2024-02-13 06:26:35 UTC

- reply

My pleasure 😄 i wonder if the DKG could be run securely (incl commitment round) if the participants sampled random evaluations instead of random coefficients when building their keygen polynomial f_i(x)...
Damn, times like now, i really wish nostr had LaTeX support 🥲 stay tuned and maybe i'll write something up for this

2024-02-12 19:50:01 UTC

- reply

You sit down, put pencil to paper and work it out!
There is likely a way to do the DKG so that some cosigners have fixed keys and others have fresh random keys. It'd probably just take some clever math and a security proof that malicious cosigners couldnt bias the DKG to do evil stuff like backdoor the group key.

2024-02-12 16:06:03 UTC

- reply

Actually bringing your own key is possible, but there are limitations.
A FROST signing share is a polynomial evaluation. If, say, 3 people join together each bringing their own fixed signing shares, there exists some quadratic polynomial that interpolates their shares. However, it's impossible to find a linear (degree-one) polynomial which does the same.
In practice, this means if `n` people BYOK, they can definitely create an `n` of `n` threshold key with FROST. They can then issue new shares to add more people to the FROST group if they wanted, to make it an `n` of `m` threshold.
I'm not sure about the security implications of what a DKG would look like if only SOME keys are fixed and others can be variable. That's a different ball game 😅

2024-02-08 18:45:01 UTC

- reply

Pixels prove nothing anymore. KYC is useless. Wait till someone designs a 3d printer that can print convincing passports or ID cards.
Want me to share an image of a piece of paper so i can use your exchange? Sure, here's an image.
Want me to show you a shiny piece of plastic so i can board this plane? Sure, here is one.
The only way to rigorously prove something is to do so mathematically. In the age of AI, anything else can be faked. Identity is about what you know, not what pieces of paper you have (Debate me).
#nevent1q…6ngp

2024-02-08 18:12:51 UTC

- reply

Reverse engineering is a blast, I've been on a bit of a binge with it lately 😇
https://github.com/conduition/wos

2024-02-04 22:17:45 UTC

⚠️ Technical article ahead!
I reverse engineered TicketMaster's rotating barcodes for fun and profit. They're actually very easy to pirate.
https://conduition.io/coding/ticketmaster/

2024-01-28 00:46:12 UTC

I'm now mostly convinced that the ordinals/inscriptions crowd just don't care about efficiency. I made some simple constructive suggestions which could save millions of dollars a year in wasted mining fees. All are being ignored.
https://github.com/ordinals/ord/discussions/2879
https://github.com/ordinals/ord/issues/2944
https://l1f.discourse.group/t/brc-20-optimization/33/11

2024-01-28 00:40:02 UTC

@npub1mut…23vg I see you guys are working on some fun DLC-based features!
Do you have any interest in giving your users the option to buy into DLC wagers off-chain using Lightning? If so, my 'Ticketed DLCs' concept might be of interest.
https://conduition.io/scriptless/ticketed-dlc/
https://delvingbitcoin.org/t/off-chain-dlc-ticketing-systems/214/3

2023-12-18 23:35:27 UTC

Clever 'coiners cooperate instead of clashing.
Forget fruitless debates about whether inscriptions _ought_ to be used or not. I want to start concrete technical action to reduce the burden of inscriptions on the bitcoin mempool and fee market by going directly to the source.
We should be spending our effort streamlining the actual apps and protocols which are pushing all this data into the mempool in the first place. Who wants to help?
https://github.com/ordinals/ord/discussions/2879

2023-12-18 02:11:48 UTC

I wanna hear your ideas on how to make ordinal #inscriptions more efficient, and less onerous on bitcoin's fee market.
https://github.com/ordinals/ord/discussions/2879

2023-12-13 08:14:38 UTC

I can see #inscriptions are causing a lot of debate in the Bitcoin community, particularly regarding whether they should be "filtered" or "censored" at the mempool level by labeling them non-standard.
I'm here to tell you that this moral/ethical tennis match is irrelevant. Inscriptions can be pushed to the blockchain invisibly, by disguising the data inside normal-looking transactions. The true plaintext data is revealed only after the inscription is mined. I call these, "Inviscriptions", and they cannot be censored without resorting to flimsy heuristics.
https://conduition.io/bitcoin/inviscriptions/
Have comments? Suggestions? Hit me with a review!
https://github.com/conduition/conduition.io/pull/5

2023-12-10 04:14:58 UTC

- reply

The whole point of a standards spec document is that it is STANDARD. Saying "everyone should define their own standards" (especially for a network communication protocol) is like telling vehicle drivers to choose their own traffic bylaws.
Relevant XKCD. https://imgs.xkcd.com/comics/standards.png

2023-12-09 17:15:51 UTC

We can execute oracle-based smart contracts off-chain without trusting any middle men.
https://delvingbitcoin.org/t/off-chain-dlc-ticketing-systems/214/3
Come tell me if I'm crazy!

2023-09-04 03:55:55 UTC

Just finished some research on issuing Shamir Secret Shares using multi-party computation. Turns out, shareholders don't need to perform a full recovery if a share is lost or a new shareholder joins the party.
Find my article here: https://conduition.io/cryptography/shamir/

2023-08-15 16:27:34 UTC

Just finished my new article, describing how Wagner's Attack was used to break the first draft of MuSig in 2018.
https://conduition.io/cryptography/wagner/