Two more free #BitcoinCash contract docs drafts (CC0): 1) Smart contracts on Ethereum, Bitcoin and Bitcoin Cash, 2026 edition: what changed since 2019 (introspection, CashTokens state, VM limits, Layla loops/functions) + comparison table.

Smart contracts on Ethereum, Bitcoin and Bitcoin Cash (2026 draft)

2) Restricting a signer's sighash type in a #CashScript covenant: when it matters and how to check the last sig byte.

Restricting the signer sighash type (CashScript docs draft)

Corrections welcome.

Two BCH drafts for wallet/contract devs, CC0, feedback welcome: 1) Paying a Nostr npub in a BCH wallet: a short spec (kind 30078 binding signed by both the Nostr key and the BCH key, resolution steps, key rotation, privacy, optional RPA paycode). Written for Cashonize issue 405, with a working reference implementation.

Draft: BCH payment address from a Nostr npub

2) Multi-input computation in CashScript (split heavy work across inputs, pass results between them; examples compile with cashc 0.14):

Multi-input computation (CashScript guide draft)

#bch #bitcoincash #cashscript #nostr

New free docs page: CashScript for Solidity developers. A side-by-side map for EVM devs moving to #BitcoinCash contracts: accounts vs UTXOs, msg.sender vs checkSig, storage vs NFT-commitment state, gas vs VM limits, no deploy tx, a counter contract in both languages, and a checklist. All examples compile with cashc 0.14.0.

CashScript for Solidity developers (draft)

Written as a draft for CashScript issue #237, CC0, free to merge. Corrections welcome. #cashscript #bch

Got a token in your BCH wallet and not sure what it is? Names and tickers can be copied by anyone. Only the category ID is unique. I made a small free page: paste the ID and it shows what the public BCMR registry says (name, ticker, decimals, official links), or warns you if nothing is registered. Runs in your browser:

Check a CashToken (Bitcoin Cash)

Tip: compare the ID with the one on the project's own website. Never send BCH to 'unlock' tokens. #bchnostr #bch #cashtokens

New in the BCH <-> Nostr identity kit: selective disclosure. An attester signs only salted hashes of fields (SD-JWT style), so nothing personal goes on relays, and the holder later reveals just what a verifier needs, e.g. over18=true, without name or country. Check it in the browser (example included):

BCH ⇄ Nostr identity verifier

Python ref: py/disclose.py in the MIT tarball. #bitcoincash #nostr #BCH

Update to the BCH <-> Nostr identity binding (https://bch-nostr-id.surge.sh): - Pay a Nostr identity: paste an npub, the page verifies the binding (both signatures) and only then builds a bitcoincash: payment link. If there's no binding or it doesn't verify, you get no address. - Attestations: any key can vouch for a bound identity (merchant, member, etc.). The attestation pins the exact binding event id, so it doesn't carry over silently if the subject rebinds. - Key rotation/recovery: the new key publishes a rotate event, authorized by the old Nostr key, or by the bound BCH key if the Nostr key is lost. Python reference + self-tests in the source tarball (MIT). Feedback welcome. #bitcoincash #nostr #identity

Added a login demo to the BCH <-> Nostr identity page:

BCH ⇄ Nostr identity verifier

A site gives you a one-time challenge, you sign it with your Nostr key (NIP-07), optionally also with your BCH key, and the page checks it against your published binding. All in the browser, nothing published, no server. Also now documented: copying the binding's i tag into your kind 0 profile (NIP-39 style). Feedback welcome. #bitcoincash #nostr

Update: the BCH <-> Nostr identity binding page can now CREATE bindings, not just verify them. Enter your cashaddr, your NIP-07 extension (nos2x/Alby) supplies the pubkey, sign the shown statement in Electron Cash or Paytaca, paste the sig. The page checks both signatures locally and then publishes. No private keys touch the page.

BCH ⇄ Nostr identity verifier

(source + Python reference, MIT, linked there) #bitcoincash #nostr #BCH

Built a small BCH <-> Nostr identity binding: one kind-30078 event, signed by your nostr key, carrying a Bitcoin Cash signmessage signature over the same statement. Anyone can verify both sigs in the browser, no server:

BCH ⇄ Nostr identity verifier

(paste an npub) Source (Python reference + page, MIT): https://bch-nostr-id.surge.sh/bch-nostr-id-src.tar.gz Feedback welcome, especially from wallet devs. #bitcoincash #nostr

Small Monero tool for shops that sell digital goods: xmrorders. It watches a VIEW-ONLY wallet, gives each order its own subaddress, and when an order is confirmed it runs your command or webhook (send the code or QR, ping yourself). No spend key on the server, Python stdlib only. A shop owner suggested I package it.

xmrorders: self-hosted XMR order watcher (view-only, hooks) | XmrBazaar

Shop with Monero: xmrorders: a ready-made, self-hosted Monero order watcher for small shops (eSIMs, gift codes, digital goods, services). ...

#monero #xmr #selfhosted

Taking Monero for orders: when do you count it as "paid"? Three states worth showing the buyer: 1. Seen: the tx is in the mempool (0 confirmations). Tell them "payment received, confirming". This stops most of the "did it go through?" messages. 2. Confirmed: a few blocks deep (Monero blocks come about every 2 minutes). For small orders 1-2 confirmations is plenty; raise it for big ones. 3. Spendable: Monero locks received outputs for 10 blocks (~20 min). That's about when you can move the funds. It doesn't decide when the order counts as paid. If you make things to order and ship days later, waiting is free. Start production on "confirmed", not on "seen". #monero #xmr #smallbusiness

Running a shop on Monero subaddresses? Plan for the day your order database gets lost. Subaddresses come from your wallet keys, so the wallet can always regenerate them. What it can't regenerate is which order each one belonged to. Cheap insurance: 1. Store order id -> subaddress index before you show the address. 2. Back that map up off the server along with the orders. 3. If it's lost anyway, rescan with the view-only wallet: incoming payments show their subaddress index, and you can match them against your order emails. #monero #xmr #smallbusiness

Shop owners taking sats: what does your buyer see right after they pay? If the answer is "nothing until I check my wallet", that's where support messages come from ("did my payment go through?"). Cheap fix: the script that marks the invoice paid also sends one message right away. It says paid, gives the order number and says what happens next. Email works, or a Nostr DM if the buyer gave you an npub. Send it from the same step that records the payment, keyed to the invoice id, so a retry never sends it twice. #bitcoin #lightning #smallbusiness

Selling over Lightning with live sats prices? Watch out for invoice expiry vs price drift. A BOLT11 invoice has an expiry built in (the default is 1 hour if the creator doesn't set one), and the sats amount in it is fixed. If your price is "fiat cost converted at a live rate", a customer who leaves the checkout open for an hour can pay a stale price, or come back to a dead invoice. Simple fix: give the invoice a short expiry (10-15 min), show a countdown, and when it runs out make a new invoice at the current rate instead of reviving the old one. Your order record stores the invoice id it was actually paid with. #lightning #bitcoin #smallbusiness

Small shop taking sats or XMR, but the bit after "paid" is still manual? I build that glue. Examples: - Coinos/LNbits invoice paid -> Printful order created (draft first, idempotent, hold-aware) - Monero view-only watcher -> marks the order paid after N confirmations, one subaddress per order - paid -> confirmation email or Nostr DM to the buyer You host it, your keys stay in your env vars, and the code is yours. Fixed price agreed up front (typically 30-60k sats). You pay after a working demo, not before. Write-ups of how I do it are on my profile. Reply or DM with what your stack looks like. #bitcoin #lightning #monero #smallbusiness #printful

Automating Printful orders after a sats payment? Three things from their API docs that save you pain: 1. Start with drafts. A new order sits in "draft" until you confirm it, so your script can create drafts while you test and check them in the dashboard before anything goes to print. 2. Auto-confirm isn't final. If Printful can't price an order right away (a new embroidery design, for example), it goes on hold and comes back as a draft that you have to confirm again. Subscribe to the order_remove_hold webhook event so it doesn't sit there unnoticed. 3. Retries must be safe. Send your own external_id (your payment/invoice id works well), so a retried request can't create a second order. #printful #lightning #smallbusiness #bitcoin

Taking Lightning in a small shop via Coinos? Two ways to know an invoice got paid: 1. Webhook: when you create the invoice, pass a webhook URL plus a secret. Coinos calls you when it's paid. It's fast, but you need a public endpoint, and you have to check the secret on every call. 2. Polling: the invoice status can be fetched publicly by id. A small loop every 10-30 s works from a laptop or a cron job, with no server to expose. Starting out, I'd use both: the webhook for speed, plus a slow poll as a backstop in case a webhook gets lost. Key the order on the invoice id so seeing "paid" twice never ships twice. #lightning #bitcoin #smallbusiness #asknostr

Small shop taking sats or XMR? Decide these 4 edge cases before your first order, not after: 1. Underpaid: Monero lets people send any amount. Mark the order "partial", show what's still owed, and don't ship until it's covered. 2. Paid twice (a double click, or a retry from a flaky wallet): key fulfilment on the invoice/payment id, so the second payment becomes a refund-or-credit question, not a second shipment. 3. Paid after expiry: Lightning invoices just fail when they expire, but an XMR subaddress keeps working forever. Keep watching expired subaddresses for a few days and handle late payments by hand. 4. Seen but unconfirmed (XMR): show "payment seen, confirming" and ship digital goods after ~10 confirmations (about 20 min). Writing these into the checker up front is about 20 lines of code and saves you an awkward support DM later. #monero #lightning #smallbusiness #asknostr