I heard on a space today that the best way to get a PR merged in core is to campaign for it, so this is me starting a campaign for a listmempooltransactions RPC

my rationale for this is that it’ll let you more easily scan the mempool for new transactions that have arrived (since the last time you scanned it)

this is a massive improvement imo for usability of mempool data for apps that want to know about newly arrived txs to their node

there currently is no RPC for quickly fetching out new outputs created in the mempool or inputs spent.

to do this currently you’d have to call getrawmempool, which returns a list of all txids currently in the mempool and then call getrawtransaction on every returned entry. this is painful and unnecessary

I also implemented a feature into a branch CLN using it that would let you scan for interesting unconfirmed txs, to demonstrate its immediate usefulness. more details in the open PR!

https://github.com/bitcoin/bitcoin/pull/29016


regular reminder that lightning *is* a “shared utxo” protocol that uses covenants (and multisig) to scale bitcoin payment tx thruput

most of the commentary against it points out that it does not scale number of holders in relation to # of utxos. in my mind this is a good sign of the protocol’s success (it shipped and people use it and they found drawbacks with the MVP). It’s also a sign of bad messaging around the applicability of 2-party accounts to certain payment situations (venmo for example)

sometimes it is useful to have multiparty channels; i’d argue that liquid is one such example of this.

federated mints are another one; note that both of these multiparty systems require consensus algorithms to function. fedimints were using BFS, (iiuc they just changed to a new one). liquid uses “nakamoto consensus” aka a blockchain to keep track and agree on shared balance states

Lightning was shipped as the minimum viable product to scale tx thru-put and it succeeded at that. it did this with minimalist, 2-party design as consensus from 2-parties is the simplest case. this meant it could avoid tricky consensus questions and focus on privacy + throughput instead

shipping multi-party utxos at scale will require a solutions for managing consensus amongst stakeholders in the “shared utxo”; see Ark and already existing federations for examples of contending with this problem 🫡


Yes. Afterwards.


Introducing Ark's Developer Hub.

Our goal is to establish this as the go-to resource for learning about Ark.

Soon, you'll find comprehensive developer documentation on how to integrate Ark into your wallet or how to set up an ASP to offer liquidity.

https://arkdev.info


There are 2 questions here:

1. Why not stratum v2 right away?

I'm not an expert, but maybe miners need to upgrade their firmware? Well, some sort of software upgrade must happen, maybe they are not ready?

2. Why not Kano pool?

Miners seem to prefer FPPS to other payment schemes, which makes sense, due to the steady stream of revenue. Since Kano only finds one block per year, I don't see how it could offer FPPS to its "customers", so in that regard Kano pool will always be behind bigger pools. So, in this particular question, size matters 😉

Again, not an expert, just thinking out loud.

https://originstamp.com/blog/pps-vs-fpps-vs-pplns-vs-pps-mining-pool-payouts/


The mining protocol is called Stratum.

Today, pools decide which transactions go inside the new block, aka the block template. After this, the block template is send  to miners which will try to mine it. All miners inside a pool use the same block template.

So, the block template decision is centralised on a dozen pools. One evil entity just need to apply pressure on a dozen individuals to censor some type of transaction.

With the next version of the protocol, Stratum v2, miners are able to decide which block template they want to work on, without loosing the benefits of being in a pool.

So, the block template decision will be decentralised  into thousands of individual miners, which makes it a lot harder for the evil entity to apply pressure.

https://ocean.xyz will use Stratum v2 in a near future
https://dmnd.work is using Stratum v2 today (I think)


Nostr + Torrents = Match made in heaven

https://next.nostrudel.ninja/#/torrents


Testing nocomment


PoC:

Buy gift cards from The Bitcoin Company and pay with
Liquid BTC

- Buy gift card (includes VISA)
- Capture Lightning (LN) invoice
- Call Boltz and make LBTC => LN swap
- User pays LBTC with Marina Wallet

https://m.primal.net/HRJO.mov

Try it:

https://joaobordalo.com/labs/tbc/

Links:

https://m.primal.net/HRJO.mov
https://www.thebitcoincompany.com/
https://boltz.exchange/
https://vulpem.com/marina


Introducing Kind0.io

A NIP-41 proof of concept.

What is NIP-41? A simple way to migrate from a compromised key into a new key while signaling to your followers what happened.

It works by whitelisting your next npub ahead of time and timestamping it to something that can order events chronologically (ie the Bitcoin blockchain)

When a key is lost or compromised the new key can sign a migration event, timestamp it as well and then clients can choose to act on it.

For more discussion on this, listen to nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 's recent Bitcoin.review where they go over the why and the tradeoffs.

Here’s is a very rough video of a very rough tool to implement this whole flow.

This is not the last word on key management; there is still a lot of work to be done, but this is a small step in the right direction that will allow us to migrate the existing nostr social graph to more cryptographically complex schemes for whoever wants to do that.

https://cdn.satellite.earth/3f1bf208810669bd3a9eaa7a0b9c7ff2d75d1abc893a6b2db8463d6f4923d083.mp4


Oh, crap, it's gone.


Another test


Test sighash #1


Test #8


Test #6


Test #5


Test #4


Announcing Nostr markets: find all markets created with NIP15

https://nostr-markets.pages.dev/

All feedback is welcome.

https://github.com/bordalix/nostr-markets


blastr: a nostr cloudflare workers proxy relay that publishes to all known online relays.
------------------

This takes advantage of the high availabilty of cloudflare serverless workers on the edge that are rust wasm-based with 0ms cold starts. Learn more about cloudflare workers.

This is write only for now and is compatible with nostr clients but also features a simple POST api endpoint at /event. All events get queued up to run in batches by another worker that spins up every 30s if there's any events lined up, or once a certain amount of events are queued up.

This will help ensure that your events are broadcasted to as many places as possible.

https://github.com/MutinyWallet/blastr

https://i.postimg.cc/SNyxQyDs/blastr-diagram.webp


🚨 Killer Nostr + FediMint Use case 🚨

p2p marketplace LocalBitcoins is shutting down. Speculation is that it has come under heightened scrutiny from FinCEN due to its use as a conduit for funds from Bitzlato and Hydra dark marketplace. Centralized solutions are not sustainable.
https://localbitcoins.com/service_closure/

Decentralized p2p marketplaces are desperately needed. Nostr relay modules for FediMint could transmit trade offers and facilitate trader chat, with escrow modules securing the trade amounts and deposits. Discussion is open on integrating Nostr with FediMint: https://github.com/fedimint/fedimint/discussions/1604

#[0]
#[1]
#[2]
#[3]
#[4]
#[5]
#[6]
#[7]
#[8]
#[9]


If you want to backup your events:

https://nostr-backup.pages.dev

If you want to broadcast your events:

https://nostr-broadcast.pages.dev