Delivery-date: Thu, 24 Oct 2024 17:39:46 -0700
Sender: bitcoindev@googlegroups.com
Date: Wed, 23 Oct 2024 20:43:50 -0700 (PDT)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <d78f0253-b09a-4718-ba4f-805c1b25a036n@googlegroups.com>
In-Reply-To: <ZxkJyPVhk2uQLPOl@petertodd.org>
References: <b383aad2-1abc-4b82-9851-1750b1b52f12n@googlegroups.com>
 <ZxkJyPVhk2uQLPOl@petertodd.org>
Subject: Re: [bitcoindev] Redefine packages to discourage address reuse
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_148318_1548187740.1729741430899"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_148318_1548187740.1729741430899
Content-Type: multipart/alternative; 
	boundary="----=_Part_148319_857370969.1729741430899"

------=_Part_148319_857370969.1729741430899
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

> This kind of idea has been proposed multiple times and rejected.

This is the first time packages are used in bitcoin. My proposal is limited=
=20
to packages.

> In this particular case, an especially bad problem with it is there are
> probably L2 protocols that actually need to reuse addresses in certain
> circumstances.=20

Can you share an example?

Packages will be used with covenants, inscriptions etc. apart from L2=20
protocols and I think there would be lot of address-reuse which can be=20
prevented by redefining the packages early.

/dev/fd0
floppy disk guy

On Wednesday, October 23, 2024 at 8:47:41=E2=80=AFPM UTC+5:30 Peter Todd wr=
ote:

> On Sat, Oct 19, 2024 at 11:19:15PM -0700, /dev /fd0 wrote:
> > Hi Bitcoin Developers,
> >=20
> > Address re-use is bad for privacy and such transactions affect everyone=
=20
> > involved. A mempool policy to reject such transactions will be useless,=
=20
> > however packages could be redefined to avoid address re-use in package=
=20
> > transactions.
> >=20
> > BIP 331 defines packages as a list of unconfirmed transactions,=20
> > representable by a connected Directed Acyclic Graph (a directed edge=20
> exists=20
> > between a transaction that spends the output of another transaction).=
=20
> With=20
> > the new definition, transactions with address reuse cannot be a part of=
=20
> > package relayed by nodes with SENDPACKAGES P2P message.
>
> This kind of idea has been proposed multiple times and rejected.
>
> In this particular case, an especially bad problem with it is there are
> probably L2 protocols that actually need to reuse addresses in certain
> circumstances. There are likely to also be situations where an adversary
> can trigger unintentional address reuse, and thus get transactions
> pinned by this filter.
>
> For these reasons alone, NACK.
>
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
d78f0253-b09a-4718-ba4f-805c1b25a036n%40googlegroups.com.

------=_Part_148319_857370969.1729741430899
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,<div><br /></div><div>&gt;=C2=A0This kind of idea has been propose=
d multiple times and rejected.</div><div><br /></div><div>This is the first=
 time packages are used in bitcoin. My proposal is limited to packages.</di=
v><div><br /></div><div>&gt; In this particular case, an especially bad pro=
blem with it is there are<br />&gt; probably L2 protocols that actually nee=
d to reuse addresses in certain<br />&gt; circumstances.=C2=A0</div><div><b=
r /></div><div>Can you share an example?</div><div><br /></div><div>Package=
s will be used with covenants, inscriptions etc. apart from L2 protocols an=
d I think there would be lot of address-reuse which can be prevented by red=
efining the packages early.</div><div><br /></div><div>/dev/fd0</div><div>f=
loppy disk guy<br /><br /></div><div class=3D"gmail_quote"><div dir=3D"auto=
" class=3D"gmail_attr">On Wednesday, October 23, 2024 at 8:47:41=E2=80=AFPM=
 UTC+5:30 Peter Todd wrote:<br/></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddi=
ng-left: 1ex;">On Sat, Oct 19, 2024 at 11:19:15PM -0700, /dev /fd0 wrote:
<br>&gt; Hi Bitcoin Developers,
<br>&gt;=20
<br>&gt; Address re-use is bad for privacy and such transactions affect eve=
ryone=20
<br>&gt; involved. A mempool policy to reject such transactions will be use=
less,=20
<br>&gt; however packages could be redefined to avoid address re-use in pac=
kage=20
<br>&gt; transactions.
<br>&gt;=20
<br>&gt; BIP 331 defines packages as a list of unconfirmed transactions,=20
<br>&gt; representable by a connected Directed Acyclic Graph (a directed ed=
ge exists=20
<br>&gt; between a transaction that spends the output of another transactio=
n). With=20
<br>&gt; the new definition, transactions with address reuse cannot be a pa=
rt of=20
<br>&gt; package relayed by nodes with SENDPACKAGES P2P message.
<br>
<br>This kind of idea has been proposed multiple times and rejected.
<br>
<br>In this particular case, an especially bad problem with it is there are
<br>probably L2 protocols that actually need to reuse addresses in certain
<br>circumstances. There are likely to also be situations where an adversar=
y
<br>can trigger unintentional address reuse, and thus get transactions
<br>pinned by this filter.
<br>
<br>For these reasons alone, NACK.
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1729827504072000&amp;usg=3DAOvVaw1=
aHwYK06BBwcVjEUYSWs71">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a hr=
ef=3D"http://petertodd.org" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1729827504072000&amp;usg=3DAOvVaw2KZhWfJVPKQm=
HJsDdTLxu6">petertodd.org</a>
<br></blockquote></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 visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/d78f0253-b09a-4718-ba4f-805c1b25a036n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/d78f0253-b09a-4718-ba4f-805c1b25a036n%40googlegroups.com</a>.<br />

------=_Part_148319_857370969.1729741430899--

------=_Part_148318_1548187740.1729741430899--