Kortik 🇦🇲
kortik@no.str.cr
npub15lmj...2796
BIP47 | Artsakh | Արցախ | Sznek | Սզնեք | Nodl | Cello
PM8TJP7RYWNosUvkvj6zoV6QwhJLfQWc4fhVsp7ZWq1WR3HU3f4uUk2yuefEedzF97QMhcPfdphZEXyhWanh6ZgPUDVPmxjW9j51Wt2zHwgPvKVkdqxR
Notes (12)
Hashing to my own node/stratum server
Was able to squeeze an average of ~2th/s out of bitaxe gamma single BM1370 chip


.
Imagine It’s 2015 tools are already here to spend w/out deterministic links haters in disbelief because red wallet “mean” they tell the truth right in your face and hurt those fragile 😭 feelings.
10 years later they proofed red wallet superior, why because it works and devs jailed because of that fact that wallet does what it’s programmed to do - break deterministic links
why because forces that fight SW wants to set their own standards for everyone to spend bitcoin with deterministic links it’s obvious
Therefore
Learn how to spend bitcoin properly without deterministic links or
all your spends deterministic
Code is speech and speech always wants to be free
The only wallet that brakes deterministic links that no one can fuck with
there is no other zerolink protocol that breaks deterministic links on this planet


..
Writing code is not a crime!
https://www.pod256.org/episodepage/096-from-open-source-to-federal-sentence-the-government-vs-samourai-wallet
. #freesamourai


.


BIP47 is primarily designed for entities handling repeated payments to and from counterparties—think exchanges, mining pools, salary-paying companies, merchants, and the like. Targeting these players makes perfect sense, as they're now the biggest culprits behind address reuse, which erodes privacy for the entire Bitcoin ecosystem.
Silent Payments (SP), by contrast, aren't a superior alternative; they simply don't aim at the same high-impact users or problems.
Although one does not require notification txn if both parties are online and actively interacting synchronous P2P via Soroban. https://medium.com/samourai-wallet/wallet-update-0-99-96-introducing-soroban-adc9a36a7ddb
A standout feature of BIP47 is its notification transaction, which eliminates the need for synchronous communication between parties. It seamlessly conveys the sender's identity while serving as a key backup for the receiver—all without relying on any server infrastructure. Yes, this introduces a partially public element, but that's a worthwhile trade-off for true serverless operation.
Far from a drawback, the notification transaction is a clear win: receivers are far less vulnerable to dusting attacks, and senders avoid crafting transactions with Taproot outputs—a script type that privacy-conscious users rightly shun for on-chain exposure.
SP, meanwhile, invites dust attacks, burdens wallets with heavy scanning overhead, and still demands those privacy-compromising Taproot outputs.
The core operational gap between the two - BIP47 involves checking each transaction output against a set of monitored addresses (say, n of them), while SP piles on extra work by computing the P0 value for every output scanned.
Crucially, this P0 computation in SP is decoupled from the number of tracked addresses, which is why some argue labels could boost SP's scalability.
But don't overlook the serverless edge here: BIP47's model keeps everything decentralized and lightweight, with no central coordinator or server to introduce single points of failure, trust assumptions, or downtime risks.
SP's added load—tied to output volume rather than tracked addresses—may scale with block size limits, but it still demands scanning every output in every block for every user, ballooning computational costs in a fully serverless setup.
Wallet recovery under SP - That's a nightmare: reprocessing the entire blockchain's outputs from genesis.
And on security - BIP47 stays lean and public-key-only, exposing nothing sensitive during monitoring.
SP, however, requires the scanning private key (b_scan) to live on the node doing the heavy lifting - a risky concession in any serverless environment where nodes must operate independently and securely.
BIP47's serverless purity keeps privacy robust without these compromises.
look at the picture of what it looks like on the recivers end one can even Refund and notification txn lets you prove recovery process.
Do you still need BTCPay Server? no need for complicated server set up or domian hosting etc... just post your PM8 and you are done.
IYKYK adding instance of fulcrum to it instead of electrs
. Getting that directed into the HVAC Intake to heat my place and decentralize mining hashing towards my own instance of Bitcoin Core and Stratum server. As Decentralized as it gets no POOLs no worries!
Here is a stonewallx2 Collaborative txn using two wallets each party shares txn fee over soroban no other wallet can do this.
In a stonewall txn the dummy output goes back to the original wallet owner and the payment goes to the merchant. In a stonewallx2 this video, the tx initiator makes a payment with an output to the merchant, and the collaborator gets an output back for the same amount.
Stonewall breaks the common input ownership heuristic because it has coinjoin identical output sizes.
An observer of a stonewall tx has to decide if it is a stonewall or stonewallx2. But there is no way to tell by looking at the transaction.
https://blossom.primal.net/cfc0b331b86b52e123977894e7f4071b225459d53716585baf2e23996e739ed2.mp4
Samourai Wallet (Ashigaru) follow each others Paynym and use cahoots over soroban like in this video example of Stowaway txn (Payjoin) there is no need to make any notification txn at all unless other part is offline or you know you will be paying same entity repeatedly then use notifx tx. if sending pamen to a BIP47 Paynym just follow each others nyms and that is it https://blossom.primal.net/7963aebfe0332045cd8b735a8c5e6169a4f47d19346b2d0dc3b6d3a45b838ac2.mp4