From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id BD64DC002D for ; Sun, 2 Oct 2022 22:48:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 90E654030F for ; Sun, 2 Oct 2022 22:48:25 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 90E654030F X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K526NK_kdY6w for ; Sun, 2 Oct 2022 22:48:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9EBE040263 Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5]) by smtp4.osuosl.org (Postfix) with ESMTPS id 9EBE040263 for ; Sun, 2 Oct 2022 22:48:24 +0000 (UTC) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 4D9D3280085E; Sun, 2 Oct 2022 15:48:22 -0700 (PDT) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Sun, 2 Oct 2022 15:48:21 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 02 Oct 2022 12:48:21 -1000 From: "David A. Harding" To: Ruben Somsen , Bitcoin Protocol Discussion In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.10 Message-ID: <9f399e0c2713f2b1d2534cd754356bb5@dtrt.org> X-Sender: dave@dtrt.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 38bc.633a1535.7b061.0 Subject: Re: [bitcoin-dev] =?utf-8?q?Trustless_Address_Server_=E2=80=93_Outsou?= =?utf-8?q?rcing_handing_out_addresses_to_prevent_address_reuse?= X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2022 22:48:25 -0000 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