Return-Path: <luke@dashjr.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 48BB6C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Aug 2023 15:52:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 22386414DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Aug 2023 15:52:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 22386414DB
Authentication-Results: smtp2.osuosl.org;
dkim=pass (1024-bit key) header.d=dashjr.org header.i=@dashjr.org
header.a=rsa-sha256 header.s=zinan header.b=IZIVGTh7
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
NICE_REPLY_A=-0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_MED=-2.3,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id NeegtFWqMQdm
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Aug 2023 15:52:35 +0000 (UTC)
X-Greylist: delayed 366 seconds by postgrey-1.37 at util1.osuosl.org;
Wed, 02 Aug 2023 15:52:35 UTC
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0B13B41486
Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1])
by smtp2.osuosl.org (Postfix) with ESMTP id 0B13B41486
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Aug 2023 15:52:34 +0000 (UTC)
Received: from [192.168.86.103] (99-39-46-195.lightspeed.dybhfl.sbcglobal.net
[99.39.46.195]) (Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 5E0C838AF85E;
Wed, 2 Aug 2023 15:46:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1690991188; bh=T65yjGbM/xham84PQXTOrWb+Uzigt+9b86Q2nmw6/z8=;
h=Date:Subject:To:References:From:In-Reply-To;
b=IZIVGTh7Thyvte0GQbDrg4A7Bh+TtviMnr9+x5rnenoH7SNhJK8rIVTToCRfsSWPQ
BnH9Zo48DhCQrnsyZEqzv15SV8uM73n/wJxRDT0w0ISYtz96wOG+zPbJDPI+hG+Wcm
P0ehTPyeh50d8vOCDSpLGm4NiG3jcXjlQGsV0kII=
X-Hashcash: 1:23:230802:gamedevalice256@gmail.com::/zi6XONsmVwH1dXB:h8k3
X-Hashcash: 1:23:230802:bitcoin-dev@lists.linuxfoundation.org::r4AHh2J1ELu4/dBs:Lf9
Content-Type: multipart/alternative;
boundary="------------fFJ3YYfZ7M293LhHboQBn10Y"
Message-ID: <f0c26b59-f75a-8831-fa9e-51ef4a129d67@dashjr.org>
Date: Wed, 2 Aug 2023 11:46:21 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.13.0
To: GamedevAlice <gamedevalice256@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAJCwDN-CFyyJhyp_5YTMtSNTN41zp5uJ1qa8vdmVqC2YCW8A6Q@mail.gmail.com>
Content-Language: en-US, en-GB
From: Luke Dashjr <luke@dashjr.org>
In-Reply-To: <CAJCwDN-CFyyJhyp_5YTMtSNTN41zp5uJ1qa8vdmVqC2YCW8A6Q@mail.gmail.com>
X-Mailman-Approved-At: Thu, 03 Aug 2023 14:11:54 +0000
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2023 15:52:39 -0000
This is a multi-part message in MIME format.
--------------fFJ3YYfZ7M293LhHboQBn10Y
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Storage is not and never has been the trouble with block sizes. Please,
before participating in discussions of this topic, at least get a basic
understanding of it. Here's a talk I did a few years ago to get you
started: https://www.youtube.com/watch?v=CqNEQS80-h4&t=7s
Luke
On 8/2/23 07:07, GamedevAlice via bitcoin-dev wrote:
> > If the rate of growth of the blockchain is too high, Ordinals aren't the
> > cause, it's rather that the theoretical limit of the amount of
> storage that
> > can be added per block isn't sufficiently limited. (Whether they are
> used
> > to produce Ordinals or something else)
>
>
> True, the real question is whether the storage is in fact sufficiently
> limited. And I believe the answer to be 'yes'.
>
> Why? Consider a worst case scenario using the maximum block size of
> 4MB and a block time of 10min, that's a growth of 210.24GB per year.
> Some of that can be pruned, but let's just assume that you don't want
> to. And currently the entire blockchain is roughly 500GB.
>
> Now that looks like a lot of growth potential based on where we are at
> now. However, with the current cost of hardware, you can get a 5 TB
> hard drive for less than $150. That will last you 21 years before you
> run out of space. That's less than $0.02 per day.
>
> That is a worst case scenario.
>
> Consider that since cost of hardware drops over time, it will become
> less of a burden over time.
>
> Also, keep in mind there are efforts to optimize how much of that
> actually needs to be stored by nodes. For example, the aforementioned
> topic announcing Floresta which seems to be a node implementation that
> uses utreexo to allow nodes to run without needing to maintain the
> full UTXO set. Other initiatives exist as well.
>
> There is definitely a lot of optimization potential for drastically
> reducing how much space is actually needed by individual nodes.
>
>
>
> On Wed, Aug 2, 2023, 5:40 AM ,
> <bitcoin-dev-request@lists.linuxfoundation.org> wrote:
>
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Pull-req to enable Full-RBF by default (Peter Todd)
> 2. Re: Concern about "Inscriptions". (ashneverdawn)
> (Keagan McClelland)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 2 Aug 2023 01:28:06 +0000
> From: Peter Todd <pete@petertodd.org>
> To: Daniel Lipshitz <daniel@gap600.com>
> Cc: Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default
> Message-ID: <ZMmxJoL1ZH4//8Fg@petertodd.org>
> Content-Type: text/plain; charset="us-ascii"
>
> On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:
> > Your research is not thorough and reaches an incorrect conclusion.
> >
> > As stated many times - we service payment processors and some
> merchants
> > directly - Coinspaid services multiple merchants and process a
> > significant amount of BTC they are a well known and active in
> the space -
> > as I provided back in December 2022 a email from Max the CEO of
> Coinspaid
> > confirming their use of 0-conf as well as providing there
> cluster addresses
> > to validate there deposit flows see here again -
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
> > - if this is not sufficient then please email
> support@coinspaid.com and ask
> > to be connected to Max or someone from the team who can confirm
> Conspaid is
> > clients of GAP600. Max also at the time was open to do a call, I
> can check
> > again now and see if this is still the case and connect you.
> >
> > That on its own is enough of a sample to validate our statistics.
>
> Why don't you just give me an example of some merchants using
> Coinspaid, and
> another example using Coinpayments, who rely on unconfirmed
> transactions? If
> those merchants actually exist it should be very easy to give me
> some names of
> them.
>
> Without actual concrete examples for everyone to see for
> themselves, why should
> we believe you?
>
> > I have also spoken to Changelly earlier today and they offered
> to email pro
> > @ changelly.com <http://changelly.com> and they will be able to
> confirm GAP600 as a service
>
> Emailed; waiting on a reply.
>
> > provider. Also please send me the 1 trx hash you tested and I
> can see if it
> > was queried to our system and if so offer some info as to why it
> wasnt
> > approved. Also if you can elaborate how you integrated with
> Changelly - I
> > can check with them if that area is not integrated with GAP600.
>
> Why don't you just tell me exactly what service Changelly offers
> that relies on
> unconfirmed transactions, and what characteristics would meet
> GAP600's risk
> criteria? I and others on this mailing list could easily do test
> transactions
> if you told us what we can actually test. If your service actually
> works, then
> you can safely provide that information.
>
> I'm not going to give you any exact tx hashes of transactions I've
> already
> done, as I don't want to cause any problems for the owners of the
> accounts I
> borrowed for testing. Given your lack of honesty so far I have
> every reason to
> believe they might be retalliated against in some way.
>
> > As the architect of such a major change to the status of 0-conf
> > transactions I would think you would welcome the opportunity to
> speak to
> > business and users who actual activities will be impacted by
> full RBF
> > becoming dominant.
>
> Funny how you say this, without actually giving any concrete
> examples of
> businesses that will be affected. Who exactly are these
> businesses? Payment
> processors obviously don't count.
>
> > Are you able to provide the same i.e emails and contacts of
> people at
> > the mining pools who can confirm they have adopted FULL RBF ?
>
> I've already had multiple mining pools complain to me that they
> and their
> employees have been harassed over full-rbf, so obviously I'm not
> going to
> provide you with any private contact information I have. There's
> no need to
> expose them to further harassment.
>
> If you actually offered an unconfirmed transaction guarantee
> service, with real
> customers getting an actual benefit, you'd be doing test transactions
> frequently and would already have a very good idea of what pools
> do full-rbf.
> Why don't you already have this data?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> <http://petertodd.org>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL:
> <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/7f826021/attachment-0001.sig>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 1 Aug 2023 22:58:53 -0700
> From: Keagan McClelland <keagan.mcclelland@gmail.com>
> To: Hugo L <ashneverdawn@gmail.com>, Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
> (ashneverdawn)
> Message-ID:
>
> <CALeFGL2Z3q90Esnu0qV0mqpHZaCnOV-5aks2TKGOjY4L+14d3w@mail.gmail.com
> <mailto:CALeFGL2Z3q90Esnu0qV0mqpHZaCnOV-5aks2TKGOjY4L%2B14d3w@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> There is an open question as to whether or not we should figure
> out a way
> to price space in the UTXO set. I think it is fair to say that
> given the
> fact that the UTXO set space remains unpriced that we actually
> have no way
> to determine whether some of these transactions are spam or not.
> The UTXO
> set must be maintained by all nodes including pruned nodes,
> whereas main
> block and witness data do not have the same type of indefinite
> footprint,
> so in some sense it is an even more significant resource than
> chain space.
> We may very well discover that if we price UTXOs in a way that
> reflect the
> resource costs that usage of inscriptions would vanish. The
> trouble though
> is that such a mechanism would imply having to pay "rent" for an
> "account"
> with Bitcoin, a proposition that would likely be offensive to a
> significant
> portion of the Bitcoin user base.
>
> Cheers,
> Keags
>
> On Mon, Jul 31, 2023 at 4:55?AM Hugo L via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > I don't think it's anyone's place to judge which types of
> transactions
> > should be allowed or not on the network, in fact, when it comes
> to privacy
> > and censorship resistance, it would be better if we were not
> even able to
> > distinguish different types of transactions from one another in
> the first
> > place.
> >
> > We have limited resources on the blockchain and so they should
> go to the
> > highest bidder. This is already how the network functions and how it
> > ensures it's security.
> >
> > Rather than thinking about this as "spam", I think it's useful to
> > objectively think about it in terms of value to the marketplace
> (fees
> > they're willing to pay) against cost to the network (storage
> consumed). It
> > comes down to supply and demand.
> >
> > If the rate of growth of the blockchain is too high, Ordinals
> aren't the
> > cause, it's rather that the theoretical limit of the amount of
> storage that
> > can be added per block isn't sufficiently limited. (Whether they
> are used
> > to produce Ordinals or something else)
> >
> >
> >
> > On Sun, Jul 30, 2023, 5:51 PM , <
> > bitcoin-dev-request@lists.linuxfoundation.org> wrote:
> >
> >> Send bitcoin-dev mailing list submissions to
> >> bitcoin-dev@lists.linuxfoundation.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> or, via email, send a message with subject or body 'help' to
> >> bitcoin-dev-request@lists.linuxfoundation.org
> >>
> >> You can reach the person managing the list at
> >> bitcoin-dev-owner@lists.linuxfoundation.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of bitcoin-dev digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >> 1. Re: Concern about "Inscriptions". (rot13maxi)
> >>
> >>
> >>
> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Sun, 30 Jul 2023 18:34:12 +0000
> >> From: rot13maxi <rot13maxi@protonmail.com>
> >> To: L?o Haf <leohaf@orangepill.ovh>, "vjudeu@gazeta.pl"
> >> <vjudeu@gazeta.pl>
> >> Cc: Bitcoin Protocol Discussion
> >> <bitcoin-dev@lists.linuxfoundation.org>
> >> Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
> >> Message-ID:
> >>
> >>
> <RIqguuebFmAhEDqCY_0T8KRqHBXEfcvPw6-MbDIyWsAWpLenFFeOVx88-068QFZr7xowg-6Zg988HsRCKdswtZC6QUKPXnrTyTAc_l5jphg=@
> >> protonmail.com <http://protonmail.com>>
> >>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> Hello,
> >>
> >> > This cat and mouse game can be won by bitcoin defenders. Why
> ? Because
> >> it is easier to detect these transactions and make them a
> standardization
> >> rule than to create new types of spam transactions.
> >>
> >> One of the things discussed during the mempoolfullrbf
> discussion is that
> >> a small (~10%) of nodes willing to relay a class of transaction
> is enough
> >> for that class of transaction to consistently reach miners.
> That means you
> >> would need to get nearly the entire network to run updated
> relay policy to
> >> prevent inscriptions from trivially reaching miners and being
> included in
> >> blocks. Inscription users have shown that they are willing and
> able to send
> >> non-standard transactions to miners out of band (
> >>
> https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae),
> >> so even if you managed to get enough of the network running the
> new rule to
> >> prevent propagation to miners, those users can just go out of
> band. Or,
> >> they can simply change the script that is used to embed an
> inscription in
> >> the transaction witness. For example, instead of 0 OP_IF?,
> maybe they do 0
> >> OP_DUP OP_DROP OP_IF. When the anti-inscription people detect
> this, they
> >> have to update the rule and wait for 90%
> >> + of the network to upgrade. When the pro-inscription people
> see this,
> >> they only have to convince other inscription enthusiasts and
> businesses to
> >> update.
> >>
> >> The anti-inscription patch has to be run by many more
> participants (most
> >> of whom don?t care), while the pro-inscription update has to be
> run by a
> >> small number of people who care a lot. It?s a losing battle for the
> >> anti-inscription people.
> >>
> >> If you want to prevent inscriptions, the best answer we know of
> today is
> >> economic: the cost of the blockspace needs to be more expensive
> than
> >> inscribers are willing to pay, either because its too expensive
> or because
> >> there?s no market demand for inscriptions. The former relies on
> Bitcoin
> >> becoming more useful to more people, the latter is the natural
> course of
> >> collectibles.
> >>
> >> > Finally, I would like to quote satoshi himself who wrote
> about spam
> >> here is the link:
> >> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
> >>
> >> Appeals to Satoshi are not compelling arguments.
> >>
> >> Cheers,
> >> Rijndael
> >>
> >> On Sun, Jul 30, 2023 at 2:04 PM, L?o Haf via bitcoin-dev <[
> >> bitcoin-dev@lists.linuxfoundation.org](mailto:On Sun, Jul 30,
> 2023 at
> >> 2:04 PM, L?o Haf via bitcoin-dev <<a href=)> wrote:
> >>
> >> > ?According to you, the rules of standardization are useless
> but in this
> >> case why were they introduced? The opreturn limit can be
> circumvented by
> >> miners, yet it is rare to see any, the same for maxancestorcount,
> >> minrelayfee or even the dust limit.
> >> >
> >> > This cat and mouse game can be won by bitcoin defenders. Why
> ? Because
> >> it is easier to detect these transactions and make them a
> standardization
> >> rule than to create new types of spam transactions.
> >> >
> >> > As for the default policy, it can be a weakness but also a
> strength
> >> because if the patch is integrated into Bitcoin Core by being
> activated by
> >> default, the patch will become more and more effective as the
> nodes update.
> >> >
> >> > Also, when it came to using a pre-segwit node, it is not a
> solution
> >> because this type of node cannot initiate new ones, which is
> obviously a
> >> big problem.
> >> >
> >> > Finally, I would like to quote satoshi himself who wrote
> about spam
> >> here is the link:
> >> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
> >> >
> >> >> Le 27 juil. 2023 ? 07:10, vjudeu@gazeta.pl a ?crit :
> >> >
> >> >>
> >> >
> >> >> ?
> >> >
> >> >>> not taking action against these inscription could be
> interpreted by
> >> spammers as tacit acceptance of their practice.
> >> >
> >> >>
> >> >
> >> >> Note that some people, even on this mailing list, do not
> consider
> >> Ordinals as spam:
> >>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021464.html
> >> >
> >> >>
> >> >
> >> >> See? It was discussed when it started. Some people believe that
> >> blocking Ordinals is censorship, and could lead to blocking regular
> >> transactions in the future, just based on other criteria. That
> means, even
> >> if developers would create some official version with that
> option, then
> >> some people would not follow them, or even block
> Ordinals-filtering nodes,
> >> exactly as described in the linked thread:
> >>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021487.html
> >> >
> >> >>
> >> >
> >> >>> as spammers might perceive that the Bitcoin network
> tolerates this
> >> kind of behavior
> >> >
> >> >>
> >> >
> >> >> But it is true, you have the whole pages, where you can find
> images,
> >> files, or other data, that was pushed on-chain long before
> Ordinals. The
> >> whole whitepaper was uploaded just on 1-of-3 multisig outputs, see
> >> transaction
> >>
> 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713.
> You have
> >> the whole altcoins that are connected to Bitcoin by using part
> of the
> >> Bitcoin's UTXO set as their database.
> >> >
> >> >>
> >> >
> >> >> That means, as long as you won't solve IBD problem and UTXO set
> >> growing problem, you will go nowhere, because if you block Ordinals
> >> specifically, people won't learn "this is bad, don't do that",
> they could
> >> read it as "use the old way instead", as long as you won't
> block all
> >> possible ways. And doing that, requires for example creating
> new nodes,
> >> without synchronizing non-consensus data, like it could be done
> in "assume
> >> UTXO" model.
> >> >
> >> >>
> >> >
> >> >> Also note that as long as people use Taproot to upload a lot
> of data,
> >> you can still turn off the witness, and become a pre-Segwit
> node. But if
> >> you block those ways, then people will push data into legacy
> parts, and
> >> then you will need more code to strip it correctly. The block
> 774628 maybe
> >> contains almost 4 MB of data from the perspective of Segwit
> node, but the
> >> legacy part is actually very small, so by turning witness off,
> you can
> >> strip it to maybe just a few kilobytes.
> >> >
> >> >>
> >> >
> >> >>> I want to emphasize that my proposal does not involve
> implementing a
> >> soft fork in any way. On the contrary, what I am asking is
> simply to
> >> consider adding a standardization option. This option would
> allow the
> >> community to freely decide whether it should be activated or not.
> >> >
> >> >>
> >> >
> >> >> 1. Without a soft-fork, those data will be pushed by mining
> pools
> >> anyway, as it happened in the block 774628.
> >> >
> >> >> 2. Adding some settings won't help, as most people use the
> default
> >> configuration. For example, people can configure their nodes to
> allow free
> >> transactions, without recompiling anything. The same with
> disabling dust
> >> amounts. But good luck finding a node in the wild that does
> anything
> >> unusual.
> >> >
> >> >> 3. This patch produced by Luke Dashjr does not address all
> cases. You
> >> could use "OP_TRUE OP_NOTIF" instead of "OP_FALSE OP_IF" used
> by Ordinals,
> >> and easily bypass those restrictions. This will be just a cat
> and mouse
> >> game, where spammers will even use P2PK, if they will be forced
> to. The
> >> Pandora's box is already opened, that fix could be good for
> February or
> >> March, but not now.
> >> >
> >> >>
> >> >
> >> >>
> >> >
> >> >>
> >> >
> >> >>> On 2023-07-26 11:47:09 user leohaf@orangepill.ovh wrote:
> >> >
> >> >>> I understand your point of view. However, inscription
> represent by
> >> far the largest spam attack due to their ability to embed
> themselves in the
> >> witness with a fee reduction.
> >> >
> >> >>
> >> >
> >> >> Unlike other methods, such as using the op_return field
> which could
> >> also be used to spam the chain, the associated fees and the
> standardization
> >> rule limiting op_return to 80 bytes have so far prevented
> similar abuses.
> >> >
> >> >>
> >> >
> >> >> Although attempting to stop inscription could lead to more
> serious
> >> issues, not taking action against these inscription could be
> interpreted by
> >> spammers as tacit acceptance of their practice. This could
> encourage more
> >> similar spam attacks in the future, as spammers might perceive
> that the
> >> Bitcoin network tolerates this kind of behavior.
> >> >
> >> >>
> >> >
> >> >> I want to emphasize that my proposal does not involve
> implementing a
> >> soft fork in any way. On the contrary, what I am asking is
> simply to
> >> consider adding a standardization option. This option would
> allow the
> >> community to freely decide whether it should be activated or not.
> >> >
> >> >>
> >> >
> >> >>
> >> >
> >> >>>> Le 26 juil. 2023 ? 07:30, vjudeu@gazeta.pl a ?crit :
> >> >
> >> >>>> and I would like to understand why this problem has not been
> >> addressed more seriously
> >> >
> >> >>> Because if nobody has any good solution, then status quo is
> >> preserved. If tomorrow ECDSA would be broken, the default state
> of the
> >> network would be "just do nothing", and every solution would be
> >> backward-compatible with that approach. Burn old coins, and
> people will
> >> call it "Tether", redistribute them, and people will call it
> "BSV". Leave
> >> everything untouched, and the network will split into N parts,
> and then you
> >> pick the strongest chain to decide, what should be done.
> >> >
> >> >>>> However, when it comes to inscriptions, there are no available
> >> options except for a patch produced by Luke Dashjr.
> >> >
> >> >>> Because the real solution should address some different
> problem, that
> >> was always there, and nobody knows, how to deal with it: the
> problem of
> >> forever-growing initial blockchain download time, and
> forever-growing UTXO
> >> set. Some changes with "assume UTXO" are trying to address just
> that, but
> >> this code is not yet completed.
> >> >
> >> >>>> So, I wonder why there are no options to reject
> inscriptions in the
> >> mempool of a node.
> >> >
> >> >>> Because it will lead you to never ending chase. You will
> block one
> >> inscriptions, and different ones will be created. Now, they are
> present
> >> even on chains, where there is no Taproot, or even Segwit. That
> means, if
> >> you try to kill them, then they will be replaced by N regular
> >> indistinguishable transactions, and then you will go back to
> those more
> >> serious problems under the hood: IBD time, and UTXO size.
> >> >
> >> >>>> Inscriptions are primarily used to sell NFTs or Tokens,
> concepts
> >> that the Bitcoin community has consistently rejected.
> >> >
> >> >>> The community also rejected things like sidechains, and
> they are
> >> still present, just in a more centralized form. There are some
> unstoppable
> >> concepts, for example soft-forks. You cannot stop a soft-fork. What
> >> inscription creators did, is just non-enforced soft-fork. They
> believe
> >> their rules are followed to the letter, but this is not the
> case, as you
> >> can create a valid Bitcoin transaction, that will be some
> invalid Ordinals
> >> transaction (because their additional rules are not enforced by
> miners and
> >> nodes).
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <
> >>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230730/dfc353d3/attachment.html
> >> >
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >> ------------------------------
> >>
> >> End of bitcoin-dev Digest, Vol 98, Issue 20
> >> *******************************************
> >>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230801/3e3a2496/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 99, Issue 3
> ******************************************
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------fFJ3YYfZ7M293LhHboQBn10Y
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Storage is not and never has been the trouble with block sizes.
Please, before participating in discussions of this topic, at
least get a basic understanding of it. Here's a talk I did a few
years ago to get you started:
<a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=CqNEQS80-h4&t=7s">https://www.youtube.com/watch?v=CqNEQS80-h4&t=7s</a></p>
<p>Luke</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 8/2/23 07:07, GamedevAlice via
bitcoin-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJCwDN-CFyyJhyp_5YTMtSNTN41zp5uJ1qa8vdmVqC2YCW8A6Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div>> If the rate of growth of the blockchain is too high,
Ordinals aren't the<br>
> cause, it's rather that the theoretical limit of the
amount of storage that<br>
> can be added per block isn't sufficiently limited.
(Whether they are used<br>
> to produce Ordinals or something else)</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
True, the real question is whether the storage is in fact
sufficiently limited. And I believe the answer to be 'yes'. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Why? Consider a worst case scenario using the
maximum block size of 4MB and a block time of 10min, that's a
growth of 210.24GB per year. Some of that can be pruned, but
let's just assume that you don't want to. And currently the
entire blockchain is roughly 500GB. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Now that looks like a lot of growth potential
based on where we are at now. However, with the current cost
of hardware, you can get a 5 TB hard drive for less than $150.
That will last you 21 years before you run out of space.
That's less than $0.02 per day. </div>
<div dir="auto"><br>
</div>
<div dir="auto">That is a worst case scenario.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Consider that since cost of hardware drops over
time, it will become less of a burden over time.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Also, keep in mind there are efforts to optimize
how much of that actually needs to be stored by nodes. For
example, the aforementioned topic announcing Floresta which
seems to be a node implementation that uses utreexo to allow
nodes to run without needing to maintain the full UTXO set.
Other initiatives exist as well. </div>
<div dir="auto"><br>
</div>
<div dir="auto">There is definitely a lot of optimization
potential for drastically reducing how much space is actually
needed by individual nodes.</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">On Wed, Aug 2, 2023, 5:40
AM , <<a
href="mailto:bitcoin-dev-request@lists.linuxfoundation.org"
target="_blank" rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">bitcoin-dev-request@lists.linuxfoundation.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Send
bitcoin-dev mailing list submissions to<br>
<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
or, via email, send a message with subject or body 'help'
to<br>
<a
href="mailto:bitcoin-dev-request@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev-request@lists.linuxfoundation.org</a><br>
<br>
You can reach the person managing the list at<br>
<a
href="mailto:bitcoin-dev-owner@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev-owner@lists.linuxfoundation.org</a><br>
<br>
When replying, please edit your Subject line so it is more
specific<br>
than "Re: Contents of bitcoin-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Pull-req to enable Full-RBF by default (Peter
Todd)<br>
2. Re: Concern about "Inscriptions". (ashneverdawn)<br>
(Keagan McClelland)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 2 Aug 2023 01:28:06 +0000<br>
From: Peter Todd <<a href="mailto:pete@petertodd.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">pete@petertodd.org</a>><br>
To: Daniel Lipshitz <<a href="mailto:daniel@gap600.com"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">daniel@gap600.com</a>><br>
Cc: Bitcoin Protocol Discussion<br>
<<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a>><br>
Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by
default<br>
Message-ID: <ZMmxJoL1ZH4//<a
href="mailto:8Fg@petertodd.org" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">8Fg@petertodd.org</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz
wrote:<br>
> Your research is not thorough and reaches an
incorrect conclusion.<br>
> <br>
> As stated many times - we service payment processors
and some merchants<br>
> directly - Coinspaid services multiple merchants and
process a<br>
> significant amount of BTC they are a well known and
active in the space -<br>
> as I provided back in December 2022 a email from Max
the CEO of Coinspaid<br>
> confirming their use of 0-conf as well as providing
there cluster addresses<br>
> to validate there deposit flows see here again -<br>
> <a
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html</a><br>
> - if this is not sufficient then please email <a
href="mailto:support@coinspaid.com" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">support@coinspaid.com</a>
and ask<br>
> to be connected to Max or someone from the team who
can confirm Conspaid is<br>
> clients of GAP600. Max also at the time was open to
do a call, I can check<br>
> again now and see if this is still the case and
connect you.<br>
> <br>
> That on its own is enough of a sample to validate our
statistics.<br>
<br>
Why don't you just give me an example of some merchants
using Coinspaid, and<br>
another example using Coinpayments, who rely on
unconfirmed transactions? If<br>
those merchants actually exist it should be very easy to
give me some names of<br>
them.<br>
<br>
Without actual concrete examples for everyone to see for
themselves, why should<br>
we believe you?<br>
<br>
> I have also spoken to Changelly earlier today and
they offered to email pro<br>
> @ <a href="http://changelly.com" rel="noreferrer
noreferrer noreferrer" target="_blank"
moz-do-not-send="true">changelly.com</a> and they will
be able to confirm GAP600 as a service<br>
<br>
Emailed; waiting on a reply.<br>
<br>
> provider. Also please send me the 1 trx hash you
tested and I can see if it<br>
> was queried to our system and if so offer some info
as to why it wasnt<br>
> approved. Also if you can elaborate how you
integrated with Changelly - I<br>
> can check with them if that area is not integrated
with GAP600.<br>
<br>
Why don't you just tell me exactly what service Changelly
offers that relies on<br>
unconfirmed transactions, and what characteristics would
meet GAP600's risk<br>
criteria? I and others on this mailing list could easily
do test transactions<br>
if you told us what we can actually test. If your service
actually works, then<br>
you can safely provide that information.<br>
<br>
I'm not going to give you any exact tx hashes of
transactions I've already<br>
done, as I don't want to cause any problems for the owners
of the accounts I<br>
borrowed for testing. Given your lack of honesty so far I
have every reason to<br>
believe they might be retalliated against in some way.<br>
<br>
> As the architect of such a major change to the status
of 0-conf<br>
> transactions I would think you would welcome the
opportunity to speak to<br>
> business and users who actual activities will be
impacted by full RBF<br>
> becoming dominant.<br>
<br>
Funny how you say this, without actually giving any
concrete examples of<br>
businesses that will be affected. Who exactly are these
businesses? Payment<br>
processors obviously don't count.<br>
<br>
> Are you able to provide the same i.e emails and
contacts of people at<br>
> the mining pools who can confirm they have adopted
FULL RBF ?<br>
<br>
I've already had multiple mining pools complain to me that
they and their<br>
employees have been harassed over full-rbf, so obviously
I'm not going to<br>
provide you with any private contact information I have.
There's no need to<br>
expose them to further harassment.<br>
<br>
If you actually offered an unconfirmed transaction
guarantee service, with real<br>
customers getting an actual benefit, you'd be doing test
transactions<br>
frequently and would already have a very good idea of what
pools do full-rbf.<br>
Why don't you already have this data?<br>
<br>
-- <br>
<a href="https://petertodd.org" rel="noreferrer noreferrer
noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://petertodd.org</a>
'peter'[:-1]@<a href="http://petertodd.org"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true">petertodd.org</a><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 833 bytes<br>
Desc: not available<br>
URL: <<a
href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/7f826021/attachment-0001.sig"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/7f826021/attachment-0001.sig</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 1 Aug 2023 22:58:53 -0700<br>
From: Keagan McClelland <<a
href="mailto:keagan.mcclelland@gmail.com"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">keagan.mcclelland@gmail.com</a>><br>
To: Hugo L <<a href="mailto:ashneverdawn@gmail.com"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">ashneverdawn@gmail.com</a>>,
Bitcoin Protocol Discussion<br>
<<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a>><br>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions".<br>
(ashneverdawn)<br>
Message-ID:<br>
<<a
href="mailto:CALeFGL2Z3q90Esnu0qV0mqpHZaCnOV-5aks2TKGOjY4L%2B14d3w@mail.gmail.com"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">CALeFGL2Z3q90Esnu0qV0mqpHZaCnOV-5aks2TKGOjY4L+14d3w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
There is an open question as to whether or not we should
figure out a way<br>
to price space in the UTXO set. I think it is fair to say
that given the<br>
fact that the UTXO set space remains unpriced that we
actually have no way<br>
to determine whether some of these transactions are spam
or not. The UTXO<br>
set must be maintained by all nodes including pruned
nodes, whereas main<br>
block and witness data do not have the same type of
indefinite footprint,<br>
so in some sense it is an even more significant resource
than chain space.<br>
We may very well discover that if we price UTXOs in a way
that reflect the<br>
resource costs that usage of inscriptions would vanish.
The trouble though<br>
is that such a mechanism would imply having to pay "rent"
for an "account"<br>
with Bitcoin, a proposition that would likely be offensive
to a significant<br>
portion of the Bitcoin user base.<br>
<br>
Cheers,<br>
Keags<br>
<br>
On Mon, Jul 31, 2023 at 4:55?AM Hugo L via bitcoin-dev
<<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a>>
wrote:<br>
<br>
> I don't think it's anyone's place to judge which
types of transactions<br>
> should be allowed or not on the network, in fact,
when it comes to privacy<br>
> and censorship resistance, it would be better if we
were not even able to<br>
> distinguish different types of transactions from one
another in the first<br>
> place.<br>
><br>
> We have limited resources on the blockchain and so
they should go to the<br>
> highest bidder. This is already how the network
functions and how it<br>
> ensures it's security.<br>
><br>
> Rather than thinking about this as "spam", I think
it's useful to<br>
> objectively think about it in terms of value to the
marketplace (fees<br>
> they're willing to pay) against cost to the network
(storage consumed). It<br>
> comes down to supply and demand.<br>
><br>
> If the rate of growth of the blockchain is too high,
Ordinals aren't the<br>
> cause, it's rather that the theoretical limit of the
amount of storage that<br>
> can be added per block isn't sufficiently limited.
(Whether they are used<br>
> to produce Ordinals or something else)<br>
><br>
><br>
><br>
> On Sun, Jul 30, 2023, 5:51 PM , <<br>
> <a
href="mailto:bitcoin-dev-request@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev-request@lists.linuxfoundation.org</a>>
wrote:<br>
><br>
>> Send bitcoin-dev mailing list submissions to<br>
>> <a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a><br>
>><br>
>> To subscribe or unsubscribe via the World Wide
Web, visit<br>
>> <a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
>> or, via email, send a message with subject or
body 'help' to<br>
>> <a
href="mailto:bitcoin-dev-request@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev-request@lists.linuxfoundation.org</a><br>
>><br>
>> You can reach the person managing the list at<br>
>> <a
href="mailto:bitcoin-dev-owner@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev-owner@lists.linuxfoundation.org</a><br>
>><br>
>> When replying, please edit your Subject line so
it is more specific<br>
>> than "Re: Contents of bitcoin-dev digest..."<br>
>><br>
>><br>
>> Today's Topics:<br>
>><br>
>> 1. Re: Concern about "Inscriptions".
(rot13maxi)<br>
>><br>
>><br>
>>
----------------------------------------------------------------------<br>
>><br>
>> Message: 1<br>
>> Date: Sun, 30 Jul 2023 18:34:12 +0000<br>
>> From: rot13maxi <<a
href="mailto:rot13maxi@protonmail.com" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">rot13maxi@protonmail.com</a>><br>
>> To: L?o Haf <a class="moz-txt-link-rfc2396E" href="mailto:leohaf@orangepill.ovh"><leohaf@orangepill.ovh></a>, "<a
href="mailto:vjudeu@gazeta.pl" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">vjudeu@gazeta.pl</a>"<br>
>> <<a href="mailto:vjudeu@gazeta.pl"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">vjudeu@gazeta.pl</a>><br>
>> Cc: Bitcoin Protocol Discussion<br>
>> <<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a>><br>
>> Subject: Re: [bitcoin-dev] Concern about
"Inscriptions".<br>
>> Message-ID:<br>
>><br>
>>
<RIqguuebFmAhEDqCY_0T8KRqHBXEfcvPw6-MbDIyWsAWpLenFFeOVx88-068QFZr7xowg-6Zg988HsRCKdswtZC6QUKPXnrTyTAc_l5jphg=@<br>
>> <a href="http://protonmail.com" rel="noreferrer
noreferrer noreferrer" target="_blank"
moz-do-not-send="true">protonmail.com</a>><br>
>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Hello,<br>
>><br>
>> > This cat and mouse game can be won by
bitcoin defenders. Why ? Because<br>
>> it is easier to detect these transactions and
make them a standardization<br>
>> rule than to create new types of spam
transactions.<br>
>><br>
>> One of the things discussed during the
mempoolfullrbf discussion is that<br>
>> a small (~10%) of nodes willing to relay a class
of transaction is enough<br>
>> for that class of transaction to consistently
reach miners. That means you<br>
>> would need to get nearly the entire network to
run updated relay policy to<br>
>> prevent inscriptions from trivially reaching
miners and being included in<br>
>> blocks. Inscription users have shown that they
are willing and able to send<br>
>> non-standard transactions to miners out of band (<br>
>> <a
href="https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae</a>),<br>
>> so even if you managed to get enough of the
network running the new rule to<br>
>> prevent propagation to miners, those users can
just go out of band. Or,<br>
>> they can simply change the script that is used to
embed an inscription in<br>
>> the transaction witness. For example, instead of
0 OP_IF?, maybe they do 0<br>
>> OP_DUP OP_DROP OP_IF. When the anti-inscription
people detect this, they<br>
>> have to update the rule and wait for 90%<br>
>> + of the network to upgrade. When the
pro-inscription people see this,<br>
>> they only have to convince other inscription
enthusiasts and businesses to<br>
>> update.<br>
>><br>
>> The anti-inscription patch has to be run by many
more participants (most<br>
>> of whom don?t care), while the pro-inscription
update has to be run by a<br>
>> small number of people who care a lot. It?s a
losing battle for the<br>
>> anti-inscription people.<br>
>><br>
>> If you want to prevent inscriptions, the best
answer we know of today is<br>
>> economic: the cost of the blockspace needs to be
more expensive than<br>
>> inscribers are willing to pay, either because its
too expensive or because<br>
>> there?s no market demand for inscriptions. The
former relies on Bitcoin<br>
>> becoming more useful to more people, the latter
is the natural course of<br>
>> collectibles.<br>
>><br>
>> > Finally, I would like to quote satoshi
himself who wrote about spam<br>
>> here is the link:<br>
>> <a
href="https://bitcointalk.org/index.php?topic=195.msg1617#msg1617"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bitcointalk.org/index.php?topic=195.msg1617#msg1617</a><br>
>><br>
>> Appeals to Satoshi are not compelling arguments.<br>
>><br>
>> Cheers,<br>
>> Rijndael<br>
>><br>
>> On Sun, Jul 30, 2023 at 2:04 PM, L?o Haf via
bitcoin-dev <[<br>
>> <a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a>](mailto:<a
href="mailto:On" rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">On</a> Sun, Jul 30, 2023
at<br>
>> 2:04 PM, L?o Haf via bitcoin-dev <<a
href=)> wrote:<br>
>><br>
>> > ?According to you, the rules of
standardization are useless but in this<br>
>> case why were they introduced? The opreturn limit
can be circumvented by<br>
>> miners, yet it is rare to see any, the same for
maxancestorcount,<br>
>> minrelayfee or even the dust limit.<br>
>> ><br>
>> > This cat and mouse game can be won by
bitcoin defenders. Why ? Because<br>
>> it is easier to detect these transactions and
make them a standardization<br>
>> rule than to create new types of spam
transactions.<br>
>> ><br>
>> > As for the default policy, it can be a
weakness but also a strength<br>
>> because if the patch is integrated into Bitcoin
Core by being activated by<br>
>> default, the patch will become more and more
effective as the nodes update.<br>
>> ><br>
>> > Also, when it came to using a pre-segwit
node, it is not a solution<br>
>> because this type of node cannot initiate new
ones, which is obviously a<br>
>> big problem.<br>
>> ><br>
>> > Finally, I would like to quote satoshi
himself who wrote about spam<br>
>> here is the link:<br>
>> <a
href="https://bitcointalk.org/index.php?topic=195.msg1617#msg1617"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bitcointalk.org/index.php?topic=195.msg1617#msg1617</a><br>
>> ><br>
>> >> Le 27 juil. 2023 ? 07:10, <a
href="mailto:vjudeu@gazeta.pl" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">vjudeu@gazeta.pl</a> a
?crit :<br>
>> ><br>
>> >><br>
>> ><br>
>> >> ?<br>
>> ><br>
>> >>> not taking action against these
inscription could be interpreted by<br>
>> spammers as tacit acceptance of their practice.<br>
>> ><br>
>> >><br>
>> ><br>
>> >> Note that some people, even on this
mailing list, do not consider<br>
>> Ordinals as spam:<br>
>> <a
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021464.html"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021464.html</a><br>
>> ><br>
>> >><br>
>> ><br>
>> >> See? It was discussed when it started.
Some people believe that<br>
>> blocking Ordinals is censorship, and could lead
to blocking regular<br>
>> transactions in the future, just based on other
criteria. That means, even<br>
>> if developers would create some official version
with that option, then<br>
>> some people would not follow them, or even block
Ordinals-filtering nodes,<br>
>> exactly as described in the linked thread:<br>
>> <a
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021487.html"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021487.html</a><br>
>> ><br>
>> >><br>
>> ><br>
>> >>> as spammers might perceive that the
Bitcoin network tolerates this<br>
>> kind of behavior<br>
>> ><br>
>> >><br>
>> ><br>
>> >> But it is true, you have the whole
pages, where you can find images,<br>
>> files, or other data, that was pushed on-chain
long before Ordinals. The<br>
>> whole whitepaper was uploaded just on 1-of-3
multisig outputs, see<br>
>> transaction<br>
>>
54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713.
You have<br>
>> the whole altcoins that are connected to Bitcoin
by using part of the<br>
>> Bitcoin's UTXO set as their database.<br>
>> ><br>
>> >><br>
>> ><br>
>> >> That means, as long as you won't solve
IBD problem and UTXO set<br>
>> growing problem, you will go nowhere, because if
you block Ordinals<br>
>> specifically, people won't learn "this is bad,
don't do that", they could<br>
>> read it as "use the old way instead", as long as
you won't block all<br>
>> possible ways. And doing that, requires for
example creating new nodes,<br>
>> without synchronizing non-consensus data, like it
could be done in "assume<br>
>> UTXO" model.<br>
>> ><br>
>> >><br>
>> ><br>
>> >> Also note that as long as people use
Taproot to upload a lot of data,<br>
>> you can still turn off the witness, and become a
pre-Segwit node. But if<br>
>> you block those ways, then people will push data
into legacy parts, and<br>
>> then you will need more code to strip it
correctly. The block 774628 maybe<br>
>> contains almost 4 MB of data from the perspective
of Segwit node, but the<br>
>> legacy part is actually very small, so by turning
witness off, you can<br>
>> strip it to maybe just a few kilobytes.<br>
>> ><br>
>> >><br>
>> ><br>
>> >>> I want to emphasize that my proposal
does not involve implementing a<br>
>> soft fork in any way. On the contrary, what I am
asking is simply to<br>
>> consider adding a standardization option. This
option would allow the<br>
>> community to freely decide whether it should be
activated or not.<br>
>> ><br>
>> >><br>
>> ><br>
>> >> 1. Without a soft-fork, those data will
be pushed by mining pools<br>
>> anyway, as it happened in the block 774628.<br>
>> ><br>
>> >> 2. Adding some settings won't help, as
most people use the default<br>
>> configuration. For example, people can configure
their nodes to allow free<br>
>> transactions, without recompiling anything. The
same with disabling dust<br>
>> amounts. But good luck finding a node in the wild
that does anything<br>
>> unusual.<br>
>> ><br>
>> >> 3. This patch produced by Luke Dashjr
does not address all cases. You<br>
>> could use "OP_TRUE OP_NOTIF" instead of "OP_FALSE
OP_IF" used by Ordinals,<br>
>> and easily bypass those restrictions. This will
be just a cat and mouse<br>
>> game, where spammers will even use P2PK, if they
will be forced to. The<br>
>> Pandora's box is already opened, that fix could
be good for February or<br>
>> March, but not now.<br>
>> ><br>
>> >><br>
>> ><br>
>> >><br>
>> ><br>
>> >><br>
>> ><br>
>> >>> On 2023-07-26 11:47:09 user
<a class="moz-txt-link-abbreviated" href="mailto:leohaf@orangepill.ovh">leohaf@orangepill.ovh</a> wrote:<br>
>> ><br>
>> >>> I understand your point of view.
However, inscription represent by<br>
>> far the largest spam attack due to their ability
to embed themselves in the<br>
>> witness with a fee reduction.<br>
>> ><br>
>> >><br>
>> ><br>
>> >> Unlike other methods, such as using the
op_return field which could<br>
>> also be used to spam the chain, the associated
fees and the standardization<br>
>> rule limiting op_return to 80 bytes have so far
prevented similar abuses.<br>
>> ><br>
>> >><br>
>> ><br>
>> >> Although attempting to stop inscription
could lead to more serious<br>
>> issues, not taking action against these
inscription could be interpreted by<br>
>> spammers as tacit acceptance of their practice.
This could encourage more<br>
>> similar spam attacks in the future, as spammers
might perceive that the<br>
>> Bitcoin network tolerates this kind of behavior.<br>
>> ><br>
>> >><br>
>> ><br>
>> >> I want to emphasize that my proposal
does not involve implementing a<br>
>> soft fork in any way. On the contrary, what I am
asking is simply to<br>
>> consider adding a standardization option. This
option would allow the<br>
>> community to freely decide whether it should be
activated or not.<br>
>> ><br>
>> >><br>
>> ><br>
>> >><br>
>> ><br>
>> >>>> Le 26 juil. 2023 ? 07:30, <a
href="mailto:vjudeu@gazeta.pl" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">vjudeu@gazeta.pl</a> a
?crit :<br>
>> ><br>
>> >>>> and I would like to understand
why this problem has not been<br>
>> addressed more seriously<br>
>> ><br>
>> >>> Because if nobody has any good
solution, then status quo is<br>
>> preserved. If tomorrow ECDSA would be broken, the
default state of the<br>
>> network would be "just do nothing", and every
solution would be<br>
>> backward-compatible with that approach. Burn old
coins, and people will<br>
>> call it "Tether", redistribute them, and people
will call it "BSV". Leave<br>
>> everything untouched, and the network will split
into N parts, and then you<br>
>> pick the strongest chain to decide, what should
be done.<br>
>> ><br>
>> >>>> However, when it comes to
inscriptions, there are no available<br>
>> options except for a patch produced by Luke
Dashjr.<br>
>> ><br>
>> >>> Because the real solution should
address some different problem, that<br>
>> was always there, and nobody knows, how to deal
with it: the problem of<br>
>> forever-growing initial blockchain download time,
and forever-growing UTXO<br>
>> set. Some changes with "assume UTXO" are trying
to address just that, but<br>
>> this code is not yet completed.<br>
>> ><br>
>> >>>> So, I wonder why there are no
options to reject inscriptions in the<br>
>> mempool of a node.<br>
>> ><br>
>> >>> Because it will lead you to never
ending chase. You will block one<br>
>> inscriptions, and different ones will be created.
Now, they are present<br>
>> even on chains, where there is no Taproot, or
even Segwit. That means, if<br>
>> you try to kill them, then they will be replaced
by N regular<br>
>> indistinguishable transactions, and then you will
go back to those more<br>
>> serious problems under the hood: IBD time, and
UTXO size.<br>
>> ><br>
>> >>>> Inscriptions are primarily used
to sell NFTs or Tokens, concepts<br>
>> that the Bitcoin community has consistently
rejected.<br>
>> ><br>
>> >>> The community also rejected things
like sidechains, and they are<br>
>> still present, just in a more centralized form.
There are some unstoppable<br>
>> concepts, for example soft-forks. You cannot stop
a soft-fork. What<br>
>> inscription creators did, is just non-enforced
soft-fork. They believe<br>
>> their rules are followed to the letter, but this
is not the case, as you<br>
>> can create a valid Bitcoin transaction, that will
be some invalid Ordinals<br>
>> transaction (because their additional rules are
not enforced by miners and<br>
>> nodes).<br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a
href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230730/dfc353d3/attachment.html"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230730/dfc353d3/attachment.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Subject: Digest Footer<br>
>><br>
>> _______________________________________________<br>
>> bitcoin-dev mailing list<br>
>> <a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a><br>
>> <a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> End of bitcoin-dev Digest, Vol 98, Issue 20<br>
>> *******************************************<br>
>><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a
href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230801/3e3a2496/attachment.html"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230801/3e3a2496/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of bitcoin-dev Digest, Vol 99, Issue 3<br>
******************************************<br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
</body>
</html>
--------------fFJ3YYfZ7M293LhHboQBn10Y--