Delivery-date: Mon, 21 Oct 2024 08:39:42 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of ask4ismailsadiq@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) client-ip=2a00:1450:4864:20::42a;
MIME-Version: 1.0
References: <b383aad2-1abc-4b82-9851-1750b1b52f12n@googlegroups.com>
In-Reply-To: <b383aad2-1abc-4b82-9851-1750b1b52f12n@googlegroups.com>
From: Abubakar Ismail <ask4ismailsadiq@gmail.com>
Date: Sun, 20 Oct 2024 08:33:16 +0100
Message-ID: <CAHR1cdW9nP3-HEXr-QMoHag7yGChZCtXEadMZON4PFJidqEMsQ@mail.gmail.com>
Subject: Re: [bitcoindev] Redefine packages to discourage address reuse
To: "/dev /fd0" <alicexbtong@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000004af0140624e38da5"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--0000000000004af0140624e38da5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Floppy

> however packages could be redefined to avoid address >re-use in package
transactions.

What type of redefinition are you talking about here, is this not policy
rule still.

I don't think it's good for a node to reject an incentive compatible
transaction in a package because it reuses an address. I believe miners
won't.

> 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.

Other disadvantage of this is that it will affect compact block
reconstruction, nodes fee estimation.


Wouldn't it be better to encourage using other safe mitigations of address
reuse like silent payments?

Abubakar

On Sun, Oct 20, 2024, 8:01=E2=80=AFAM /dev /fd0 <alicexbtong@gmail.com> wro=
te:

> 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 exis=
ts
> between a transaction that spends the output of another transaction). Wit=
h
> 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 proble=
m
> or we can limit the address reuse check only for the chain of transaction=
s.
>
> 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-1750=
b1b52f12n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/b383aad2-1abc-4b82-9851-175=
0b1b52f12n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=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 on the web visit https://groups.google.com/d/msgid/=
bitcoindev/CAHR1cdW9nP3-HEXr-QMoHag7yGChZCtXEadMZON4PFJidqEMsQ%40mail.gmail=
.com.

--0000000000004af0140624e38da5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><p dir=3D"ltr" style=3D"font-size:12.8px;line-height:1.38=
;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:16pt;font-famil=
y:&#39;google sans&#39;;color:rgb(0,0,0);vertical-align:baseline">Hi Floppy=
</span></p><div style=3D"color:rgb(80,0,80);font-size:12.8px" dir=3D"auto">=
<br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0=
pt"><span style=3D"font-size:16pt;font-family:&#39;google sans&#39;;color:r=
gb(0,0,0);vertical-align:baseline">&gt; however packages could be redefined=
 to avoid address &gt;re-use in package transactions.</span></p><br></div><=
p dir=3D"ltr" style=3D"font-size:12.8px;line-height:1.38;margin-top:0pt;mar=
gin-bottom:0pt"><span style=3D"font-size:16pt;font-family:&#39;google sans&=
#39;;color:rgb(0,0,0);vertical-align:baseline">What type of redefinition ar=
e you talking about here, is this not policy rule still.</span></p><p dir=
=3D"ltr" style=3D"font-size:12.8px;line-height:1.38;margin-top:0pt;margin-b=
ottom:0pt"><span style=3D"font-size:16pt;font-family:&#39;google sans&#39;;=
color:rgb(0,0,0);vertical-align:baseline">I don&#39;t think it&#39;s good f=
or a node to reject an incentive compatible transaction in a package becaus=
e it reuses an address. I believe miners won&#39;t.</span></p><div style=3D=
"color:rgb(80,0,80);font-size:12.8px" dir=3D"auto"><br><p dir=3D"ltr" style=
=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-=
size:16pt;font-family:&#39;google sans&#39;;color:rgb(0,0,0);vertical-align=
:baseline">&gt; The only downside that I could think of is the scanning tim=
e 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.</span></p><br></div><p dir=3D"ltr" style=3D"font-size:12.8px=
;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-siz=
e:16pt;font-family:&#39;google sans&#39;;color:rgb(0,0,0);vertical-align:ba=
seline">Other disadvantage of this is that it will affect compact block rec=
onstruction, nodes fee estimation.</span></p><br style=3D"font-size:12.8px"=
><br style=3D"font-size:12.8px"><p dir=3D"ltr" style=3D"font-size:12.8px;li=
ne-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:1=
6pt;font-family:&#39;google sans&#39;;color:rgb(0,0,0);vertical-align:basel=
ine">Wouldn&#39;t it be better to encourage using other safe mitigations of=
 address reuse like silent payments?</span></p><div style=3D"color:rgb(136,=
136,136);font-size:12.8px" dir=3D"auto"><br><p dir=3D"ltr" style=3D"line-he=
ight:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:16pt;f=
ont-family:&#39;google sans&#39;;color:rgb(0,0,0);vertical-align:baseline">=
Abubakar</span></p></div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Sun, Oct 20, 2024, 8:01=E2=80=AFAM /dev /fd0 &l=
t;<a href=3D"mailto:alicexbtong@gmail.com">alicexbtong@gmail.com</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">Hi Bitcoin Developers,<div><br=
></div><div>Address re-use is bad for privacy and such transactions affect =
everyone involved. A mempool policy to reject such transactions will be use=
less, however packages could be redefined to avoid address re-use in packag=
e transactions.</div><div><br></div><div>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 addres=
s reuse cannot be a part of package relayed by nodes with SENDPACKAGES P2P =
message.</div><div><br></div><div>The only downside that I could think of i=
s the scanning time required to check address reuse. Maybe others could sug=
gest solutions for this problem or we can limit the address reuse check onl=
y for the chain of transactions.</div><div><br></div><div>I am not sure if =
BIP author would agree with this change and a new BIP wont make a differenc=
e if its not implemented in bitcoin core.</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" target=
=3D"_blank" rel=3D"noreferrer">bitcoindev+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&amp;utm_source=3Dfooter" target=3D"_blank" rel=3D"no=
referrer">https://groups.google.com/d/msgid/bitcoindev/b383aad2-1abc-4b82-9=
851-1750b1b52f12n%40googlegroups.com</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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/CAHR1cdW9nP3-HEXr-QMoHag7yGChZCtXEadMZON4PFJidqEMsQ%4=
0mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/d/msgid/bitcoindev/CAHR1cdW9nP3-HEXr-QMoHag7yGChZCtXEadMZON4PFJidqEM=
sQ%40mail.gmail.com</a>.<br />

--0000000000004af0140624e38da5--