kukks's avatar
kukks
kukks@kukks.org
npub1y24g...z2ad
Building in the shadows for a better future.
kukks's avatar
kukks 1 year ago
The state of the Bitcoin community in a bull market is such an embarrassment. Principles, and freedom tech all thrown out so that we can simp for the statists and their corrupt financial instruments, all for a few extra digits. Do better
kukks's avatar
kukks 2 years ago
The @BTCPay Server coinjoin plugin now supports automated, private coin consolidation during low-fee markets. image
kukks's avatar
kukks 2 years ago
On July 28th, I submitted my proposal to @HRF for the Serverless Payjoin bounty: Payjoin over Nostr. You can read the protocol addendum here: The proposal is incredibly simple in nature, just as BIP78 was designed to be, to increase adoption chances. All logic within the Payjoin protocol stays the same, so the version is still 1. It is asynchronous (receiver can process later when back online), encrypted (communication is end-to-end encrypted), and lightweight (no server requirement, leverages existing Nostr network). In addition to this, I also added building blocks for a new experimental addition: Nostr Payjoin Market. If your wallet supports receiving Payjoin, you can share a static payjoin endpoint using the Nostr Coinjoin Discovery protocol ( Other wallets, which support Payjoin but want to send money to wallets that don't, can use these static endpoints to enhance their transactions. The goal? Make every transaction to every wallet a coinjoin. See the sample wallet code and additional detailed description: See quick video demo of prototype:
kukks's avatar
kukks 2 years ago
Working on massively simplifying my relay code of NNostr https://github.com/kukks/nnostr. Recently, @lontivero asked me why my relay logic was so different to the rest, so here is my story: Back in 2021, we had to do assumptions on how clients would utilize subscriptions and filters. There were only A handful UI clients back then doing mostly the same thing and realistically 0 users as all the notes were just tests. Would everyone generally just create identical subscriptions? Would they have massive filters sets per subscription? Would filters be a template that everyone mix and matched into subscriptions? Was anyone even going to use any of this? As usual I went nuts and started building it super optimized from the get go. Every filter from every subscription was hashed and used as an identifier so that no duplicate sql call would be needed when users requested the same filters. Realistically though, nip01 still needed to mature and the filter spec gradually changed to introduce more convenience, such as paging and date ranges. This made writing clients way more efficient, but unfortunately made my optimizations just a bunch of crazy useless magic as filters were always different due to more precise query capabilities. I'm still happy with my relay code though, it comes with unique features such as a builtin balance system, fee charge on new keys and on per event basis, dynamic event fee based on event size, a chat bot for administration, and other fun stuff. Soon I'll be changing the filtering code to a more simplistic style, and I'm hopeful to eventually also find some more crazy stuff to build for it! I do have some interesting client side nostr bitcoin stuff being prototyped on the other end 😉 Always looking for feedback and ideas, feel free to reach out!
kukks's avatar
kukks 2 years ago
Updated the btcpay nostr plugin, zaps should be more stable now, but need some help testing plox