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:38:22 -0700 (PDT) [thread overview]
Message-ID: <6eac324c-27a3-457c-a9ea-a8e3c0d18887n@googlegroups.com> (raw)
In-Reply-To: <CAHR1cdW9nP3-HEXr-QMoHag7yGChZCtXEadMZON4PFJidqEMsQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3811 bytes --]
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
On Monday, October 21, 2024 at 9:09:35 PM UTC+5:30 Abubakar Ismail wrote:
> 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
>
> On Sun, Oct 20, 2024, 8:01 AM /dev /fd0 <alice...@gmail•com> 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.
>>
>> 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
>>
>> --
>> 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
>> <https://groups.google.com/d/msgid/bitcoindev/b383aad2-1abc-4b82-9851-1750b1b52f12n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/6eac324c-27a3-457c-a9ea-a8e3c0d18887n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7255 bytes --]
next 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 [this message]
2024-10-23 14:35 ` Peter Todd
2024-10-24 3:43 ` /dev /fd0
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=6eac324c-27a3-457c-a9ea-a8e3c0d18887n@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