RT @Excellion: A lot of time had passed with little progress on #P2EP adoption as a common standard, so we decided to jumpstart it with the @BtcpayServer team. My strategy was to create a pool of anchor tenants for #BlockstreamGreen & other light wallet users to transact with. 🔒⛓ https://t.co/yxFJmgo7Yi
RT @adam3us: #bitcoin privacy and fungibility needs improving, the design consideration is to render taint-tracing inoperable. one pragmatic step towards that future is P2EP aka PayJoin https://t.co/kAZnI8tqHX lets do this in wallets with p2p PayJoin and with shops and merchants. https://t.co/EOU9IxBgj2
#bitcoin privacy and fungibility needs improving, the design consideration is to render taint-tracing inoperable. one pragmatic step towards that future is P2EP aka PayJoin https://t.co/kAZnI8tqHX lets do this in wallets with p2p PayJoin and with shops and merchants. https://t.co/EOU9IxBgj2
Hmm, with this we have Bitcoin wallets communicating with each other over the Internet. There is not only the obvious problem that this new P2EP transaction type can't work with one of the parties not online when needed, and cannot make payments to cold wallets (keys need to be around to sign outputs):
I see also dangers of "rogue" P2EP enabled wallets, e.g. with new ways of making denial-of-service attacks possible, maybe making transactions fail by quickly spending the outputs that they hand out to take part in the CoinJoin etc.
I probably don't know enough about the exact inner workings of Bitcoin transactions, and lack the creativity of hackers, but I do think that this will open new dangers.
Here we go again. Lots of noise and fanfare on social media from people that really ought to know better, trumpeting their latest "solution" to Bitcoin's fundamental privacy problems. Their hope seems to be to simply drown out the reality that it simply cannot be "fixed" with tricks and second layer solutions.
Just as before with LN: which hasn't added any meaningful privacy, CJ: which has led to censorship and this, which only even half attempts to fix cherry-picked specific cases.
i mean, its a clever hack. How it will hold up who knows. I don't really see how it fixes the problem. Sounds like it might open up a nice new MITM though.
though i like the plug for privacy
> Transaction privacy is especially important for merchants because they come into contact with so many transactions from different customers. After identifying a single Bitcoin address belonging to a merchant, any customer can potentially use blockchain analysis to determine how much money a business is making and how many customers the business may have—information competitors or thieves may find very valuable.
It's a disingenuous plug for privacy IMO, a marketing/PR story.
With regards to its actual effectiveness, it's already quite clear it only attempts to actually tackle a very narrow subset of the gaping Bitcoin privacy problems.
Unfortunately there will be lots of people that latch onto this (just as they did with LN and CJ) thinking Bitcoin is now private, again.
I never said that. I was saying that no bolt-on privacy measure that’s added to Bitcoin could ever make Monero obsolete. That doesn’t necessarily mean that Monero will one day completely take over or anything like that. I think your assessment is probably right, unfortunately.
It doesn't keep you from creating a transaction graph, just makes it a little bit harder.
To be fair, you can still *try* to make a transaction graph in Monero, albeit with a higher degree of uncertainty.
"BTCPay Server uses a modified and expanded version of BIP79 Bustapay. If you’re interested in learning how it works and want to add support to a specific wallet, read our specification here."
Clicking on the link to the specification, I came across this paragraph:
"Another proposition is to allow one wallet to support both, P2WPKH and P2SH-P2WPKH. But this is problematic as it is non standard so no wallet or tool supports fund recovery for such a type of wallet."
I believe /r/mycelium figured out a way to do this, as one mnemonic seed can give you 3 types of addresses. /u/giszmo is this true?
Pinging /u/CardCollector1. Reposting in the other thread to foster discussion there.
The Mycelium Bitcoin Wallet for Android treats the legacy, the p2sh segwit and the segwit "Account 3" as one "Account 3". This way you don't need to switch to a different account to receive to a different type of address but as other wallets follow the word of the BIPs, they don't mix those accounts, so one account from Mycelium might appear as 3 accounts with funds jumping between those on other wallets.
It is not really too hard:
A seed is the main thing to store. From a seed, you derive root HD keys, often referred to as xpub, ypub & zpub ( legacy format, p2sh segwit, segwit) and generate addresses in each format from there. Our main difficulty is the existing code base for BTCPay focuses on having 1 wallet format only. UX wise, giving the user an option to choose formats is also a tricky matter.
Recovery wise, it should be simple (except for non segwit, since we cannot scan this through Core, but we dont care since it is not supported by Payjoin anyway), just do the recovery method for each format and you're good to go.
Another way I was thinking of solving this input incompatibility was to do a hop to a freshly generated bitcoin address of the correct format and then initiating payjoin from it, but i need to see more if it is feasible.
Are there any proposed icons for P2EP so you know what icon to click at the checkout page?
Update: The payjoin demo page has the "incognito-man" as the icon for payjoin. I'd propose the cart / checkout have the Orange-B for BTC, the Orange-B with lightning superimposed for BTC-LN, and the Orange-B with incognito-man superimposed for BTC-PayJoin.
No need to distinguish, your wallet should recognize it, it's quite smooth checkout experience. And if you want to manually copy, just copy "payment link" in btcpay invoice. You can try with btcpay internal wallet for example.
Ohh cool... They are using the little "incognito" icon. I'm good with that.
To my previous point. I'm not concerned that my payment won't work, my concern is that I don't want it to work unless its payjoin. What I'm looking for is a "Payjoin garanteed" channel.
Most of the shops that could benefit from PayJoin would benifit by assuring their customers that it won't fallback to a traceable payment channel.
So Incognito-Man superimposed on the Orange Bitcoin B. Perfect.
Ok I can see the separate payment link for payjoin with unique icon, but there is a bigger issue because payjoin will automatically defaults to sending a nonpayjoin transaction if there are any problems with communication between the wallets according to this documentation
>"If a connection cannot be established, a non-P2EP Bitcoin payment will be made instead."
Thus I think the bigger issue is on the wallet side where wallets at least warn the user that a P2EP cannot go through and offer them an opportunity to send normally or cancel the tx so they can send later and preserve their privacy.
The UX wallet side would be ok because a payjoin qr is uniquely different than regular QR so the wallet would only prompt the user if there is a failure(rare) when sending to a payjoin address... but this would require a different logo as you indicate differentiating the QR code as well because P2EP is optional when one creates the store. I don't know if replacing the B is a good idea because btcpay already accepts certain alts so this would get confusing however.
Perhaps leave the logo and just focus on the wallet side alone because ultimately there are 2 issues. Have the wallet (like blockstream green) recognize the payjoin QR code when scanned and than tell the user its a payjoin tx where they can back out if its not and if it fails another popup occurs? This would eliminate the need for changing the merchant side QR code change
What are your thoughts?
"Thus I think the bigger issue is on the wallet side where wallets at least warn the user that a P2EP cannot go through and offer them an opportunity to send normally or cancel the tx so they can send later and preserve their privacy."
This is not just for a smoother ux flow, it is a security measure for the sender. If the sender has created and signed a fully valid transaction, and has tried to send it over to the store to coordinate a payjoin but for any reason, failed, the store can publish that transaction at will at any time to receive the funds. In fact, if a payjoin transaction is proposed and the sender does not sign and broadcast on time, the store does exactly that.
>store can publish that transaction at will at any time to receive the funds.
Gotcha, Thus the store can finish a nonpayjoin tx ruining the users privacy.
So should I submit an issue for blockstream green or wasabi to make sure they are aware of this wallet side UX issue or do you think they are already aware?
> Please read the specs to understand why it is that way.
~~Link?~~ Found it. Why isn't there a BIP for this? BIP079 and BIP174 only cover aspects of this, not its entirety.
Further explanations here (article): https://www.coindesk.com/btcpay-looks-to-anonymize-bitcoin-transactions-with-payjoin-integration
Or here (talk by Adam Gibson / u/waxwing): https://twitter.com/udiWertheimer/status/1250873748409978888