š
Original date posted:2022-10-02
š Original message: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
David A. Harding [ARCHIVE] /
npub16dā¦x4wrd
2023-06-07 23:14:04
in reply to nevent1qā¦kwwy
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-07 23:14:04Event JSON
{
"id": "9c38cdf933b70cfb6e3ba2af771b9595a74e51ffe42b374d241b98035c5fc099",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686179644,
"kind": 1,
"tags": [
[
"e",
"ea43f2af105feface907b52de43940c36932ecd5ba849c28f38155d42df5d943",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
Original date posted:2022-10-02\nš Original message:On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote:\n\u003e An alternative mitigation (more user friendly, but more implementation\n\u003e complexity) would be to require the sender to reveal their intended\n\u003e transaction to the server prior to receiving the address[^9]. This is\n\u003e not a privacy degradation, since the server could already learn this\n\u003e information regardless. If the transaction doesn't end up getting\n\u003e sent, any subsequent attempt to reuse one of the inputs should either\n\u003e be (temporarily) blacklisted or responded to with the same address\n\u003e that was given out earlier\n\u003e [...]\n\u003e [^9]: *This would essentially look like an incomplete but signed\n\u003e transaction where the output address is still missing.*\n\nHi Ruben,\n\nInstead of maintaining a database of inputs that should be blocked or \nmapped to addresses, have the spender submit to you (but not the \nnetwork) a valid transaction paying a placeholder address and in return \ngive them a guaranteed unique address. They can then broadcast a \ntransaction using the same inputs to pay the guaranteed unique address. \nIf you don't see that transaction within a reasonable amount of time, \nbroadcast the transaction paying the placeholder address. This makes it \ncost the same to them whether they use the unique address or not. By \nplaceholder address, I mean an address of yours that's never received a \npayment but which may have been provided in a previous invoice (e.g. to \nprevent exceeding the gap limit).\n\nIn short, what I think I've described is the BIP78 payjoin protocol \nwithout any payjoining going on (which is allowed by BIP78). BTCPay \nalready implements BIP78, as do several wallets, and I think it \nsatisfies all the design constraints you've described.\n\n-Dave",
"sig": "4f8fd0527a9cfe5fbce7d2f6fbcb618cbbac55377df6eed7ea508bff8dda1560a47972450a7d324c3febfc29284f60f79d4327e904c0154194717e3db5cf4526"
}