From: "aymeric@peersm.com" <aymeric@peersm.com>
To: <leohaf@orangepill.ovh>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [SPAM] Concern about "Inscriptions".
Date: Thu, 27 Jul 2023 12:41:06 +0200 [thread overview]
Message-ID: <55D64031-B210-4971-B353-E31A68268A58@peersm.com> (raw)
In-Reply-To: <A2F4432A-FFFA-4CAF-97A2-59EF4FFBD674@orangepill.ovh>
[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]
See #28130 on bitcoin repo
Of course the intent is not to store "inscriptions" but a reference
Whatever you do bitcoin cannot avoid deviant practices
Therefore that one is the right way to go
Envoyé de mon iPhone
> Le 25 juil. 2023 à 23:19, Léo via bitcoin-dev <bitcoin-dev@lists.linuxfoun@lists.linuxfoundation.org> a écrit :
>
>
> Hello,
>
> I am writing to you today because I am concerned about a significant bug that seems to be overlooked in recent versions of the software. The bug in question concerns the "inscriptions" developed by @rodarmor, and it worries me because, in just a few months, they have already reached a size of 11.8GB on the blockchain, causing issues with the UTXO set, which appears to be growing by about 25MB per day.
>
> I understand that there may be discussions about the nature of these inscriptions, but personally, I find it hard not to consider them as spam. Their recurring nature and their impact on the size of the UTXO set and the blockchain itself seem concerning, and I would like to understand why this problem has not been addressed more seriously.
>
> I would also like to point out that there are options in Bitcoin Core to choose the mempool policy, such as datacarrier or permitbaremultisig. However, when it comes to inscriptions, there are no available options except for a patch produced by Luke Dashjr. Unfortunately, this patch is unusable for most people as it requires compiling Bitcoin Core.
>
> So, I wonder why there are no options to reject inscriptions in the mempool of a node. Such a feature could give users the ability to customize their approach in managing these particular cases and help mitigate the negative impact of inscriptions on the network.
>
> In addition to the technical issues, I also find that this situation raises ethical questions. Inscriptions are primarily used to sell NFTs or Tokens, concepts that the Bitcoin community has consistently rejected.
>
> Therefore, I kindly request you, as Bitcoin developers, to take this concern into consideration and seriously consider implementing a feature that would allow users to reject inscriptions in the mempool. Such a measure would contribute to protecting the integrity of the network.
>
> Thank you sincerely for your attention to this matter.
>
> Léo.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 11552 bytes --]
prev parent reply other threads:[~2023-07-27 13:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 14:11 [bitcoin-dev] Concern about "Inscriptions" leohaf
2023-07-27 10:41 ` aymeric [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=55D64031-B210-4971-B353-E31A68268A58@peersm.com \
--to=aymeric@peersm.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=leohaf@orangepill.ovh \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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