📅 Original date posted:2022-10-03
📝 Original message:Hi David,
Thanks for the excellent suggestion, that makes the protocol much more
elegant and actually increases my optimism about its practicality. Also,
interesting observation that there is overlap with BIP78. From the
perspective of the recipient it does mean there's a potential privacy
reduction when a placeholder transaction goes through (these should perhaps
be marked in the wallet?), but I suppose this is still better than no
payment at all. I also like your point that it doubles as a way to
potentially bridge gaps.
Cheers,
Ruben
On Mon, Oct 3, 2022 at 12:48 AM David A. Harding <dave at dtrt.org> wrote:
> On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote:
> > An alternative mitigation (more user friendly, but more implementation
> > complexity) would be to require the sender to reveal their intended
> > transaction to the server prior to receiving the address[^9]. This is
> > not a privacy degradation, since the server could already learn this
> > information regardless. If the transaction doesn't end up getting
> > sent, any subsequent attempt to reuse one of the inputs should either
> > be (temporarily) blacklisted or responded to with the same address
> > that was given out earlier
> > [...]
> > [^9]: *This would essentially look like an incomplete but signed
> > transaction where the output address is still missing.*
>
> Hi Ruben,
>
> Instead of maintaining a database of inputs that should be blocked or
> mapped to addresses, have the spender submit to you (but not the
> network) a valid transaction paying a placeholder address and in return
> give them a guaranteed unique address. They can then broadcast a
> transaction using the same inputs to pay the guaranteed unique address.
> If you don't see that transaction within a reasonable amount of time,
> broadcast the transaction paying the placeholder address. This makes it
> cost the same to them whether they use the unique address or not. By
> placeholder address, I mean an address of yours that's never received a
> payment but which may have been provided in a previous invoice (e.g. to
> prevent exceeding the gap limit).
>
> In short, what I think I've described is the BIP78 payjoin protocol
> without any payjoining going on (which is allowed by BIP78). BTCPay
> already implements BIP78, as do several wallets, and I think it
> satisfies all the design constraints you've described.
>
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221004/e94a81c6/attachment-0001.html>;
Ruben Somsen [ARCHIVE] /
npub1cn…qyeq0
2023-06-07 23:14:04
in reply to nevent1q…fnly
Author Public Key
npub1cnrnujx86le38yu2jrt3la0yhewsrh2p2lucakv6mu28x7lm0rsq9qyeq0Published at
2023-06-07 23:14:04Event JSON
{
"id": "4a3978daef5294cdbe18af494b31d3b09dc42376212306eb765caa8ab30918b3",
"pubkey": "c4c73e48c7d7f313938a90d71ff5e4be5d01dd4157f98ed99adf14737bfb78e0",
"created_at": 1686179644,
"kind": 1,
"tags": [
[
"e",
"ea43f2af105feface907b52de43940c36932ecd5ba849c28f38155d42df5d943",
"",
"root"
],
[
"e",
"9c38cdf933b70cfb6e3ba2af771b9595a74e51ffe42b374d241b98035c5fc099",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "📅 Original date posted:2022-10-03\n📝 Original message:Hi David,\n\nThanks for the excellent suggestion, that makes the protocol much more\nelegant and actually increases my optimism about its practicality. Also,\ninteresting observation that there is overlap with BIP78. From the\nperspective of the recipient it does mean there's a potential privacy\nreduction when a placeholder transaction goes through (these should perhaps\nbe marked in the wallet?), but I suppose this is still better than no\npayment at all. I also like your point that it doubles as a way to\npotentially bridge gaps.\n\nCheers,\nRuben\n\n\n\n\n\n\n\nOn Mon, Oct 3, 2022 at 12:48 AM David A. Harding \u003cdave at dtrt.org\u003e wrote:\n\n\u003e On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote:\n\u003e \u003e An alternative mitigation (more user friendly, but more implementation\n\u003e \u003e complexity) would be to require the sender to reveal their intended\n\u003e \u003e transaction to the server prior to receiving the address[^9]. This is\n\u003e \u003e not a privacy degradation, since the server could already learn this\n\u003e \u003e information regardless. If the transaction doesn't end up getting\n\u003e \u003e sent, any subsequent attempt to reuse one of the inputs should either\n\u003e \u003e be (temporarily) blacklisted or responded to with the same address\n\u003e \u003e that was given out earlier\n\u003e \u003e [...]\n\u003e \u003e [^9]: *This would essentially look like an incomplete but signed\n\u003e \u003e transaction where the output address is still missing.*\n\u003e\n\u003e Hi Ruben,\n\u003e\n\u003e Instead of maintaining a database of inputs that should be blocked or\n\u003e mapped to addresses, have the spender submit to you (but not the\n\u003e network) a valid transaction paying a placeholder address and in return\n\u003e give them a guaranteed unique address. They can then broadcast a\n\u003e transaction using the same inputs to pay the guaranteed unique address.\n\u003e If you don't see that transaction within a reasonable amount of time,\n\u003e broadcast the transaction paying the placeholder address. This makes it\n\u003e cost the same to them whether they use the unique address or not. By\n\u003e placeholder address, I mean an address of yours that's never received a\n\u003e payment but which may have been provided in a previous invoice (e.g. to\n\u003e prevent exceeding the gap limit).\n\u003e\n\u003e In short, what I think I've described is the BIP78 payjoin protocol\n\u003e without any payjoining going on (which is allowed by BIP78). BTCPay\n\u003e already implements BIP78, as do several wallets, and I think it\n\u003e satisfies all the design constraints you've described.\n\u003e\n\u003e -Dave\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221004/e94a81c6/attachment-0001.html\u003e",
"sig": "6126993375518d45a3368004315be2bd83ed3b5dc914d31ba2d6d0224048159de8ae0262a71938f53d36d77a649711a7991cba14b45a43ac40ee62ea673116ac"
}