# BIP47

What is the opinion of BIP47 here? I keep finding myself circling around the concept but I dislike the complexity and the onchain footprint for initial handshake. However, the onchain handshake feels important as a ddos prevention mechanism so that malicious users do not "handshake" with you infinite times and you end up following x amount of xpubs.

Lucas Ontivero Apr 5th at 6:13 PM
We have discussed it a million times and there is not unanimous decision.
IMO it allows the best UX at a quite high technical cost. From the privacy point of view there are many things that bother me too. The cost is also something to have in mind once onchain fees are high forever. Finally if we are right and in the near future all devices will be on and connected all the time then there will be no need for things like bip47 because my wallet will ask your wallet for an address in a very similar way as p2ip was working in bitcoin nodes (edited)
:point_up:
2

48 replies
Also sent to the channel

Kukks 5 days ago
Ah sorry for bringing it up then, slack is the destroyer of useful history :slightly_smiling_face:

Lucas Ontivero 5 days ago
no no, we have discussed it during meetings.

Lucas Ontivero 5 days ago
that are not recorded

Kukks 5 days ago
I am also on the same boat, but find that a 1:1 handshaked identity could also be useful beyond a simple address sharing

Lucas Ontivero 5 days ago
yes, of course. Samourai use it for creating shared keys and encrypt the communication with their "soroban" server

Kukks 5 days ago
I've been looking at some much simpler online-based alternatives, which wcould probably be extended to provide a similar functionality to bip47 without the footprint, but the ddos vector is my biggest issue since blockchain scanning is also expensive in its own way

Lucas Ontivero 5 days ago
You don't really need bip47 for having a DH shared secret with other, you only need pubkeys

Lucas Ontivero 5 days ago
with taproot script the pubkeys will be in the scriptpubkey so you will be able to do DH with anyone

Kukks 5 days ago
I've been very interested in the simplicity behind a project called Paystring (paystring.org) but it was spearheaded by Ripple and all their initial ideas complete go against all privacy practices so I have a few proposals that I need to flesh out on that

Kukks 5 days ago
Ah i'm not particularly worried about the crypto, just the UX for the end users, which is what appeals to most users of the curren BIP47 userbase

Lucas Ontivero 5 days ago
if you don't need to be compatible with other then you can implement very cool things

Kukks 5 days ago
for example, it would let users running a btcpay to just publish a public identity as kukks$btcpay.org and then you can resolve addresses, handshake with public keys, p2ep, etc

Lucas Ontivero 5 days ago
you could generate an ouputdescriptor ancoded as a qr code and import that in your wallet and then you have the same

Kukks 5 days ago
yeah exactly, though you need to generate an output descriptor per user, and make sure there is some good form of dos protection as you'll end up tracking a thousand xpubs (edited)

Kukks 5 days ago
which is what cricles me back to bip47, because the handshake serves as a good dos protection, albeit very wasteful..

Lucas Ontivero 5 days ago
anyway, we discuss this same thing so many times that nopara is starting to hate me. @nothingmuch is on the side of those who thinks bip47 is good

Lucas Ontivero 5 days ago
perhaps he can provide more useful comments than me

Kukks 5 days ago
Thanks for the input :slightly_smiling_face:

Kukks 5 days ago
Constant discussion means there is something that needs to be built, so I think there's no reason for any hate :smile:

nothingmuch 5 days ago
i don't think bip 47 is good actually

nothingmuch 5 days ago
i think it works in a very constrained set of use cases, but one of them is important - being able to receive donations while offline without address reuse

nothingmuch 5 days ago
i think the biggest problem is there's no clear way to revoke these codes

nothingmuch 5 days ago
and that for most payment use cases p2ep is strictly better in many regards

nothingmuch 5 days ago
and the notification transaction thing is a big problem even for the use case it's good for... with wabisabi we might be able to make it less painful but i don't know

nothingmuch 5 days ago
i think the right building block is strong, PKI less authentication in two scenarios: point of sale or customer merchant case, where customer authenticates client (once or repeatedly), or mutual authentication case where two parties verify each other (i.e. adding a contact)
in physical space QR codes allow ~256 bits of entropy to be exchanged, enough to give a strongly authenticated hidden service address
when humans are part of the channel, i think PAKE gives the nicest UX - use a one time code (~3 seed words), the clients rendezvous with a centralized server, do PAKE and exchange hidden service addresses
once the wallets have that they can communicate over tor in a variety of settings and do P2EP or exchange single use addresses, i think that would be better than BIP 47 in almost every scenario

nothingmuch 5 days ago
another approach that is interesting is something like Gnunet's GNS

nothingmuch 5 days ago
especially more recently, now that gnunet supports user IDs and messaging (i need to look into that)

nothingmuch 5 days ago
also i think paystrings are analogous to this kind of authentication, but ultimately they delegate authentication to CAs/DNS since they are just fancy URLs

Lucas Ontivero 4 days ago
with Tor, cjdns and i2p the authentication problem is solved and then these paystrings are just the p2ep that we have in mind

nothingmuch 4 days ago
i think they are a bit overly complex personally

nothingmuch 4 days ago
i.e. the discovery protocol to get that syntax working assumes a lot of infrastructure

nothingmuch 4 days ago
there's lots of hidden trust

nothingmuch 4 days ago
but yeah once at least one party has a cryptographic identify of the other side that should be enough to do any p2ep protocol

nothingmuch 4 days ago
so i think that's really the fundamental problem - how to make a smooth UX that (mutually) authenticates ~32 bytes of data used to establish that

Kukks 4 days ago
Yeah and one thing i would love to focus on is making it dead easy for interopability. BIP47 never took off because it is arguably complex to integrate. I especially like the DNS option since any noob web dev can get it running most likely

Kukks 4 days ago
at least for the simplest option of wanting to send X to user Y

nothingmuch 4 days ago
that makes sense both for public, human meaningful identifiers, as well as for authenticated contacts

nothingmuch 4 days ago
UX wise I think that should flow very similarly for both

Kukks 4 days ago
then we can do user X "pairs" with user Y and creates a bond -- where both share an output descriptor to one another for the offline payment capability of a bip47

Kukks 4 days ago
and then p2ep of course is natural

Kukks 4 days ago
and then we can start creating trade agreements with DLCs but that's for when we're at a bar during a bitcoin conference ad we're drunk :smile: (edited)

nothingmuch 4 days ago
isn't it a single p2ep to establish a blockspace-cost-free alternative to bip47 notofications?

Kukks 4 days ago
sure, yeah, i was thinking thinking of a from-to dual thing where you establish a pair between identities

Kukks 4 days ago
but yes, 1 p2ep would be enough as well

Kukks 4 days ago
it depends on what capabiltiies you aim for i guess

nothingmuch 4 days ago
if it's p2ep it needs no special tagging for discovery since it includes a spend by the receiver, that's very nice

nothingmuch 4 days ago
if payjoin p2ep

transisto 2 days ago
I'd like to add that Samourai paynym has always been buggy AF for me, I don't think that many people use it. (edited)