Delivery-date: Sun, 20 Oct 2024 00:01:29 -0700
Sender: bitcoindev@googlegroups.com
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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&quot; 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--