From: Chris Belcher <belcher@riseup.net>
To: Lucas Ontivero <lucasontivero@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] PayJoin adoption
Date: Tue, 19 Jan 2021 15:44:11 +0000 [thread overview]
Message-ID: <828e0ad4-8fe6-7db9-630f-daae51c04c3a@riseup.net> (raw)
In-Reply-To: <CALHvQn3Z39cBLrtVfrd9_DGQnSZm9EuymoaaAB0qKWA4QYc2_w@mail.gmail.com>
Regarding incentives, privacy is itself an incentive.
If your business suffers from being spied on (for example you're a
casino or p2p exchange, and regulated exchanges keep banning your
customers) then the cost of adopting payjoin is worth it. That's why I
expect and hope that p2p exchanges will be one of the earlier adopters.
While researching for the Adoption page I was surprised to find that one
exchange has already adopted PayJoin: a no-signup altcoin exchange
called sideshift.ai
On 18/01/2021 20:38, Lucas Ontivero wrote:
> Hi
>
> Before all, thanks for the wiki page tracking the payjoin adoption, it is a
> good idea.
>
> -----
>
> Even when there is a reasonable economical incentive to use segwit
> transactions to save fees a big percentage of the transactions are not
> using segwit yet. In the case of payjoins the economic incentives are not
> so big while the privacy benefits are not so clear for the payer as they
> are for the global transactions graph as a whole. This means that payjoins
> requires some level of altruist attitude from the payers. The payjoins UX
> is also not good because I think most users are not familiar with bip21
> uris (users still request support because they pay a bech32 address in an
> exchange and the exchange tells them that's not a valid bitcoin address).
> All this is relative and subjective but in general terms I would say it is
> more or less true for many people.
>
> Anyway, imagine wallets' developers agree on making payjoins payment by
> default because it is the right thing to do (fight against surveillance to
> spy on bitcoin users and improve bitcoin's fungibility). In that case it
> should be completely transparent to the users and at not cost, it shouldn't
> require the user to do anything different, it shouldn't be noticeable
> slower, etc. In fact, users should have to know they are payjoining at all.
>
> The only way I see to achieve something like that is by moving to schemes
> where wallets can communicate and interact. I should be able to know
> something about you that allows me to select your name from my contact list
> and select "Pay to Chris" and if my wallet knows how to find yours then it
> can request a new address and pays, or generate a new one for you (probably
> using a output descriptor you created to share with me).
>
> Sorry for the long semi-random rant.
>
> El vie, 15 ene 2021 a las 21:07, Chris Belcher via bitcoin-dev (<
> bitcoin-dev@lists.linuxfoundation.org>) escribió:
>
>> PayJoin is an exciting bitcoin privacy technology which has the
>> potential to damage the ability of blockchain surveillance to spy on
>> bitcoin users and destroy bitcoin's fungibility. A protocol standard has
>> already been defined and implemented by a couple of projects such as
>> BTCPayServer, Wasabi Wallet, JoinMarket and BlueWallet.
>>
>> I've made a wiki page tracking adoption:
>> https://en.bitcoin.it/wiki/PayJoin_adoption
>>
>> It is similar to the Bech32 adoption page.
>>
>>
>> Recently a UK bitcoin exchange shut down due to new regulations, with
>> the owner writing a very interesting and relevant blog post that I'll
>> quote here:
>>
>>> you’re considered suspicious if you used a marketplace and not an
>> exchange. Coinjoin counts as high risk. Gambling is high risk. As you
>> use entities that are paranoid about keeping their coins clean and
>> adhering to all the regulations, your risk scores will continue to
>> increase and without you even knowing why, your deposits will become
>> rejected, you may be asked to supply documents or lose the coins, your
>> account may become suspended without you having any clue what you did
>> wrong. And quite possibly you didn’t do anything wrong. But that won’t
>> matter.
>>>
>>> The goal post, the risk score threshold will keep moving along this
>> trend until the point where you will be afraid of using your personal
>> wallet, donating to someone online, receiving bitcoins from anywhere
>> except for regulated exchanges. At that point, crypto will be akin to a
>> regular bank account. You won’t have a bitcoin wallet, you will have
>> accounts to websites.
>>
>> https://blog.bitbargain.com/post/638504004285054976/goodbye
>>
>> If we want bitcoin to fulfill its dream of a permissionless money for
>> the internet then we'll have to work on this. What can we do to increase
>> adoption of PayJoin?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
prev parent reply other threads:[~2021-01-19 15:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-16 0:07 [bitcoin-dev] PayJoin adoption Chris Belcher
2021-01-16 2:52 ` dev_f
2021-01-16 6:15 ` Craig Raw
2021-01-18 20:38 ` Lucas Ontivero
2021-01-19 15:44 ` Chris Belcher [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=828e0ad4-8fe6-7db9-630f-daae51c04c3a@riseup.net \
--to=belcher@riseup.net \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=lucasontivero@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox