Delivery-date: Thu, 24 Oct 2024 17:39:44 -0700
Sender: bitcoindev@googlegroups.com
Date: Wed, 23 Oct 2024 20:38:22 -0700 (PDT)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <6eac324c-27a3-457c-a9ea-a8e3c0d18887n@googlegroups.com>
In-Reply-To: <CAHR1cdW9nP3-HEXr-QMoHag7yGChZCtXEadMZON4PFJidqEMsQ@mail.gmail.com>
References: <b383aad2-1abc-4b82-9851-1750b1b52f12n@googlegroups.com>
 <CAHR1cdW9nP3-HEXr-QMoHag7yGChZCtXEadMZON4PFJidqEMsQ@mail.gmail.com>
Subject: Re: [bitcoindev] Redefine packages to discourage address reuse
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_138582_77821467.1729741102324"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_138582_77821467.1729741102324
Content-Type: multipart/alternative; 
	boundary="----=_Part_138583_768529727.1729741102324"

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

Hi Abubakar,

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

The transactions are not rejected. They will continue to work as they did=
=20
before packages existed. It is incentive compatible and does not reduce=20
miner revenue.

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

It wont.

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

Silent payments are used for reusable payment codes that help in creating=
=20
multiple addresses. Its not a protocol change that discourages address=20
reuse on-chain.=20

/dev/fd0
floppy disk guy


On Monday, October 21, 2024 at 9:09:35=E2=80=AFPM UTC+5:30 Abubakar Ismail =
wrote:

> Hi Floppy
>
> > however packages could be redefined to avoid address >re-use in package=
=20
> transactions.
>
> What type of redefinition are you talking about here, is this not policy=
=20
> rule still.
>
> I don't think it's good for a node to reject an incentive compatible=20
> transaction in a package because it reuses an address. I believe miners=
=20
> won't.
>
> > The only downside that I could think of is the scanning time required t=
o=20
> check address reuse. Maybe others could suggest solutions for this proble=
m=20
> or we can limit the address reuse check only for the chain of transaction=
s.
>
> Other disadvantage of this is that it will affect compact block=20
> reconstruction, nodes fee estimation.
>
>
> Wouldn't it be better to encourage using other safe mitigations of addres=
s=20
> reuse like silent payments?
>
> Abubakar
>
> On Sun, Oct 20, 2024, 8:01=E2=80=AFAM /dev /fd0 <alice...@gmail.com> wrot=
e:
>
>> Hi Bitcoin Developers,
>>
>> 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.
>>
>> BIP 331 defines packages as a list of unconfirmed transactions,=20
>> representable by a connected Directed Acyclic Graph (a directed edge exi=
sts=20
>> between a transaction that spends the output of another transaction). Wi=
th=20
>> the new definition, transactions with address reuse cannot be a part of=
=20
>> package relayed by nodes with SENDPACKAGES P2P message.
>>
>> The only downside that I could think of is the scanning time required to=
=20
>> check address reuse. Maybe others could suggest solutions for this probl=
em=20
>> or we can limit the address reuse check only for the chain of transactio=
ns.
>>
>> I am not sure if BIP author would agree with this change and a new BIP=
=20
>> wont make a difference if its not implemented in bitcoin core.
>>
>> /dev/fd0
>> floppy disk guy
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to bitcoindev+...@googlegroups.com.
>> To view this discussion on the web visit=20
>> https://groups.google.com/d/msgid/bitcoindev/b383aad2-1abc-4b82-9851-175=
0b1b52f12n%40googlegroups.com=20
>> <https://groups.google.com/d/msgid/bitcoindev/b383aad2-1abc-4b82-9851-17=
50b1b52f12n%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 visit https://groups.google.com/d/msgid/bitcoindev/=
6eac324c-27a3-457c-a9ea-a8e3c0d18887n%40googlegroups.com.

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

Hi Abubakar,<div><br /></div><div>&gt;=C2=A0I don't think it's good for a n=
ode to reject an incentive compatible transaction in a package because it r=
euses an address. I believe miners won't.</div><div><br /></div><div>The tr=
ansactions are not rejected. They will continue to work as they did before =
packages existed. It is incentive compatible and does not reduce miner reve=
nue.</div><div><br /></div><div>&gt;=C2=A0Other disadvantage of this is tha=
t it will affect compact block reconstruction, nodes fee estimation.</div><=
div><br /></div><div>It wont.</div><div><br /></div><div>&gt;=C2=A0Wouldn't=
 it be better to encourage using other safe mitigations of address reuse li=
ke silent payments?</div><div><br /></div><div>Silent payments are used for=
 reusable payment codes that help in creating multiple addresses. Its not a=
 protocol change that discourages address reuse on-chain.=C2=A0</div><div><=
br /></div><div>/dev/fd0</div><div>floppy disk guy</div><div><br /></div><d=
iv><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_=
attr">On Monday, October 21, 2024 at 9:09:35=E2=80=AFPM UTC+5:30 Abubakar I=
smail wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
<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><div dir=3D"auto"><div style=3D"color:rgb(80,0,80);font-si=
ze: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; however pac=
kages could be redefined to avoid address &gt;re-use in package transaction=
s.</span></p><br></div></div><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-family:&#39;google sans&#39;;color:rgb(0,0,0);verti=
cal-align:baseline">What type of redefinition are you talking about here, i=
s this not policy rule still.</span></p><p dir=3D"ltr" style=3D"font-size:1=
2.8px;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"fon=
t-size:16pt;font-family:&#39;google sans&#39;;color:rgb(0,0,0);vertical-ali=
gn:baseline">I don&#39;t think it&#39;s good for a node to reject an incent=
ive compatible transaction in a package because it reuses an address. I bel=
ieve miners won&#39;t.</span></p></div><div dir=3D"auto"><div style=3D"colo=
r:rgb(80,0,80);font-size:12.8px" dir=3D"auto"><br><p dir=3D"ltr" style=3D"l=
ine-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:base=
line">&gt; The only downside that I could think of is the scanning time req=
uired 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 tran=
sactions.</span></p><br></div></div><div dir=3D"auto"><p dir=3D"ltr" style=
=3D"font-size:12.8px;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><sp=
an style=3D"font-size:16pt;font-family:&#39;google sans&#39;;color:rgb(0,0,=
0);vertical-align:baseline">Other disadvantage of this is that it will affe=
ct compact block reconstruction, 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;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><sp=
an style=3D"font-size:16pt;font-family:&#39;google sans&#39;;color:rgb(0,0,=
0);vertical-align:baseline">Wouldn&#39;t it be better to encourage using ot=
her 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-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">Abubakar</span></p></div></div><br><div class=3D"g=
mail_quote"></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Sun, Oct 20, 2024, 8:01=E2=80=AFAM /dev /fd0 &lt;<a href data-em=
ail-masked rel=3D"nofollow">alice...@gmail.com</a>&gt; wrote:<br></div></di=
v><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bitcoin Deve=
lopers,<div><br></div><div>Address re-use is bad for privacy and such trans=
actions affect everyone involved. A mempool policy to reject such transacti=
ons will be useless, however packages could be redefined to avoid address r=
e-use in package transactions.</div><div><br></div><div>BIP 331 defines pac=
kages as a list of unconfirmed transactions, representable by a connected D=
irected Acyclic Graph (a directed edge exists between a transaction that sp=
ends the output of another transaction). With the new definition, transacti=
ons with address reuse cannot be a part of package relayed by nodes with SE=
NDPACKAGES P2P message.</div><div><br></div><div>The only downside that I c=
ould think of is the scanning time required to check address reuse. Maybe o=
thers could suggest solutions for this problem or we can 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 change and a new BIP wont m=
ake a difference if its not implemented in bitcoin core.</div><div><br></di=
v><div>/dev/fd0</div><div>floppy disk guy</div>

<p></p></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">

-- <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 rel=3D"noreferrer nofollow" data-email-masked>bitcoindev+..=
.@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" rel=3D"noreferrer nofollow"=
 target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3D=
en&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/b383aad2-1abc-4b82-=
9851-1750b1b52f12n%2540googlegroups.com?utm_medium%3Demail%26utm_source%3Df=
ooter&amp;source=3Dgmail&amp;ust=3D1729827070911000&amp;usg=3DAOvVaw2B6WTq9=
K0CWOZNNESWRjzb">https://groups.google.com/d/msgid/bitcoindev/b383aad2-1abc=
-4b82-9851-1750b1b52f12n%40googlegroups.com</a>.<br>
</blockquote></div>
</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/6eac324c-27a3-457c-a9ea-a8e3c0d18887n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/6eac324c-27a3-457c-a9ea-a8e3c0d18887n%40googlegroups.com</a>.<br />

------=_Part_138583_768529727.1729741102324--

------=_Part_138582_77821467.1729741102324--