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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <6eac324c-27a3-457c-a9ea-a8e3c0d18887n@googlegroups.com> In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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 >> >> . >> > --=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,

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

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.

>=C2=A0Other disadvantage of this is tha= t it will affect compact block reconstruction, nodes fee estimation.
<= div>
It wont.

>=C2=A0Wouldn't= it be better to encourage using other safe mitigations of address reuse li= ke silent payments?

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
<= br />
/dev/fd0
floppy disk guy


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

Hi Floppy=


> however pac= kages could be redefined to avoid address >re-use in package transaction= s.


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

I don't think it'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't.


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


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



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


Abubakar


On Sun, Oct 20, 2024, 8:01=E2=80=AFAM /dev /fd0 <alice...@gmail.com> wrote:
Hi Bitcoin Deve= lopers,

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.

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.

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.

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.

/dev/fd0
floppy disk guy

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+..= .@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/b383aad2-1abc= -4b82-9851-1750b1b52f12n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/6eac324c-27a3-457c-a9ea-a8e3c0d18887n%40googlegroups.com.
------=_Part_138583_768529727.1729741102324-- ------=_Part_138582_77821467.1729741102324--