From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 186E9C0012 for ; Sun, 12 Dec 2021 22:32:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id E54E740645 for ; Sun, 12 Dec 2021 22:32:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=willtech.com.au Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHT_1RKgMM5R for ; Sun, 12 Dec 2021 22:32:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from brown.birch.relay.mailchannels.net (brown.birch.relay.mailchannels.net [23.83.209.23]) by smtp2.osuosl.org (Postfix) with ESMTPS id 2B47C40010 for ; Sun, 12 Dec 2021 22:32:27 +0000 (UTC) X-Sender-Id: hostpapa|x-authuser|damian@willtech.com.au Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id AAF103415B2; Sun, 12 Dec 2021 22:32:25 +0000 (UTC) Received: from s110.servername.online (unknown [127.0.0.6]) (Authenticated sender: hostpapa) by relay.mailchannels.net (Postfix) with ESMTPA id 42DD63415A8; Sun, 12 Dec 2021 22:32:23 +0000 (UTC) X-Sender-Id: hostpapa|x-authuser|damian@willtech.com.au Received: from s110.servername.online (s110.servername.online [204.44.192.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.127.242.180 (trex/6.4.3); Sun, 12 Dec 2021 22:32:25 +0000 X-MC-Relay: Junk X-MailChannels-SenderId: hostpapa|x-authuser|damian@willtech.com.au X-MailChannels-Auth-Id: hostpapa X-Hysterical-Rock: 0749d8103ded27ce_1639348345453_4243421455 X-MC-Loop-Signature: 1639348345453:2522022827 X-MC-Ingress-Time: 1639348345453 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=willtech.com.au; s=default; h=Content-Transfer-Encoding:Content-Type: Message-ID:References:In-Reply-To:Subject:To:From:Date:MIME-Version:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kWiyxhaHVHSgI+XL0DUVUsgLMiOZag5mslfPR6gLjTg=; b=HtSU1ZUZdmSX1nXzcDUykbs33L zaYNbvvoYqGhlpnl0m4BDUKBnzT8FKtj7v+HjrRWEiwynJhXcxNtIjUDRW7fE2Or8FG1YS3rptyeT TTuhgLIpcFhRqCmR3MCPSXdd75VAtUmnhONsk54qZbOVmCFYnn2SX7IMpsMlzJSBVDrNnfz1jt1wD 2bIn+snLm6UAQreaunHu7NWFK4wY0rP0HRv3YYW2zKA9yV+MQWaQHBi/p8tjIPXzC9FDc0I6ppZPH 6m9be+usa2fNmB554rn1v6qnmstyk2iqslMohQILN5rbs+l0i0pJIJJsotovVtjw6fjDrx5yiDpVl svihZG7A==; Received: from localhost ([127.0.0.1]:47388 helo=s110.servername.online) by s110.servername.online with esmtpa (Exim 4.94.2) (envelope-from ) id 1mwXOH-001ieY-Dg; Sun, 12 Dec 2021 14:32:22 -0800 MIME-Version: 1.0 Date: Sun, 12 Dec 2021 14:32:21 -0800 From: damian@willtech.com.au To: Pieter Wuille , Bitcoin Protocol Discussion In-Reply-To: References: <1fbf0ef8b1b42979361b5df0b09c2dcd@willtech.com.au> User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: damian@willtech.com.au Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: damian@willtech.com.au X-Mailman-Approved-At: Sun, 12 Dec 2021 23:04:06 +0000 Subject: Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network 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, 12 Dec 2021 22:32:30 -0000 Good Afternoon, You are right, of course, I did nothing to differentiate between the privacy of the connection of the node, the identification of the public IP of the node, and the suspected original of a transaction. If I understand, the reason for only the originating node to rebroadcast was because only that node can be authoritative, but that logic is fallible once the transaction is signed - none of the nodes apart from the origin know about the transaction but they always manage to gossip. Anyway, it is concept ACK from me and I know it has been a concern that I have raised previously, I presume some pseudo-random and lengthening per attempt length of time between receiving gossip about a transaction and rebroadcasting attempts. I have always worked with `mempoolexpiry=2160` and `maxmempool=900` and so far as I can presume mempool has never been full. Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. On 2021-12-11 08:21, Pieter Wuille via bitcoin-dev wrote: >> It is that the solution to privacy is to use privacy-enhancing network >> communications, such as TOR. I am not against a mechanism to >> rebroadcast >> transactions more robustly if the mempool of adjoining nodes has >> forgotten about them, but the truth is, all transactions originate >> from >> some node, and there are methods that allow an individual node to be >> identified as the likely source of a transaction unless >> privacy-enabled >> networks are utilised. Having a different method to cause rebroadcast >> does not obfuscate the origin. > > You're talking about distinct aspects of transaction privacy. > > The rebroadcasting approach as it exists on the network, where wallets > are responsible for their own rebroadcasting, directly reveals to your > peers a relation between nodes and transactions: whenever any node > relays the same transaction twice, it almost certainly implies they > are the origin. > > This is just a node-transaction relation, and not necessarily > IP-transaction relation. The latter can indeed be avoided by only > connecting over Tor, or using other privacy networks, but just hiding > the relation with IP addresses isn't sufficient (and has its own > downsides; e.g. Tor-only connectivity is far more susceptible to > partition/Eclipse/DoS attacks). For example seeing the same node (even > without knowing its IP) rebroadcast two transaction lets an observe > infer a relation between those transactions, and that too is a privacy > leak. > > I believe moving to a model where mempools/nodes themselves are > responsible for rebroadcasting is a great solution to improving this > specific problem, simply because if everyone rebroadcasts, the > original author doing it too does not stand out anymore. It isn't > "fixing privacy", it's fixing a specific leak, one of many, but this > isn't a black and white property. > > Cheers, > > -- > Pieter > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev