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 😇
There's no such thing as unlimited money. Take a sip of patience. This too will pass. 😌
I made a Rust library for 2-way async TCP sockets with a Noise-powered authenticated encryption layer. Uses the NNpsk0 handshake protocol.
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.
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.
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).
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.
Sounds like IPFS to me. Why not just upload blobs to IPFS instead and skip the extra dev work?
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.
Hey nostr:npub1j8d6h8mzvc8f2fvysrf09nlkmn7m2ylj32zl5na4tm5e8fd5dqysrg26k2, 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 😎
Reached an initial waypoint with the aut-ct (anonymous usage tokens from curve trees) project. It should now be easy to install and test; see the README:
https://github.com/AdamISZ/aut-ct
70-100ms verification time for 48K signet keys on my laptop. Generates a key image, a DLEQ proof and a Curve Tree proof. It's organized as a small RPC server (the API currently consists of only one call - "verify") and a client. Make the proof with the autct binary first then make the rpc verify call - for me it takes between 70 and 100ms for that larger keyset, or for smaller test ones. There'll be very little variation in timing in practice; I will try up to maybe 200K later.
Also contacted the paper authors to check a couple of minor points, which were fine. I'm quite optimistic about this, in that I now am fairly convinced this is a practical way to do what I previously called "RIDDLE" (see e.g. https://reyify.com/blog/little-riddle ) with much larger keysets - even the whole taproot utxo set, in the extreme. In that earlier construction, while the proofs were compact (1kB), the verification scaled linearly with the keyset size so it created a realistic limit. With Curve Trees we still have 2-3kB which is absolutely fine, but verification time is in the tens of milliseconds, and barely changes much when moving to 100k-1M range (which is completely impractical with the previous GK14/Triptych-based construction in that blog post).
If anyone could test the install-then-worked-example from the README and report back, I'd appreciate it.
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.
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
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.
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.
I just added RFC6979 logic to my BIP340 implementation:
https://github.com/conduition/musig2/pulls/2
Seems reliable enough to me!
Woops, wrong link
I just added RFC6979 logic to my BIP340 implementation:
https://github.com/conduition/musig2/pulls/2
Seems reliable enough to me!
You totally can use RFC6979.
BIP340 even says how to do it: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#alternative-signing
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!
They picked me! My Ticketed DLC concept has been selected for the backdropbuild.com v3 cohort 😇
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.
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.