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
|
Delivery-date: Sun, 20 Oct 2024 00:01:29 -0700
Received: from mail-yb1-f185.google.com ([209.85.219.185])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBQGV2K4AMGQEMBVZH5Q@googlegroups.com>)
id 1t2PwO-000337-7g
for bitcoindev@gnusha.org; Sun, 20 Oct 2024 00:01:28 -0700
Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-e28ef71f0d8sf6568602276.0
for <bitcoindev@gnusha.org>; Sun, 20 Oct 2024 00:01:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1729407682; x=1730012482; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:sender:from:to:cc:subject:date
:message-id:reply-to;
bh=Kf4Ll4c8mhE4biTxzWzbDnFe7g3OLyw6+A0DXEOC2Sw=;
b=b9C9AySsC+oqYMiBMkDf1BT/KVU5kOQZK1AqD/IzPl1x1BWkwIEGYgFma96vw0x1PQ
fpLbhwfuxXfYTPKl29yD4lUuo7gxuhvl9Eulxeu8yua8K91VjOQxKS86oscuwccyp6/x
b709HESp3JRkkjtBiGXiFL25T01HQtTD1IN+v+OlUlYzD8wWVyqkDetEkAIQ72BWYJsy
NHRFyNMF4WnI9byoeN6zbeJymSE5PSBBwF//KtDpaRNKYcYPDBJD+xTKuE4RlWzPQtVg
ca/8hXWgMIpgq8nHv4OzrvKMpJlRJmtHHN3WKHXKo24yMZFBXRo0psLQ4X+1aQJqRlr0
YTDw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1729407682; x=1730012482; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:from:to:cc:subject:date:message-id
:reply-to;
bh=Kf4Ll4c8mhE4biTxzWzbDnFe7g3OLyw6+A0DXEOC2Sw=;
b=IvVuy584dvGWL4arcHmYJG3G57mvawBV+BvJ+hl82Ns0i7Ygks/29TD1kRnjEJl49y
uGJvDDXfG5uv9KIMxpp48n6kTQlZ0EII440JxhT93VaUUZ/Mvq9E+b12JvHBfkL8a6K1
1w0SX3ijNISq+2BjdLIT5sVKWaDKS8xZRmo356zR4J6mDltj3wBivS8s6Nnv8RoR74Y0
XiSZBtyX/CoYnv03LzRCEPsaIybvP2SJzyhPapqoxFijwhFYsOAJZEZdHiDRI5pCHHzx
oTJ8EfQrgnz2T806+V/8wEtNmmyNjP7laBS/QAW3beDFlEbRGoItgZ0bhWvjDIkIxtfP
5yQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1729407682; x=1730012482;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:x-beenthere:x-gm-message-state
:sender:from:to:cc:subject:date:message-id:reply-to;
bh=Kf4Ll4c8mhE4biTxzWzbDnFe7g3OLyw6+A0DXEOC2Sw=;
b=OXzH8cwiX9b5JMaXQ1ZSBviqx9b0fQk7Vl4Lyqf5G3oy8sJCqi5UWz70+TrvOEWsgB
grVgV09lmYWg9MBThA2OINMe0wVuJbAxnJVuNpWcdkYjc1mGXOp90eu2wRvRvyRWgVJw
kfNIHiiAbKm8AaczdclIs5JjXXjmiB8+7x7d5IXL4KbOrQzI8TLiUcjTSSbMFQUMYwsg
VWDXUZJalNcEAe/imBIYW3Wc4jjeCuA2sGJGbYaNriugE221rjAUcLvEIm732brHuG40
Q9t6uKKGCRMccil0Q4KgUIeqHDQoLOEYFq/Rv+Dr2fy+unlNgWV+QtTPSBrwGuIYgj/N
CSCw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWEkIGF0sMuzClU2Pcrvp+mnYIHBMlR8fPLZrn5Ie9l62hXab0fseUHsVyHglMgfhnPk6NfADhhAYam@gnusha.org
X-Gm-Message-State: AOJu0YxtdKTxj+B5QslQk+PZuTDQl4TDLBH8p4QJ2BkAelwnyB1j4Hw1
boZ9tuFMrZjhklx43txY9N94gdMYcc/OXn9NY8L/x9CLtGVIZlvo
X-Google-Smtp-Source: AGHT+IGsmb4uPCRxHe/uXvY/QFMxVmnva3Dyb5Z61P3ItiqNk8f7dqPWGjlkAU9STURf1WuYxa7v9Q==
X-Received: by 2002:a05:6902:120d:b0:e2b:d9d7:9078 with SMTP id 3f1490d57ef6-e2bd9d79431mr1767692276.3.1729407681622;
Sun, 20 Oct 2024 00:01:21 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:726:b0:e20:db8:7862 with SMTP id
3f1490d57ef6-e2b9ce27e07ls4061751276.2.-pod-prod-02-us; Sun, 20 Oct 2024
00:01:19 -0700 (PDT)
X-Received: by 2002:a05:690c:2e0f:b0:6e3:1050:5a3b with SMTP id 00721157ae682-6e5bfa0baefmr58469117b3.25.1729407679805;
Sun, 20 Oct 2024 00:01:19 -0700 (PDT)
Received: by 2002:a05:690c:7249:b0:6e3:65a1:402f with SMTP id 00721157ae682-6e5bd5605d7ms7b3;
Sat, 19 Oct 2024 23:19:16 -0700 (PDT)
X-Received: by 2002:a05:690c:a85:b0:6e2:5d2:3421 with SMTP id 00721157ae682-6e5bfc2e6b0mr73271747b3.10.1729405156087;
Sat, 19 Oct 2024 23:19:16 -0700 (PDT)
Date: Sat, 19 Oct 2024 23:19:15 -0700 (PDT)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <b383aad2-1abc-4b82-9851-1750b1b52f12n@googlegroups.com>
Subject: [bitcoindev] Redefine packages to discourage address reuse
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_173010_1667570706.1729405155687"
X-Original-Sender: alicexbtong@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_173010_1667570706.1729405155687
Content-Type: multipart/alternative;
boundary="----=_Part_173011_202910925.1729405155687"
------=_Part_173011_202910925.1729405155687
Content-Type: text/plain; charset="UTF-8"
Hi Bitcoin Developers,
Address re-use is bad for privacy and such transactions affect everyone
involved. A mempool policy to reject such transactions will be useless,
however packages could be redefined to avoid address re-use in package
transactions.
BIP 331 defines packages as a list of unconfirmed transactions,
representable by a connected Directed Acyclic Graph (a directed edge exists
between a transaction that spends the output of another transaction). With
the new definition, transactions with address reuse cannot be a part of
package relayed by nodes with SENDPACKAGES P2P message.
The only downside that I could think of is the scanning time required to
check address reuse. Maybe others could suggest solutions for this problem
or we can limit the address reuse check only for the chain of transactions.
I am not sure if BIP author would agree with this change and a new BIP wont
make a difference if its not implemented in bitcoin core.
/dev/fd0
floppy disk guy
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/b383aad2-1abc-4b82-9851-1750b1b52f12n%40googlegroups.com.
------=_Part_173011_202910925.1729405155687
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Bitcoin Developers,<div><br /></div><div>Address re-use is bad for priva=
cy and such transactions affect everyone involved. A mempool policy to reje=
ct such transactions will be useless, however packages could be redefined t=
o avoid address re-use in package transactions.</div><div><br /></div><div>=
BIP 331 defines packages as a list of unconfirmed transactions, representab=
le by a connected Directed Acyclic Graph (a directed edge exists between a =
transaction that spends the output of another transaction). With the new de=
finition, transactions with address reuse cannot be a part of package relay=
ed by nodes with SENDPACKAGES P2P message.</div><div><br /></div><div>The o=
nly downside that I could think of is the scanning time required to check a=
ddress reuse. Maybe others could suggest solutions for this problem or we c=
an limit the address reuse check only for the chain of transactions.</div><=
div><br /></div><div>I am not sure if BIP author would agree with this chan=
ge and a new BIP wont make a difference if its not implemented in bitcoin c=
ore.</div><div><br /></div><div>/dev/fd0</div><div>floppy disk guy</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/b383aad2-1abc-4b82-9851-1750b1b52f12n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/b383aad2-1abc-4b82-9851-1750b1b52f12n%40googlegroups.com</a>.=
<br />
------=_Part_173011_202910925.1729405155687--
------=_Part_173010_1667570706.1729405155687--
|
