path: root/00/2d314380088a44e23d4dcab926c3c25703cddc

Delivery-date: Thu, 24 Oct 2024 17:39:46 -0700
Received: from mail-yb1-f183.google.com ([209.85.219.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBSOR5O4AMGQEG6UKK6Y@googlegroups.com>)
	id 1t48Mj-0004s1-Sz
	for bitcoindev@gnusha.org; Thu, 24 Oct 2024 17:39:46 -0700
Received: by mail-yb1-f183.google.com with SMTP id 3f1490d57ef6-e2904d0cad0sf3139019276.1
        for <bitcoindev@gnusha.org>; Thu, 24 Oct 2024 17:39:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1729816779; x=1730421579; 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=W9QMYW7CavAHmPnSRU6Z9zpQhXvR3d8PgfUilm22S2E=;
        b=vkudTZz1ynGg1h2frjZCeErw8t5HLahzURX6K83j7P7GQQDniyNFal5sX9YNOwZXJ/
         aMoYOLg+/TdhrIJt8mEERf00lWMm7qumyLZcpy2RVqHKEUayh7QfgGHMTaF2hsklphs3
         djwaB0uhym0lRMEga3ZMCYIRGfMWaOwdJNurWbNu3ZsIxhzkxGr/GEPQfuEa03VBvo3R
         RCv0LK1XV/80NlUsqlcI3qiM4+RM5QIYuCE5UEjK5u91FEIZw+9m3EA8GDcuP+P2OT+t
         vMoz/GCDKqabbLcgIM7jHFVBc4J7x+hCnDD/zI67FWuDVLXsiiRtUuRgIoMbGtvwS7DE
         UTsA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1729816779; x=1730421579; 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=W9QMYW7CavAHmPnSRU6Z9zpQhXvR3d8PgfUilm22S2E=;
        b=W2UsIg9owzQTYlryTmbzqQDzj10RND/BAuU585u99rj2FUBmdk+FaiwT+aP/Tq8h00
         dbmt1YykLvDS+PjlbKi+qsMpIqYrp1VsKJK6Zv79/CHQacDHLtA5AD/JD7FRvAD+pUF+
         6Zgydm4zMagQLBppDe2Zrlv+rkSe481IFXxLDeILDiCutOC1Q95C3rZDQKZxhchVvBke
         3XAGZVaSuTOfwkV+dkhm9kYPvsmtf1hbOLwiQ9lonIAXKIxHCivVWmPNIkUKbFKw8cZl
         /bXi0Snv4TsnJoryi+8/8jgRtAGYjj6Lzo8pWH4IiV0nRGQnb6fEEpVqdDVpFL0P3Wtb
         8Ydw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1729816779; x=1730421579;
        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=W9QMYW7CavAHmPnSRU6Z9zpQhXvR3d8PgfUilm22S2E=;
        b=WHjN0iRn/mhZVhu0ieO2mYu2pXHu9gRyO9kR/P8zk9r+nRtq3nUHnVg9ruE3+APiKz
         NO7UIjf8CfReXxWi7IvW22pwYKX6IeNtE2sQUGnR8yXl8VyaBwucU6uG5GhAZhXxqO7k
         Du2Z6+jzheCV8tU2lqNgPjaiufeiPQs8dMsAa+2rAOZkiwsP2jW0FTrRuPZlcIffFUki
         4flB1RIfloFRmss2pxxMCFSxedPxfZjc5Eu23OiSFYmyxsC6R4Y/Qk0md7K9WoNz9/LY
         SK5FbpwcVpKTAO0Z3HxpUqmonds1hA3gw2Ukz+v2JsmcKAOJ2F8QybQbtIf2gB6zigyy
         60rg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVD0fPw1BZbODROz+rX9K9yPmr+FAqsniR4Y+F6eAItYmsXGCAdmhDcu+bSPygfkY0ukaEnppdCCcyx@gnusha.org
X-Gm-Message-State: AOJu0YwU6+00AUARIxKmQiL0R2wXdirwabVNP3NnCEs+GwG7bpvDscQj
	yj2zRNlP+YIMVIGNehdPxljbDn8hvKfotIqhT08VbRzJwCtkZr5l
X-Google-Smtp-Source: AGHT+IEtGG4xYaVH6/I9DYTV0qJtOYsfSldw3ltTwB2tJZ2ElT2PxiHOpxQ8iXYZdryIXMCUCoZgYQ==
X-Received: by 2002:a05:6902:2b92:b0:e24:9b99:c01f with SMTP id 3f1490d57ef6-e2e3a512054mr8353123276.0.1729816779454;
        Thu, 24 Oct 2024 17:39:39 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:18d3:b0:e29:19d5:b575 with SMTP id
 3f1490d57ef6-e2e4a7647a2ls1049361276.1.-pod-prod-06-us; Thu, 24 Oct 2024
 17:39:37 -0700 (PDT)
X-Received: by 2002:a05:690c:38a:b0:6e2:313a:a01e with SMTP id 00721157ae682-6e7f0f53c1dmr100634057b3.32.1729816777535;
        Thu, 24 Oct 2024 17:39:37 -0700 (PDT)
Received: by 2002:a05:690c:640c:b0:6dd:f386:13dc with SMTP id 00721157ae682-6e7eefee158ms7b3;
        Wed, 23 Oct 2024 20:43:51 -0700 (PDT)
X-Received: by 2002:a05:690c:4c0a:b0:6e2:43ea:54e with SMTP id 00721157ae682-6e85818ad44mr8597357b3.21.1729741431129;
        Wed, 23 Oct 2024 20:43:51 -0700 (PDT)
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"
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_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--