Hi all,
I'm publishing a payjoin upgrade in response to a request from this list. The
payjoin receiver no longer has to run a public server. They lean on a relay for
the connection and share a symmetric-key for security rather than a TLS
certificate or a Tor hidden service.
I think this work
Funding channels on a lightning node can be a pain. First, I need to send funds
to my node on-chain. Then I need to make another transaction to open channels.
Instead, we can use the BIP 78 PayJoin P2EP protocol to fund and open channels
in a single transaction.
We do not communicate over the
Address expiration does seem to be a generic problem, but Silent Payments could
play a role in solving the problem once and for all. Payment requests often
have expiration in practice because of moving exchange rates but no way to
communicate that to sending software. BTCPay checkout page
s is ameliorated
>> (though not removed) as a vector, but then we'd need to be clear that we
>> require those (e.g. Tor). Not sure if it's palatable to do this if
>> otherwise, i.e. if we think the relays can tie network addresses to
>> transactions? Well, not sure, but I'd ex
Hi all,
The Serverless Payjoin idea has come a long way toward formal specification of
a Payjoin version 2. In the spirit of BIP 2, I’m sharing an intermediate draft
of the BIP here before opening a draft on GitHub for the BIP editors, and
before this exact specification has a complete
Hi list, The following message details a number of examples using payjoin P2EP
to coordinate payment batches. I stray from the original shape of stenographic
payjoin, what I call "canonical payjoin" with 2 inputs and many outputs, to
describe what I believe are novel structures that break
Thanks for weighing in Dave,
> On Aug 13, 2023, at 8:00 AM, bitcoin-dev-requ...@lists.linuxfoundation.org
> wrote:
>
>
> The way BItcoin users currently use BIP21 URIs and QR-encoded BIP21 URIs,
> posting them where evesdroppers can see
>
> …
>
> I don't think it would be practical to
Blockchain Commons UR seems to be the most elegant choice since QRs are
commonplace. This suggestion, along with Adam’s to reconsider DH over symmetric
crypto would let us encode a pub key directly in the `pj=` endpoint rather than
with a separate am somewhat concerned that some payjoin
