path: root/10/c37eb051f8117e3cc7283b2280d3ab0c2129ca

Delivery-date: Thu, 24 Oct 2024 17:39:44 -0700
Received: from mail-yb1-f186.google.com ([209.85.219.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBRWR5O4AMGQES6UR5MA@googlegroups.com>)
	id 1t48Mh-0004rz-CI
	for bitcoindev@gnusha.org; Thu, 24 Oct 2024 17:39:43 -0700
Received: by mail-yb1-f186.google.com with SMTP id 3f1490d57ef6-e292d801e59sf2671677276.0
        for <bitcoindev@gnusha.org>; Thu, 24 Oct 2024 17:39:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1729816776; x=1730421576; 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:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=fWeqIbX9d9GVA+e0y6ZtD+xeFhJTZic+ILvqVyZoDOE=;
        b=vUrxXh/hgTUDMZ/j+FbYH1mIU0AHqjV7zkQcs30j2nsQLWlHLNaFV3Hgzb5q2rjiDT
         y+G+AlvSyZccWDNPK9E47qrlRi4025xFSzhtU5K3bXBfoU+LHZB2d1NYHcOP/AlvjzIx
         7pCshZyyw3zLzIn42tnZkmi9Pm3e4aEqJXGSpq6Ox/wTeZBhf8hndUA5uyQpz7FSO3nD
         ytCY02ATN7UcPX6fWw1bcAS2k0Oui1Iep+/vL7+tIlv6C9+ARR/R3Z3yyqk8APB0K9c6
         D/UacEI/vWKAxv/p7MCpUI7e83f7WDGGH03NhZv6Ig25fk65UKj/qKJS4aUxTuOkjoZj
         S9Cw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1729816776; x=1730421576; 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:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fWeqIbX9d9GVA+e0y6ZtD+xeFhJTZic+ILvqVyZoDOE=;
        b=YhDgK1UGUYMjh2bUQYQgOuTCz80D8Xgw/ea2nJJVDipFiuyouibCIZZ5GLpYT/fboR
         +bpZZHfQ8jdfov7SQb9JEPV4EmSs0krkcdPemnwBeKCjCHh2i6BjIt7CgGgqjidy2HYQ
         UJ8fhiTot+UYWaP8nH7dnexPNOncEBvwgRmkEANg/jwmHRrmklDdjOeiYMVzwsOVvyDr
         Sj/6nArw5V/HAnfvQEopK2kOyUt2SFxBdHdT4ico3z3RBoCxoBxXJMcbBOBALQO6j2U3
         jxbJGe9b6NfGfA/FmJ45n4c1lR4QYFK0PH+iBxQBfSjj0QvCTBf/C193kCwZoWhdEEww
         g0FQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1729816776; x=1730421576;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=fWeqIbX9d9GVA+e0y6ZtD+xeFhJTZic+ILvqVyZoDOE=;
        b=wkVRw3MnbK9vtXxEsyR/5fp0Vg6kbZbqtqFpXHsvkjVc8QnUHyeYYooC4olB6sJ41y
         zoRNscx7QsfEQiHlA7DQ4t1SSuMuEj8/9zcBHLxnpLI66TVbCTgJ1erBeZeIlNZYRNmW
         6lcyJnN+yPICMW63G/dY0ISGQliKK5eauK1yqddkIfvLfwtC9YQco4ZoNErYdG6z4CVF
         KG4cIofR1iHZcYEki7Z6Wl7Ex+QBVnPWbxj07LwDlvYhVa5pzDhqQ7lwxYxeO+b1lST7
         BuJBoBWs27yHqfu2qyAFBBDtUAU75jRjKge3cS31cKmg68HEgzxdPNbI26EL3+FJYfyl
         d1fg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXj0/80YUadLhpTZnSQML4njnTUEIxl3mAx8YoGcHd0Y+2McO4/6/9tgmfpSKR80qmZRLemJpc+gU+1@gnusha.org
X-Gm-Message-State: AOJu0YysKQPFLXAhj+n6N38zOkw1Uu8Un7guNkwJ/w2MZeNtPUhKmZOH
	z9v78L4aYkwp72K66+BgKXwPuQvMp6JKDMh+iDVVIV9wmYkLhIMJ
X-Google-Smtp-Source: AGHT+IH8MD7lWS6bOiyYSHNhmsasDNie5XEmR9QgLp0Fg8vNqAlYQSJwu3MAFR0GHHbZYwIX50SFOQ==
X-Received: by 2002:a05:6902:1005:b0:e28:6ebe:949 with SMTP id 3f1490d57ef6-e2e3a61fd30mr8821345276.20.1729816776481;
        Thu, 24 Oct 2024 17:39:36 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:188c:b0:e1c:eeec:3175 with SMTP id
 3f1490d57ef6-e2e4a77e8fbls1221990276.1.-pod-prod-02-us; Thu, 24 Oct 2024
 17:39:34 -0700 (PDT)
X-Received: by 2002:a05:690c:4513:b0:6dd:ba9b:2ca7 with SMTP id 00721157ae682-6e7f0ffbd92mr79584927b3.46.1729816774199;
        Thu, 24 Oct 2024 17:39:34 -0700 (PDT)
Received: by 2002:a81:fb01:0:b0:6dd:c9c1:7a16 with SMTP id 00721157ae682-6e7eed5a03cms7b3;
        Wed, 23 Oct 2024 20:38:24 -0700 (PDT)
X-Received: by 2002:a05:690c:490b:b0:6e7:e22b:fb80 with SMTP id 00721157ae682-6e85817f257mr7964677b3.19.1729741102828;
        Wed, 23 Oct 2024 20:38:22 -0700 (PDT)
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"
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_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--