Future me: you want to run a node? Great! There are 2 main kinds: Core and Knots. The main difference between them is how they approach spam. Core takes a welcoming stance toward spam transactions, whereas Knots filters them out as much as possible. Which one do you want to run?
Discussion
Knots. But "spam" is the wrong word. It can be sub divided into harmless and harmful.
In this case I would prefer to use core
because by default running knot node will filter BIP47 or tx0(zero) transactions that Inorefer to use everyday for my use case
So if I choose knots I’m out of luck
What do yuu say to that?
Its incredibly easy to change a configuration option lmao
Meanwhile core is deprecating (theyve walked it back, for now, but theyll be back at it again when people forget) incredibly important options
Sounds pretty simple to me
I am glad you are making an informed decision. :)
Also, I recommend ceasing use of bip47. Silent Payments are imo a superior way to do what bip47 does.
Also, I hope a new version of samourai's protocol becomes popular that fixes the part of tx0 that makes it incompatible with the default mempool policy in knots. If their protocol uses an op_return, it shouldn't imo.
Silent payment is right now unusable for light mobile clients so not a solution tonreplace bip47, I don’t need a separate scanning server for SP, BIP47 is serverless
Op_return in Tx0 ther for a reason and it uses standard 83bytes there is nothing spammy about it
The op_return contains info allowing the server to verify that the fee was actually paid to a publisher. It's an anti-spoofing mechanism. If the fee is not seen on chain then the inputs are not registered. It also allows to NOT use a static fee for address collection.
> Silent payment is right now unusable for light mobile clients so not a solution tonreplace bip47, I don’t need a separate scanning server for SP, BIP47 is serverless
I don't think silent payments requiring anything more than bip47 does. How does your Bip47 wallet identify which blocks contain payments for it? If you look into it, I suspect you'll find it is by getting information about blocks from a server, which is how SP wallets do it too
> Op_return in Tx0...contains info allowing the server to verify that the fee was actually paid to a publisher
If the publisher tells their fee address to the server, the op_return is not needed. Neither solution requires a static fee address
>. It's an anti-spoofing mechanism. If the fee is not seen on chain then the inputs are not registered. It also allows to NOT use a static fee for address collection.
- BIP47 doesn't rely on any trusted server.
In the example, Alice is paying Bob:
1- Alice gets Bob’s payment code. Besides some metadata, this code contains Bob’s xpub at derivation path 47;
2- Alice prepares a notification transaction. She selects one of her UTXOs and creates a shared secret S = k.B, with k being the private key of one of her UTXOs and B being the first public key of Bob’s xpub.
She encrypts her own payment code applying XOR between her code and HMAC-SHA512(o, Sx), with o being the previous outpoint of the UTXO and Sx being the X coordinate of S;
3- She sends the transaction to Bob’s notification address, which is the first address of Bob’s xpub, including her encrypted payment code in the op_return;
4- Bob reads the op_return, finds S = b.K, with b being the private key of B and K being the public key of k. Bob gets K and o from the notification transaction. With that info, he is able to retrieve Alice’s payment code;
5- Alice can now derive new addresses and send payments to Bob by multiplying the private key a from her payment code and Bob’s public keys B0, B1, B2 etc from his payment code.
Bob will do the opposite: b0.A, b1.A, b2.A etc;
More on this here and no bip47 does not use any servers
> Bob reads the op_return
How does he do that without contacting a server? The OP said he uses bip47 on a mobile phone, so it is very unlikely that a copy of the blockchain is on the device. Therefore, unless you are in the very special circumstance of actively syncing blocks on your mobile device, your bip47 wallet contacts a server.
Sorry, not "The OP said he uses" -- I meant "you said you use"
BIP47 doesn't require any centralized backend servers. Bip47 addresses are generated client side and outside of the xpub space. If you choose to query that address through someone else's node then of course you receive degraded privacy but that node has 0 knowledge the address is a PayNym derived one.
Think of this
Paynym.rs isn't a modified version of BIP47. It's a directory.
A metaphor:
- BIP47 payment code <=> PGP pubkey
- paynym.rs <=> PGP keyserver
their is no paynym server paynym.is just host Pepe bots which is represented by pm8 number and derived from your private key. bip47 is serverless. All you need to share or to publish for BIP47 is a payment code, like this:
PM8TJUAu8QqW5WasFvDUH4qcviw8aCdcJfwkzHMM4KjkduyoN7yXtL5fxCtotcg5wrxpHRRbuQVD3XHzz2RzDCD58TzCrRwPw1xyUbRLdeds9ygNwxty
But the fact that I've shared this payment code with you on doesn't mean that servers are required for BIP47. One can publish the payment code whereever you wish (e.g.: 3rd party directory, personal website hosted by yourself). More important: It just need to be retrieved once by your counterparty.
you publish your payment code, then a thousand people can send btc to a thousand different addresses without any leakage as there was no need to share those addresses at all
Here
> If you choose to query that address through someone else's node then of course you receive degraded privacy
Sir, that's a server, and mobile wallets all require it except for the very rare case where a mobile device itself actively syncs blocks and parses them on its own
Silent Payments are better for several reasons. Two of them are: (1) with silent payments, you can run it (even on a mobile device) *without* querying someone else's node about your address (2) it doesn't require putting a notification transaction on the blockchain, which costs money and puts needless data on it
Well bip47 does not require notification txn. If both parties online one just shares pm8 code and there is no need for notification txn
Notification txn requires only if one party is offline
you just follow each others paynym and use cahoots using soroban like in this video example of stowaway txn (payjoin) there is no need to make notification txn at all unless other party is offline or you know you will be paying same entity repeatedly when they are offline then use notif txn. Here video example inside wallet
Silent payments are a better protocol than bip47 because they allow you to send payments to *offline* people without a notification transaction, repeatedly, and because both protocols, when run on a mobile device, require a server's assistance anyway, apart from a rare exception where the mobile device is actively syncing the blockchain (in which case neither protocol needs a server's assistance, except to sync the blocks)
BIP47 is first and foremost for entities who send/receive repeated payments to/from their counterparties. Examples of such entities are exchanges, mining pools, companies paying salaries to their collaborators, merchants, etc
and trying to address these entities make a lot of sense because most occurrences of address reuse are now caused by these entities. And sadly, it has a huge impact on the privacy of everybody. Silent Payments are not a better solution than BIP47. They don't even try to address the same target .
The point of the notif tx is that it doesn't require a synchronuous comm' between the 2 entities, it communicates the "identity" of the sender and it acts as a backup of the derived keys for the receiver. The partially public aspect of the notif tx is the price paid for that.
There is no server. Plus The notification transaction for BIP47 is an advantage, not a disadvantage. It makes you less likely to be dusted as a receiver and, as a sender, you don’t have to construct transactions with a taproot output - a script type that no one serious about on chain privacy uses. While SP are a magnet for dust attacks, have a significant scanning overhead for wallets and they require a taproot output in a tx too which is a negative.
the only difference between SP and BIP47 is that BIP47 requires for each output a lookup against n monitored addresses while SP requires these lookups + the computation of P0. This additional work is independent of the number of addresses tracked by the node, hence the claim that labels improve the scalability of SP
There's is still an additional load (computation of P0) but it scales with the number of outputs, not with the number of tracked addresses. Main benefit is that the former is bounded (by the max blocksize) while the latter is potentially unlimited...
Anyway Silent payments has significant performance and computational costs for the block scanning and key derivation.
It must scan every output of every block for every user. Recovering a wallet would require rescanning every output of the entire blockchain from wallets creation
Another difference is in terms of the security model associated to each mode. In the case of SP, b_scan (scan private key) must be known by the node monitoring the blockchain while BIP47 only requires public information (public keys).
BIP47 is Serverless: GROK knows 
Would be great to just forget about this silly debate and focus on actually important topics in bitcoin.
Soon: a bunch of Coretards are blocking Knots nodes, so you may want to spoof your client version. 🙄
Very well put
Bitcoin Knots. Bitcoin is P2P Money, not a jpeg spam dumpster.
"So, if I run knots my node won't get spam?"
"Oh, no, you'll still have it."
More knots less spam
Good morning Rusty! But we dont embrace it, right?! You seemed to have given up and opened the floodgate
"But empirically less of it."
Oh, I love empirical data! How much less?
Everything that doesn’t get mined! Which these days is nothing…
Well, it's not obvious to me, even if that's true. You will probably receive it twice (once to discover you don't want it, then once again when it's in a block anyway?) but you won't send it (except maybe with the block again?). I don't know the details of tx and block relay. And I'm not sure what fraction of txs these filters apply to, either.
This is why I was interested in the claim of empirical results, but maybe nobody has actually measured, which is sad.
> You will probably receive it twice (once to discover you don't want it, then once again when it's in a block anyway?) but you won't send it (except maybe with the block again?)
Yep.
I assume someone has stats on what % of transactions Knots rejects. I imagine it’s fairly high given all the inscriptions out there (which I believe it blocks?). But not sure if “high” is 5% or 30.
https://ocean.xyz/blocktemplate/core
At this particular moment, about 38.2 kB less
That's why we need UASF now