1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
|
Return-Path: <damian@willtech.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 186E9C0012
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <damian@willtech.com.au>)
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-dev@wuille.net>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <dSBrti8VFr0lMNgTHw8pD-mAPLm0E4auJa234o0FNY67EUuEy1Dfb93INNIzoUb3j2dWSJjZtG7qncci1LhKAHOXzAzbEWOtXjnggr19J6w=@wuille.net>
References: <MqZttWy--3-2@tutanota.de>
<1fbf0ef8b1b42979361b5df0b09c2dcd@willtech.com.au>
<dSBrti8VFr0lMNgTHw8pD-mAPLm0E4auJa234o0FNY67EUuEy1Dfb93INNIzoUb3j2dWSJjZtG7qncci1LhKAHOXzAzbEWOtXjnggr19J6w=@wuille.net>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <a249de6ad8bbd739612e4b177459c626@willtech.com.au>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
|
