Thread

PV. nostr:nevent1qqst7d8xu4tqsks6kk2a45dlm2py8sdeedflp9y9qay29k8zgpds8sspzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyp778hhc6ggen3dv0wp8xh9nkma5sd7lhs7dxyct3lcgt4gv8p95xqcyqqqqqqgerp8ck

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?

Would be great to just forget about this silly debate and focus on actually important topics in bitcoin.

I think spam is an important topic in bitcoin

But still, core, it worked great so far.

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.

Back in the day it was obvious to everyone but the % of bitcoiners that understand spam's implications has been severely diluted in the last years. A downside of a growing community.

agreed, but what are these important topics you have in mind?

Soon: a bunch of Coretards are blocking Knots nodes, so you may want to spoof your client version. 🙄

Very well put

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.

Bitcoin Knots. Bitcoin is P2P Money, not a jpeg spam dumpster.

And boiling it down to just that is disengenious and I'll informed.

"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 https://github.com/bitcoin/bips/pull/2017

> 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.

"But empirically less of it."

The problem of a bloated chain seems miniscule compared to a black swan event that quantum computers could pose. We should rally to find solutions to that first before we get into issues like the spam debate. https://bip360.org/

You can hide content in signatures iiuc, so why worry about spam if its unavoidable?

Larp™️

Oh, I love empirical data! How much less?

Everything that doesn’t get mined! Which these days is nothing…

That's why we need UASF now

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.

https://ocean.xyz/blocktemplate/core At this particular moment, about 38.2 kB less

- 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 https://medium.com/@ottosch/how-bip47-works-ee641cc14bf3

> 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 https://www.npmjs.com/package/@samouraiwallet/bip47

> 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 https://r2a.primal.net/uploads2/7/96/3a/7963aebfe0332045cd8b735a8c5e6169a4f47d19346b2d0dc3b6d3a45b838ac2.mp4

> 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.

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