From: /dev /fd0 <alicexbtong@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Redefine packages to discourage address reuse
Date: Wed, 23 Oct 2024 20:43:50 -0700 (PDT) [thread overview]
Message-ID: <d78f0253-b09a-4718-ba4f-805c1b25a036n@googlegroups.com> (raw)
In-Reply-To: <ZxkJyPVhk2uQLPOl@petertodd.org>
[-- Attachment #1.1: Type: text/plain, Size: 2288 bytes --]
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
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.
Can you share an example?
Packages will be used with covenants, inscriptions etc. apart from L2
protocols and I think there would be lot of address-reuse which can be
prevented by redefining the packages early.
/dev/fd0
floppy disk guy
On Wednesday, October 23, 2024 at 8:47:41 PM UTC+5:30 Peter Todd wrote:
> On Sat, Oct 19, 2024 at 11:19:15PM -0700, /dev /fd0 wrote:
> > 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
> exists
> > between a transaction that spends the output of another transaction).
> With
> > the new definition, transactions with address reuse cannot be a part of
> > 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.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
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 visit https://groups.google.com/d/msgid/bitcoindev/d78f0253-b09a-4718-ba4f-805c1b25a036n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3480 bytes --]
prev parent reply other threads:[~2024-10-25 0:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-20 6:19 /dev /fd0
2024-10-20 7:33 ` Abubakar Ismail
2024-10-24 3:38 ` /dev /fd0
2024-10-23 14:35 ` Peter Todd
2024-10-24 3:43 ` /dev /fd0 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d78f0253-b09a-4718-ba4f-805c1b25a036n@googlegroups.com \
--to=alicexbtong@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox