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 , > 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 > To: Daniel Lipshitz > Cc: Bitcoin Protocol Discussion >         > Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default > Message-ID: > 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 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 > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 833 bytes > Desc: not available > URL: > > > ------------------------------ > > Message: 2 > Date: Tue, 1 Aug 2023 22:58:53 -0700 > From: Keagan McClelland > To: Hugo L , Bitcoin Protocol Discussion >         > Subject: Re: [bitcoin-dev] Concern about "Inscriptions". >         (ashneverdawn) > Message-ID: >         > > > 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 > >> To: L?o Haf , "vjudeu@gazeta.pl" > >>          > >> Cc: Bitcoin Protocol Discussion > >>          > >> Subject: Re: [bitcoin-dev] Concern about "Inscriptions". > >> Message-ID: > >> > >> > >> 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 < 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: > > > ------------------------------ > > 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