# 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)
Last changed by  
 
BitcoinDesign
BitcoinDesign Notes
450

Read more

Social / P2P Payjoin

A payjoin is a type of coinjoin which is just between 2 parties. The sender and receiver both add their inputs and outputs and sign the transaction. This interaction results in a transaction that makes it difficult to fingerprint the transaction and determine which direction the payment is being made. It looks like any normal transaction. This provides a “cheap” way to confuse outside observers about the direction of the payment. Who is sending to who? Payjoins are mostly used by online merchants. Since both the sender and reciver both need to collaborate on a payjoin transaction. Your wallet will handle this in the background by connecting to the merchants server to do the exchange of the transaction file. In a social peer-to-peer setting the sender and reciever probably don’t have a server setup how do they do this exchange?

2/16/2023
Untitled

I also like the idea of having an expert mode, and having most features hidden by default. There are some thing that won’t be very useful to “Noobs” but essential for pros

10/27/2021
JoinMarket

Actors Maker Taker set up JM data dir, connect to core, create JM wallet in core, create .jmdat and validate backup/recover wallet and rescan Jobs to be done Lock up bitcoin to earn yield (who? why?)

10/27/2021
Untitled

Bitcoin Backups :::info Since slack often deletes history and we lose some interesting perspectives here is a record of one such thread. ::: Daniel Nordh Oct 18th at 4:02 PM Will an interoperable standard for backups supporting Lightning state ever happen? I posted a question in the LDK slack, not encouraging: 15 replies

10/26/2021
Read more from BitcoinDesign
Published on HackMD