Redefine packages to discourage address reuse

212 views
Skip to first unread message

/dev /fd0

unread,
Oct 20, 2024, 3:01:21 AM (11 days ago) Oct 20
to Bitcoin Development Mailing List
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.

The only downside that I could think of is the scanning time required 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 transactions.

I am not sure if BIP author would agree with this change and a new BIP wont make a difference if its not implemented in bitcoin core.

/dev/fd0
floppy disk guy

Abubakar Ismail

unread,
Oct 21, 2024, 11:39:35 AM (10 days ago) Oct 21
to /dev /fd0, Bitcoin Development Mailing List

Hi Floppy


> however packages could be redefined to avoid address >re-use in package transactions.


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

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


> The only downside that I could think of is the scanning time required 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 transactions.


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



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


Abubakar


--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/b383aad2-1abc-4b82-9851-1750b1b52f12n%40googlegroups.com.

Peter Todd

unread,
Oct 23, 2024, 11:17:41 AM (8 days ago) Oct 23
to /dev /fd0, Bitcoin Development Mailing List
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
signature.asc

/dev /fd0

unread,
Oct 24, 2024, 8:39:36 PM (6 days ago) Oct 24
to Bitcoin Development Mailing List
Hi Abubakar,

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

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

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

It wont.

> Wouldn't it be better to encourage using other safe mitigations of address reuse like 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. 

/dev/fd0
floppy disk guy

/dev /fd0

unread,
Oct 24, 2024, 8:39:39 PM (6 days ago) Oct 24
to Bitcoin Development Mailing List
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

Peter Todd

unread,
Oct 29, 2024, 12:52:27 PM (2 days ago) Oct 29
to /dev /fd0, Bitcoin Development Mailing List
On Wed, Oct 23, 2024 at 08:43:50PM -0700, /dev /fd0 wrote:
> 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?

For example in Lightning you can do closes to arbitrary addresses. An
adversary could pick an address that they know you will use in a package
to cause package propagation to fail, effectively resulting in a form of
transaction pinning.

There's no reason to add this complexity for essentially zero gain.

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

Packages tell chainalysis services that the transactions are related and
probably created by the same person anyway. Avoiding address reuse in
them doesn't improve privacy meaningfully.
signature.asc
Reply all
Reply to author
Forward
0 new messages