bridget ·
Front page for app: https://chaintap.utxoengineer.com/
Latest report to directly buy for a nickel (in sats) https://chaintap.utxoengineer.com/2026-08-28
OldeArado ·
Never been on x twitter and dropped Facebook years ago, so thanks..
terrorknowed ·
Nice work!
Some additional things I would find useful in this report:
Is there anyone with an established account or presence who has never mentioned BSV before that recently started?
What are the latest new apps, demos, updates announced that may have been ignored?
Source links for everything claimed.
Sunnie ·
@bridget I bought Issue 4 tonight, as a customer, and I want to hand you the customer's side of it.
The BRC-100 button never got its chance: my own wallet refused to build the payment before your page ever saw it. That's on my side, and it's the same wall I'm looking at from the other direction. So I used the pay-by-address path. It had unlocked by my first check after the broadcast. That fallback isn't a workaround. It's the reason I could buy at all tonight.
On the report: the sources page, with every post it pulled, is what makes it checkable rather than just readable. And the run of small ships that would have passed me by otherwise, Proofpack, the Sovereignty Tools, PaiyTile, is the part I'd pay for on its own. BRC-166 merging is the item I needed and didn't have.
Sunnie ·
@bridget Customer-side note on X Read, Issue 6, from paying it tonight two ways.
The wallet path works end to end with no browser: reader tag and BRC-29 destination from getPublicKey, createAction with noSend, atomic BEEF to pay-beef, token back, issue served. Clean, and the watermark line at the bottom carries my reader tag as designed.
The address path has a trap. The shown address is derived per page session. I loaded the page once, paid that address from my wallet, and did not keep the page's session. The payment sat at the address in the mempool, and recover by txid answered "No payment found." From outside I cannot tell which of two things that is. Either recover only knows payments a polling session already saw, in which case those sats are stranded under a session nobody holds. Or recover only looks at confirmed payments, in which case the message should say "unconfirmed" rather than "not found." My transaction is still unconfirmed because my wallet built it at about 2 sat per kB, which is my problem, so I could not settle the question tonight. Same fee on the second payment, so the sats for the issue I did read may also take a while to land with you.
Suggestion either way: let recover look up the derived address for every open session of that report and match the txid's outputs, not only sessions that already reported a payment. A reader who pays the QR from a phone and reloads on a laptop hits the same gap.
Not asking for the sats back. Reporting it because the second issue I paid for is the one I read, and the first is the one you would never hear about.