datacarriersize: Match more datacarrying

luke-jr commented at 3:02 am on September 5, 2023: member

Updates -datacarriersize to be effective with newer datacarrying styles.

DrahtBot commented at 3:02 am on September 5, 2023: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept NACK	Sjors, petertodd, darosior, douglaz, aviv57, eragmus, mmgen, alpeshvas, michaelfolkson, sipa, glozow, murchandamus
Concept ACK	ChrisMartl, Retropex, Sun0fABeach, hmisty, 1ma, conduition, ns-xvrn, dzyphr, desi-bitcoiner
Approach ACK	wizkid057
Approach NACK	1440000bytes, ajtowns

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

No conflicts as of last run.

DrahtBot added the label CI failed on Sep 5, 2023

glozow commented at 7:07 am on September 5, 2023: member

Maybe add some tests?

luke-jr referenced this in commit 080b93064e on Sep 5, 2023

luke-jr referenced this in commit beda78c1fb on Sep 5, 2023

luke-jr referenced this in commit 63b399dd3c on Sep 5, 2023

luke-jr referenced this in commit 6a9fc14cd0 on Sep 6, 2023

luke-jr referenced this in commit 19b825b7f1 on Sep 6, 2023

luke-jr referenced this in commit ead77af9e6 on Sep 6, 2023

Retropex commented at 12:35 pm on September 7, 2023: none

Maybe I’m doing something wrong but it will seem that my node no longer receives any txs with this update if datacarrier=0

02023-09-07T12:23:39Z Imported mempool transactions from disk: 0 succeeded, 1516 failed, 0 expired, 0 already there, 0 waiting for initial broadcast

in src/validation.cpp:815 in c49ed98678 outdated

811@@ -812,6 +812,10 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, Workspace& ws)
812         return state.Invalid(TxValidationResult::TX_INPUTS_NOT_STANDARD, "bad-txns-nonstandard-inputs");
813     }
814 
815+    if (DatacarrierBytes(tx, m_view) > m_pool.m_max_datacarrier_bytes) {

LarryRuane commented at 6:33 pm on September 20, 2023:

0    if (m_pool.m_max_datacarrier_bytes && DatacarrierBytes(tx, m_view) > *m_pool.m_max_datacarrier_bytes) {

This fixes the problem mentioned in #28408 (comment) (which I can reproduce), and is necessary because m_pool.m_max_datacarrier_bytes is type std::optional<unsigned int>. If the configuration includes datacarrier=0 this variable is nullopt. It’s surprising to me that without this suggestion (comparing an int32_t to an unset std::optional<unsigned int> for greater-than), the test succeeds (which deems the transaction to be invalid, so the mempool stays completely empty).

This suggestion also requires changing the return type of DatacarrierBytes() from int32_t to uint32_t (I think an unsigned type makes more sense anyway).

Note that this change does not cause the mempool to accept data-carrying transactions (as it might appear) if datacarrier=0 because they’re filtered out by the call to IsStandardTx() earlier in this function.

Retropex commented at 7:35 am on September 21, 2023:

It worked all transactions are no longer purged at startup, however even with datacarrier=0, inscriptions still appear in my mempool(I don’t know if it still works for inscriptions of more than 80 bytes).

We can see it here, as my node refuses the inscriptions they are supposed to appear in blue however we see that many of them have still passed.

That said, it seems to work if instead of using datacarrier=0 we use datacarriersize=0.

ChrisMartl commented at 11:33 am on September 21, 2023:

But a code correction is needed in order datacarriersize=0 to behave as expected.

0    if (DatacarrierBytes(tx, m_view) > *m_pool.m_max_datacarrier_bytes) {

https://github.com/luke-jr/bitcoin/pull/10/commits/669cdb01e75c432501f096e752a0342caf08d4a0

Retropex commented at 10:49 am on September 22, 2023:

datacarriersize=0 works as expected with @LarryRuane’s suggestions.

ChrisMartl commented at 2:09 pm on September 22, 2023:

Also with this #https://github.com/bitcoin/bitcoin/pull/28408#discussion_r1332912845 suggestion?

Retropex commented at 4:13 pm on September 22, 2023:

I don’t know, I haven’t tested your suggestions.

ChrisMartl commented at 9:01 pm on September 22, 2023:

m_pool.m_max_datacarrier_bytes && @LarryRuane: why is that condition necessary? It provides always a pointer different than NULL, right? It is always interpreted as “True” by the ‘If’ conditional expression.

LarryRuane commented at 1:51 pm on September 24, 2023:

It’s necessary because m_pool.m_max_datacarrier_bytes isn’t a pointer, it’s a std::optional. It may be unset (it will be if the config includes -datacarrier=0), so it must be tested in this way (or we could call m_pool.m_max_datacarrier_bytes.has_value(), which would have the same effect) before attempting to access the contained value (which is what the * does).

ChrisMartl commented at 3:28 pm on September 24, 2023:

@LarryRuane: You are right about: m_pool.m_max_datacarrier_bytes isn’t a pointer, it’s a std::optional.

Two user parameters are in play: -datacarrier and -datacarriersize

Following code extract determine the behavior:

if (argsman.GetBoolArg("-datacarrier", DEFAULT_ACCEPT_DATACARRIER)) { mempool_opts.max_datacarrier_bytes = argsman.GetIntArg("-datacarriersize", MAX_OP_RETURN_RELAY); } else { mempool_opts.max_datacarrier_bytes = std::nullopt; }

In case -datacarrier=0, then your proposal will not work as intended since max_datacarrier_bytes will be std::nullopt and the conditional: if (m_pool.m_max_datacarrier_bytes && DatacarrierBytes(tx, m_view) > *m_pool.m_max_datacarrier_bytes) is not fulfilled.

For that reason here a suggested code change:

0    if (!m_pool.m_max_datacarrier_bytes || (DatacarrierBytes(tx, m_view) > *m_pool.m_max_datacarrier_bytes)) {

LarryRuane commented at 3:57 pm on September 24, 2023:

No, if you do this (and the config includes -datacarrier=0), then all transactions are rejected. (Try it, you’ll see that bitcoin-cli getmempoolinfo shows size and bytes are zero.) We don’t want that, we want all data-carrying transactions to be rejected, but non-data carrying should not be rejected.

ChrisMartl commented at 4:01 pm on September 24, 2023:

Yes. You are right again!

ChrisMartl commented at 4:06 pm on September 24, 2023:

What is the intended use case for: -datacarriers=0?

It seems to be: -datacarrier=1 -datacarriersize=0 If the new policy rule should reject any data-carrying transaction, right?

ChrisMartl commented at 10:45 am on September 25, 2023:

Maybe following code suggestion could consider the use cases:

no datacarrier option given: default full node behavior no datacarrier option given and no datacarriersize option given: same behavior like use case above

-datacarrier=0: full node does not accept any transaction with data carrier -datacarrier=0: and -datacarriersize=“any number”: same behavior like use case above -datacarrier=1 and -datacarriersize=0: same behavior like use case above no datacarrier option given and -datacarriersize=0: same behavior like use case above

-datacarrier=1 and -datacarriersize=“any non-zero number”: full node accept data carrier transactions until size of data carrier being less than “any non-zero number” no datacarrier option given and -datacarriersize=“any non-zero number”: same behavior like use case above

In validation.cpp:

0    if (IsDataCarrier(tx, m_view, m_pool.m_max_datacarrier_bytes)) {

In policy.h: bool IsDataCarrier(const CTransaction& tx, const CCoinsViewCache& view, const std::optional<unsigned>& max_datacarrier_bytes);

In policy.cpp: bool IsDataCarrier(const CTransaction& tx, const CCoinsViewCache& view, const std::optional<unsigned>& max_datacarrier_bytes) { bool fRet{0}; uint32_t DataCarrierBytesSize{0}; DataCarrierBytesSize = DatacarrierBytes(tx, view); if (DataCarrierBytesSize > 0){ if (!max_datacarrier_bytes){ fRet = true; }else{ if (max_datacarrier_bytes.has_value() && (DataCarrierBytesSize > *max_datacarrier_bytes)){ fRet = true; } } } return fRet; }

luke-jr commented at 0:14 am on September 28, 2023:

0    if (DatacarrierBytes(tx, m_view) > *m_pool.m_max_datacarrier_bytes) {

This would be undefined behaviour if it’s a nullopt. Using .value_or(0) instead.

Retropex commented at 11:58 am on September 21, 2023: none

Needs the tests fixed

Do you have any suggestions to fix this?

LarryRuane commented at 4:04 pm on September 23, 2023: contributor

@MarcoFalke @glozow I’ve written some unit tests, will push to a branch and suggest it here.

in src/script/script.cpp:314 in c49ed98678 outdated

304+            // Invalid scripts are necessarily all data
305+            return size();
306+        }
307+
308+        // Match OP_FALSE OP_IF
309+        if (inside_noop) {

LarryRuane commented at 3:24 pm on September 24, 2023:

nit, to show that this isn’t a bool

0        if (inside_noop > 0) {

in src/script/script.cpp:321 in c49ed98678 outdated

311+            case OP_IF: case OP_NOTIF:
312+                ++inside_noop;
313+                break;
314+            case OP_ENDIF:
315+                if (0 == --inside_noop) {
316+                    counted += it - data_began + 1;

LarryRuane commented at 3:25 pm on September 24, 2023:

Confirming the + 1, that counts the OP_FALSE.

in src/script/script.cpp:362 in c49ed98678 outdated

349+    int witnessversion = 0;
350+    std::vector<unsigned char> witnessprogram;
351+
352+    if (!prevScript.IsWitnessProgram(witnessversion, witnessprogram)) {
353+        return std::make_pair(prevScript, WITNESS_SCALE_FACTOR);
354+    }

LarryRuane commented at 3:32 pm on September 24, 2023:

I’m confused about this. If p2sh is false, won’t we be counting bytes from the previous transaction’s scriptPubKey (output)?

luke-jr commented at 3:31 pm on September 28, 2023:

Yes, it should probably check scriptSig instead here.

LarryRuane commented at 3:40 pm on September 24, 2023: contributor

I pushed some unit tests to https://github.com/LarryRuane/bitcoin/commits/2023-09-luke-DatacarrierBytes-test (only the latest commit). It looks like some functional tests are failing (p2p_segwit.py, at least), and there should be some new functional tests for this PR. I’ll try to do that over the next couple of days.

petertodd commented at 8:34 am on September 26, 2023: contributor

Concept NACK

The transactions targeted by this pull-req are a very significant source of fee revenue for miners. It is very unlikely that minres will give up that source of revenue. Censoring those transactions would simply encourage the development of private mempools - harmful to small miners - while making fee estimation less reliable.

ChrisMartl commented at 8:53 am on September 26, 2023: none

Concept ACK

The transactions targeted by this pull-req. are a very significant source of prohibitive cost for regular node operators. It is very unlikely that regular node operators will give up mitigating that source of operative cost. Regular policy rule for these transactions would encourage the economical resource usage of mempools - not harming any miners - neither changing any fee estimation already on the field.

petertodd commented at 9:15 am on September 26, 2023: contributor

Concept ACK

The transactions targeted by this pull-req. are a very significant source of prohibitive cost for regular node operators. It is very unlikely that regular node operators will give up mitigating that source of operative cost. Regular policy rule for these transactions would encourage the economical resource usage of mempools - not harming any miners - neither changing any fee estimation already on the field.

As long as miners continue to mine these transactions they will end up in blocks, requiring node operators to process those transactions. Censoring those transactions simply shifts when that bandwidth usage happens. Indeed, it’ll make block propagation happen somewhat slower for some users/miners due to interference with compact blocks. This is harmful to many users, as well as some smaller miners.

Secondly, fee estimation requires knowledge of unconfirmed transactions to determine what the next block will likely consist of. Censoring unconfirmed transactions that could be included in blocks makes it harder to estimate fees correctly because you lack information about the true total demand for blockspace.

ChrisMartl commented at 9:43 am on September 26, 2023: none

Concept ACK The transactions targeted by this pull-req. are a very significant source of prohibitive cost for regular node operators. It is very unlikely that regular node operators will give up mitigating that source of operative cost. Regular policy rule for these transactions would encourage the economical resource usage of mempools - not harming any miners - neither changing any fee estimation already on the field.

As long as miners continue to mine these transactions they will end up in blocks, requiring node operators to process those transactions. Censoring those transactions simply shifts when that bandwidth usage happens. Indeed, it’ll make block propagation happen somewhat slower for some users/miners due to interference with compact blocks. This is harmful to many users, as well as some smaller miners.

Secondly, fee estimation requires knowledge of unconfirmed transactions to determine what the next block will likely consist of. Censoring unconfirmed transactions that could be included in blocks makes it harder to estimate fees correctly because you lack information about the true total demand for blockspace.

There is not censoring of anything. Focusing to propagate that framing is just misleading and dishonest.

Miners entities will propose any block which complies the consensus rules; it was so since the beginning, it is so and it will remain so. Nothing has changed, nothing will change.

If block propagation after consensus rules validation may slow somehow then that would be the cost internalization for mining entities proposing blocks with transaction which increment prohibitively the operation cost for regular node operators.

There are already many mechanisms to increment the fees from an already broadcasted transaction (nobody probably knows that better than the RBF’s proposal author). Furthermore, there is not something called “demand for blockspace”, what there is, is a fee bidding for transaction processing in a timely manner; a compensation for mining entities for losing relative competitiveness with each marginal transaction inclusion.

Retropex commented at 11:51 am on September 26, 2023: none

Secondly, fee estimation requires knowledge of unconfirmed transactions to determine what the next block will likely consist of. Censoring unconfirmed transactions that could be included in blocks makes it harder to estimate fees correctly because you lack information about the true total demand for blockspace.

False, I let you compare these two instances of the mempool software you will see that the fees are rarely incorrect.

https://mempool.space https://orangepill.ovh

Censoring those transactions would simply encourage the development of private mempools - harmful to small miners

You are mistaken about the purpose of this PR, the goal is simply to apply the same restrictions as on OP_RETURN.

As long as miners continue to mine these transactions they will end up in blocks

Probably false, mining pools require exorbitant fees to mine a tx out of the mempool, thus making the “mint” of “BRC-20 tokens” unprofitable. He will therefore stop having demand for that.

Retropex commented at 12:16 pm on September 26, 2023: none

Concept ACK

These transactions affect the decentralization of the network by increasing the cost of operating the nodes, which are without any added value for bitcoin.

petertodd commented at 12:29 pm on September 26, 2023: contributor

On Tue, Sep 26, 2023 at 04:52:10AM -0700, Léo Haf wrote:

Secondly, fee estimation requires knowledge of unconfirmed transactions to determine what the next block will likely consist of. Censoring unconfirmed transactions that could be included in blocks makes it harder to estimate fees correctly because you lack information about the true total demand for blockspace.

False, I let you compare these two instances of the mempool software you will see that the fees are rarely incorrect.

https://mempool.space https://orangepill.ovh

At the moment, mempool.space estimates 15sat/vByte to get into the next block; organgepill.ovh estimates 9sat/vByte.

That’s a very significant difference.

Censoring those transactions would simply encourage the development of private mempools - harmful to small miners

You are mistaken about the purpose of this PR, the goal is simply to apply the same restrictions as on OP_RETURN.

You have not refuted my point. I am describing the effect of this pull-req, not commenting on its intended purpose.

As long as miners continue to mine these transactions they will end up in blocks

Probably false, mining pools require exorbitant fees to mine a tx out of the mempool, thus making the “mint” of “BRC-20 tokens” unprofitable. He will therefore stop having demand for that.

Mining pools already mine transactions that do not meet standard mempool requirements: full-rbf. About 30% of hash power is mining full-rbf transactions, and they charge no premium to mine those transactions.

There is zero reason to believe that mining pools would charge exorbitant fees to mine transactions that can be mined by simply not upgrading to the latest Bitcoin Core, and/or setting -datacarriersize=1000000.

luke-jr force-pushed on Sep 28, 2023

DrahtBot removed the label CI failed on Sep 29, 2023

luke-jr force-pushed on Sep 29, 2023

luke-jr commented at 11:44 am on September 29, 2023: member

Review comments addressed, tests from @LarryRuane added, CI passing

DrahtBot added the label CI failed on Oct 7, 2023

DrahtBot removed the label CI failed on Oct 15, 2023

luke-jr referenced this in commit d40375d773 on Oct 19, 2023

luke-jr referenced this in commit 454d917a28 on Oct 19, 2023

luke-jr referenced this in commit d923657ff7 on Oct 19, 2023

luke-jr referenced this in commit 13481dcd70 on Oct 19, 2023

DrahtBot added the label Needs rebase on Oct 29, 2023

LarryRuane commented at 8:03 pm on October 30, 2023: contributor

In case anyone’s wondering about the practical effect of this patch today (obviously, it could be very different in the future), here are some recent transactions that this patch would not have relayed. These are not hand-picked, they’re exactly the first ones I saw after adding debug logging to print them:

Right now, there seems to be roughly 15-25 of these arriving per block.

in test/functional/feature_taproot.py:742 in abd19ad480 outdated

738@@ -739,7 +739,7 @@ def spenders_taproot_active():
739         scripts = [
740             ("pk_codesep", CScript(random_checksig_style(pubs[1]) + bytes([OP_CODESEPARATOR]))),  # codesep after checksig
741             ("codesep_pk", CScript(bytes([OP_CODESEPARATOR]) + random_checksig_style(pubs[1]))),  # codesep before checksig
742-            ("branched_codesep", CScript([random_bytes(random.randrange(2, 511)), OP_DROP, OP_IF, OP_CODESEPARATOR, pubs[0], OP_ELSE, OP_CODESEPARATOR, pubs[1], OP_ENDIF, OP_CHECKSIG])),  # branch dependent codesep
743+            ("branched_codesep", CScript([random_bytes(random.randrange(2, 75)), OP_DROP, OP_IF, OP_CODESEPARATOR, pubs[0], OP_ELSE, OP_CODESEPARATOR, pubs[1], OP_ENDIF, OP_CHECKSIG])),  # branch dependent codesep

jonatack commented at 9:21 pm on October 30, 2023:

Trivial rebase needed following the merge of #28727.

0            ("branched_codesep", CScript([random.randbytes(random.randrange(2, 75)), OP_DROP, OP_IF, OP_CODESEPARATOR, pubs[0], OP_ELSE, OP_CODESEPARATOR, pubs[1], OP_ENDIF, OP_CHECKSIG])),  # branch dependent codesep

Sun0fABeach commented at 10:35 am on November 3, 2023: none

Concept ACK

Node runners need a builtin option to ignore all modern forms of datacarrying so they don’t have to resort to manually patching their nodes.

… and the ‘censorship’ framing is getting old by now and has been rebutted often enough. If you really hold these principles, then please remove all your email spam filters. Otherwise you’re engaging in censorship of a permissionless protocol and thereby impairing an important source of revenue for network users.

Retropex commented at 12:13 pm on November 5, 2023: none

Node runners need a builtin option to ignore all modern forms of datacarrying so they don’t have to resort to manually patching their nodes.

In addition, it is important to note that if developers do not help node runners defend themselves against this attack, they may have to resort to misappropriate means to strengthen their defense. Although the use of a pre-SegWit node is a defense option, it can have harmful consequences for the entire network.

petertodd commented at 8:28 pm on November 13, 2023: contributor

In addition, it is important to note that if developers do not help node runners defend themselves against this attack, they may have to resort to misappropriate means to strengthen their defense.

This pull-req is not a defense. In fact, it does the opposite: with compact blocks, rejecting transactions that are very likely to get mined actually increases bandwidth consumption, in particular, peak bandwidth. You can either incur that cost when the transaction is broadcast. Or later, when the transaction is contained in a block.

Retropex commented at 8:25 am on November 16, 2023: none

Congratulations, what some feared finally happened without us doing anything. @Glozow luke added the tests weeks ago, it is more than time to review this PR, you are in charge of the mempool and it is in a disastrous state with no less than 200,000 spam transactions.

This trend also seems to be accelerating with waves of spam getting closer and closer.

I may repeat myself but these spam transactions make the real usefulness of Bitcoin more and more difficult to use.

We will never resonate with people who want to play gambling and scam other peoples, that’s why we must take the lead.

petertodd commented at 9:11 pm on November 16, 2023: contributor

On Thu, Nov 16, 2023 at 12:25:20AM -0800, Léo Haf wrote:

Congratulations, what some feared finally happened without us doing anything.

@Glozow luke added the tests weeks ago, it is more than time to review this PR, you are in charge of the mempool and it is in a disastrous state with no less than 200,000 spam transactions.

The tweet you link shows how pointless this pull-req is.

ViaBTC is actively mining BRC-20 transactions, ignoring Bitcoin Core policy entirely. They’re certainly getting paid to do so, probably at a small premium to market fee rates.

There is no way miners are going to run code that throws away millions of dollars in fee revenue. All this pull-req could possibly accomplish is make it difficult for smaller miners to make a profit. They don’t have the resources to or hash power required to make side deals with people making BRC-20 transactions, so they rely on mempool propagation to get them their revenue.

Sun0fABeach commented at 9:52 am on November 17, 2023: none

The tweet you link shows how pointless this pull-req is.

I want to be in charge of my mempool policy and I want to decide what is spam and what is not, in a straightforward and easy way. This is a matter of principle and principles are not pointless. I don’t get why you would want to withhold that from node runners, especially since it is completely opt-in and only people who feel strongly about this will choose to do so. (Maybe it’s because you think we need an easy path for ordinals to save ourselves from the ‘security budget problem’, but I don’t want to impute motives here …)

petertodd commented at 7:05 pm on November 17, 2023: contributor

On November 17, 2023 4:52:53 AM EST, Markus @.***> wrote:

The tweet you link shows how pointless this pull-req is.

I want to be in charge of my mempool policy and I want to decide what is spam and what is not, in a straightforward and easy way. This is a matter of principle and principles are not pointless. I don’t get why you would want to withhold that from node runners, especially since it is completely opt-in and only people who feel strongly about this will choose to do so.

This pull-req is not opt-in. It changes the default behavior to block inscription transactions.

Retropex commented at 7:36 pm on November 17, 2023: none

On November 17, 2023 4:52:53 AM EST, Markus @.***> wrote: > The tweet you link shows how pointless this pull-req is. I want to be in charge of my mempool policy and I want to decide what is spam and what is not, in a straightforward and easy way. This is a matter of principle and principles are not pointless. I don’t get why you would want to withhold that from node runners, especially since it is completely opt-in and only people who feel strongly about this will choose to do so. This pull-req is not opt-in. It changes the default behavior to block inscription transactions.

At the height of 80 bytes as agreed years ago with OP_RETURN…

casey commented at 6:53 am on November 30, 2023: contributor

There are a few issues with this PR.

By changing the default, instead of being opt in, it represents a potentially disruptive and unwelcome change in behavior for miners relying on Bitcoin Core to construct block templates.

Over the last ten months, inscription reveal transactions have paid at least $121,386,535 in transaction fees. (Or rasan-titon-vybong, timill-bysanditonra dollars, for those who prefer the tonal number system.)

Miners who use an updated version of Bitcoin Core with this PR would lose that fee revenue, which is substantial, and unexpectedly become uncompetitive relative to other miners, either using an older version of Bitcoin Core, or who change the default -datacarriersize.
Beyond the immediate loss of inscription reveal transaction fee revenue, this would appear to be long-term incentive-incompatible for miners. The total contribution of inscriptions to block rewards is much higher than the above quoted figure, since it doesn’t include commit transactions, subsequent transfers, or ancillary transactions, so miners would probably prefer not to discourage such activity.
This change would prevent the relay of inscription reveal transactions. However, it does not prevent the relay and mining of inscription commit transactions. Thus, if widely adopted, it would effectively lock inscription commit transaction outputs, making it impossible to spend them using their tapscript spend path.

Although sophisticated users could retrieve locked commit transaction outputs either with a key path spend, or by submitting the full reveal transaction directly to a miner who processes nonstandard transactions, unsophisticated users, or those using software that doesn’t support recovering commit transaction outputs with a keypath spend, would find their funds locked.

I think this would represent a mild form of confiscation, and should be avoided.

doc: script: Document that IsUnspendable is incorrect for some witness scripts e5ad067401

script: Add CScript::DatacarrierBytes 8f75e976ca

policy: GetScriptForTransactionInput to figure out P2SH, witness, taproot 59ae065956

Apply -datacarriersize to all datacarrying f2c0396cd4

QA: script_tests: Check GetScriptForTransactionInput and CScript::DataCarrierBytes 4d2ec0671a

luke-jr force-pushed on Dec 5, 2023

DrahtBot removed the label Needs rebase on Dec 5, 2023

DrahtBot added the label CI failed on Dec 6, 2023

Sjors commented at 12:17 pm on December 6, 2023: member

NACK. There’s no universal way to filter all present and future datacarrying styles. This invites an endless cat and mouse game inside very critical code paths.

It seems better if you just keep this patch for Knots, or alternatively, come up with a generic design to filter transactions. E.g. by loading rules from a file in some template language.

Sjors commented at 12:21 pm on December 6, 2023: member

Just to set expectations, I might also NACK such a generic arbitrary filtering system, given the can of worms it would open, but I’d have to think about that more.

petertodd commented at 1:20 pm on December 6, 2023: contributor

I would NACK that as you are creating infrastructure for things like OFAC censorship.

On December 6, 2023 1:21:15 PM GMT+01:00, Sjors Provoost @.***> wrote:

Just to set expectations, I might also NACK such a generic arbitrary filtering system, given the can of worms it would open, but I’d have to think about that more.

luke-jr commented at 4:47 pm on December 6, 2023: member

Hypothetical future issues is not an excuse to stagnate harmfully. You’re making the perfect the enemy of the good.

Sjors commented at 9:23 am on December 7, 2023: member

This does not meet the bar for “good”. If only Ocean pool uses this and it remains a relatively small pool, it will have no effect. If it is widely deployed, it’s trivial to circumvent, which will cause this code to grow in complexity. And every time that happens there’ll be a lot of pressure on maintainers to push it through quickly “to stop the spam”. It’s just a matter of time before some DoS vector accidentally makes it in.

For example you’re currently looking for this pattern, used for inscriptions:

0OP_FALSE OP_IF spam OP_ENDIF

This pattern fits about 1000 data pushes with each a max of 520 bytes, so 520 KB, per output.

If this PR were widely deployed, the pattern could be changed as follows:

0OP_TRUE OP_IF spam OP_2DROP … OP_2DROP

So the “spammers” now need to use up to 500 OP_2DROP codes so the stack is empty again, reducing the capacity to 515 KB. This time the code is actually executed by nodes, which is (slightly?) worse.

Next move?

Retropex commented at 10:41 am on December 7, 2023: none

Next move?

Standardize the new spam method.

sgs2018 commented at 12:27 pm on December 7, 2023: none

maybe is hard to define spam , it is very fuzzy .

Retropex commented at 1:00 pm on December 7, 2023: none

The problem is that they use a diverted means to include data instead of using OP_RETURN which has been more or less adapted for this, in particular by not bloating the UTXOs set, that they have an unfair fee reduction compared to OP_RETURN and that they unbalance the incentives of miners.

Miners could, for example, start creating this kind of tx (BRC-20) to get richer than it will by mining normal financial txs.

petertodd commented at 2:44 pm on December 7, 2023: contributor

To be clear, OP_Return outputs are not added to the UTXO set. That’s why we standardized OP_Return in the first place.

On December 7, 2023 2:00:19 PM GMT+01:00, “Léo Haf” @.***> wrote:

The problem is that they use a diverted means to include data instead of using OP_RETURN which has been more or less adapted for this, in particular by not bloating the UTXOs set, that they have an unfair fee reduction compared to OP_RETURN and that they unbalance the incentives of miners.

Miners could, for example, start creating this kind of tx (BRC-20) to get richer than it will by mining normal financial txs.

Sjors commented at 2:47 pm on December 7, 2023: member

Next move?

Standardize the new spam method.

I assume you meant “make the new spam method non-standard”. That’s exactly the whack-a-mole game I’d like to avoid in this part of the code base. Bitcoin Core release cycles are also much too slow to keep up with such a game.

The current situation is very different from when OP_RETURN with 80 bytes was standardized. At the time that was a way to discourage the alternative approach of bare multisig, by creating an incentive to use this slightly cheaper and less harmful approach.

The approach in this PR does not create an incentive to use a slightly less harmful method to post “spam”. Rather, it encourages finding ever more creative and potentially more harmful ways to avoid the filter.

Retropex commented at 9:54 pm on December 7, 2023: none

I understand your argument.

However, now OP_RETURN, baremultisig, and other flaws such as OP_0 OP_IF, are used to spam the chain. So what do you think we should do? Let them spam the chain by what we can’t give them a toy on which to spam?

1440000bytes commented at 10:42 pm on December 7, 2023: none

Approach NACK

DatacarrierBytes() will need an update every few weeks as explained by @Sjors in #28408 (comment) and could affect some other use cases.
datacarriersize is used for OP_RETURN and should not be mixed with other things. We should remove default limits for OP_RETURN because it does not affect UTXO set and there is no witness discount involved.
I do not see any issues with inscriptions. Neither they are spam nor an attack. Casey figured out a smart way to use bitcoin for this use case. It has lot of demand and ~2000 BTC has been paid in fees by inscription users. Let people use their money in a different way that is valid under present consensus rules.
There will always be a way to add JSON, JPEG etc. in transaction data and any controversies around them are free marketing. Humans have been writing and drawing things on money since decades and they will continue to do so.
Such workarounds to kill certain use case leads to worse things like OFAC compliance, private mempools, out of band payments to pools etc.

petertodd commented at 12:07 pm on December 8, 2023: contributor

Worth noting that the vast majority of inscriptions are tiny, BRC-20 tokens, with ~50 bytes of data: https://ordiscan.com/inscriptions

The data in this use-case isn’t actually significant. Typically ~50WU out of a ~600WU transaction. Even if BRC-20 and similar tokens modify the protocol to not actually put any data in the Bitcoin chain, they still would drive fees up significantly due to the transactions themselves.

luke-jr commented at 3:58 am on December 10, 2023: member

The vulnerability this fixes has been assigned CVE-2023-50428

conduition commented at 5:48 am on December 10, 2023: none

Concept NACK

I personally have no use for on-chain ordinals or inscriptions. I think everyone would be better off if these were moved to some off-chain or side-chain protocol. However I can’t rightly label the inscriptions as ‘spam’, nor would I dub their exclusion from the mempool ‘censorship’. The distinction between ‘censorship’ and ‘spam filtering’ is entirely subjective.

If i publish a chain of 1000 transactions pointlessly bouncing coins around my own wallet addresses, is that spam? What about a single big (in terms of weight) transaction which only pays from myself to myself? The whole BTC network (including myself) would be better off if i didn’t do that. I’m needlessly inflating the fee market for zero utility. In my humble opinion, inscriptions are similarly redundant because they could be done off-chain, so their on-chain utility to the network is near zero as well.

If people want to donate money to miners by uploading pointless ‘spam’ data to the blockchain, they will always be able to find ways of doing that. I think @1440000bytes hit the nail on the head with this.

There will always be a way to add JSON, JPEG etc. in transaction data and any controversies around them are free marketing. Humans have been writing and drawing things on money since decades and they will continue to do so.

I agree with @Sjors that entering into a whack-a-mole game is a bad choice operationally, even if the driving motivation behind fixing the bug (and it is a bug) is sound. As much as I may personally dislike it, people are demonstrating a willingness to pay for on-chain inscription/data-push functionality. If we patch this method of inscribing, someone will come up with another.

darosior commented at 11:21 am on December 10, 2023: member

Concept NACK.

glozow luke added the tests weeks ago, it is more than time to review this PR, you are in charge of the mempool and it is in a disastrous state with no less than 200,000 spam transactions. @Retropex stop using this type of language. Nobody has to answer to you or anybody about how people are using this software or the Bitcoin network. Your past contributions to this forum gives me little hope you’d succeed but i would urge you to think twice before posting: your comments are not only stupid but they could also turn out to be harmful.

eragmus commented at 1:24 pm on December 10, 2023: none

Concept NACK.

So, we come back to what was originally and consistently advised, based on the free-market principles that fundamentally underly Bitcoin’s incentives: The “solution” to inscriptions txs is to price them out with non-inscriptions txs. This is a natural process that happens over time, and has at least 2 dimensions:

Inscriptions txs (that are willing to pay a high enough fee to have higher priority confirmation) decrease over time, as demand falls, as their novelty wears off. Or, maybe the novelty never wears off, but that is also fine, see (2).
Non-inscriptions txs (that are willing to pay a high enough fee to have higher priority confirmation) increase over time, as demand rises, as Bitcoin awareness and adoption and demand to use layer 1 rise.

In case it needs reminding, low-fee txs of any kind are not designed for layer 1, for decentralization-consistent reasons (accessibility of mining nodes and non-mining nodes decreases, as layer 1 capacity is increased to allow low-fee txs to have a high enough priority to escape the mempool and get mined).

If the issue is that not even layer 2s (like LN) currently scale well enough for the low-fee txs (seen by required layer 1 fee being too high, implying not enough blockspace supply and too much blockspace demand), the solution is not to try to forcefully decrease layer 1 demand/supply. This would be a high-time-preference behavior and a fool’s errand, since the free market will still find a way to express that demand/supply, and also the “solution” employed may be worse for bitcoin than the original problem by creating new and worse problems.

The solution is instead multi-fold:

Decrease layer 1 demand by communicating and collaborating with relevant parties to increase efficiency (getting same/better result with fewer resources through better software design) of layer 1 inscriptions txs + to increase efficiency of layer 1 LN txs (e.g. through advancing proposals like CTV).
Increase layer 1 supply in a decentralization-consistent manner, such as extension blocks… and/or if the community has overcome its bcash PTSD yet, then through a well-thought-out block size increase (as used to be the plan before the proto-bcashers chose to forcefully demand big changes and poisoned the well). There is also BitVM on layer 1, which apparently can enable Drivechain, which can then enable greater capacity via 2wp sidechains – all this without any forks, thanks to BitVM.
Increase layer 2 options. Discuss enabling covenants or whatever is needed for Ark to work properly.

douglaz commented at 9:12 pm on December 10, 2023: none

Concept NACK.

This is an attempt to increase transaction censorship under the guise of a bugfix.

Retropex commented at 10:02 pm on December 10, 2023: none

This is an attempt to increase transaction censorship under the guise of a bugfix.

Bitcoin Core already standardizes the insertion of arbitrary data above 83 bytes and inscriptions are a diverted way to bypass this limit so it is a bug fix.

aviv57 commented at 10:22 pm on December 10, 2023: none

Concept NACK.

I think ordinals and inscriptions will make a lot of people invest in shit jpegs.

But the way to stop people from encoding arbitrary data on the chain is not by adding censorship.

It’s by waiting for it to be much more expensive to do it on bitcoin than doing it on other networks / centralized services

hmisty commented at 2:53 am on December 11, 2023: none

Concept ACK.

Makes sense to consider the way inserting data as a trick and abuse of the taproot script.

hmisty commented at 3:20 am on December 11, 2023: none

Concept ACK.

Makes sense to consider the way inserting data as a trick and abuse of the taproot script.

Since the obfuscated data in the script are neither verified nor enforced by the consensus, and these data are to any extent eventually rely on off-chain indexers to proceed, a more elegant way could be to move all data out of the chain for the off-chain indexers to store and deal with, while leaving only a hash on chain which fits well into the design intent with minimal on-chain footprint.

mmgen commented at 4:04 am on December 11, 2023: none

Concept NACK. The ordinals transactions will end up in the blockchain anyway, bypassing the mempool, so this PR does nothing to solve/mitigate the problem of blockchain spam.

And as Peter Todd noted, block propagation will be adversely impacted, as regular nodes will be seeing the ordinals TXs only when a block is announced.

droptpackets commented at 5:50 am on December 11, 2023: none

Attempting to report the underlying functionality that has lead to Ordinals as a ‘vulnerability’ via NIST (https://nvd.nist.gov/vuln/detail/CVE-2023-50428), when it is clearly not a vulnerability by any definition, is in bad faith.

I find it ironic that a body that claims censorship resistance is pivotal to blockchain (and Bitcoin) is:

Attempting to define chain behavior and transaction censorship of their own accord and against the wishes of many of those utilizing the chain.
Are providing misleading information on a government platform and attempting to paint this as some sort of vulnerability when it is clearly not.

At worst, one could argue that this is a bug that has become a feature.

As software engineers know, many times software may have behavior that was not necessarily intended by the developer, but the end user leverages the behavior to build their own tooling and process around it. Future changes to the product must include the end users’ utilization of the programs functionality in mind and should not change “just because” one feels it could be designed differently. This is the same thing that has happened here with inscriptions / ordinals.

Given the value that there is with provenance and on-chain data, I will note that many who originally were on Ethereum have now migrated to Bitcoin because the data is truly on-chain vs other methods on Ethereum that utilized pointing to IPFS or other off-chain mechanisms to store data. Bitcoin has a chance to truly and uniquely position this functionality for future adoption in mainstream and should not simply kill it because it falls outside of the original payments design of the platform.

It is ok to debate around if this functionality is good or bad, but lets have an honest conversation instead of trying to dictate the terms of the debate to try to strong arm a conclusion.

We are all, after all, pro decentralization at the end of the day, are we not?

Sources, especially for those not native to the conversation above: Docs.ordinals explains underlying concept: https://docs.ordinals.com/inscriptions.html Bitgo briefly explains changes to segregated witness soft fork and taproot soft fork: https://blog.bitgo.com/the-rise-of-ordinal-inscriptions-dbe7cb0336c6

Edit to remove unnecessary text/update phrasing to focus on the core issues at hand.

douglaz commented at 3:12 pm on December 11, 2023: none

Concept ACK. Makes sense to consider the way inserting data as a trick and abuse of the taproot script.

Since the obfuscated data in the script are neither verified nor enforced by the consensus, and these data are to any extent eventually rely on off-chain indexers to proceed, a more elegant way could be to move all data out of the chain for the off-chain indexers to store and deal with, while leaving only a hash on chain which fits well into the design intent with minimal on-chain footprint.

It’s not up to us to tell how people should use bitcoin. If you think your design is more “elegant” then do it and let the free market decide which one is better.

Sun0fABeach commented at 4:09 pm on December 11, 2023: none

The shipcoiners have truly arrived, as evidenced by this thread. Thanks, bitcoin core. Unbelievable.

Retropex commented at 4:58 pm on December 11, 2023: none

Well, since people have come to protect their scams business and Core refuses to give the tool to the nodes runners to guard against it, know that @luke-jr maintains a fork of bitcoin core that has already integrated this patch.

Here is the link for Bitcoin Knot.

If you want to stay on bitcoin core, applying a simple patch is enough to get rid of inscription in your mempool.

If you do not know how to apply the patch I take care of applying the patch to each release of Bitcoin Core on my fork.

Also, ready-to-use binaries are available on @BcnBitcoinOnly and also on my fork for the latests versions.

eragmus commented at 5:25 pm on December 11, 2023: none

The shipcoiners have truly arrived, as evidenced by this thread. Thanks, bitcoin core. Unbelievable.

Ad hominem, the second lowest level of disagreement. Better to level up & address the actual arguments being made.

Retropex commented at 6:10 pm on December 11, 2023: none

If you can’t see yourself that the thousands of tokens created with the inscriptions are scams I really can’t do anything for you, for the images it’s the same, inscribe ten times the same things with a slight declination and then move on to something else when people are no longer interested. This cycle continues indefinitely.

eragmus commented at 6:32 pm on December 11, 2023: none

If you can’t see yourself that the thousands of tokens created with the inscriptions are scams I really can’t do anything for you, for the images it’s the same, inscribe ten times the same things with a slight declination and then move on to something else when people are no longer interested. This cycle continues indefinitely.

People lose their money by voluntarily choosing to gamble in the casino (the house always wins), so do we ban casinos? We don’t, not in the US at least. Inscriptions are basically people voluntarily choosing to gamble to try to make more money. They could choose to gamble by actively trading bitcoin (and lose longterm as 95-99% do), like others do, but they instead want to gamble with inscriptions. (FYI: I never gamble, have zero interest in it.)

People also use their bitcoin for other distasteful things: making terrorist payments, for the abhorrent practice of CP, and certainly even for money laundering. The establishment power structure including MSM trumpet such things as an argument to try to ban bitcoin, or force miners to act to stop such transactions.

In both cases, the basic Bitcoin principles are important to remember: Bitcoin is a decentralized permissionless network + censorship-resistance of txs is a core characteristic. – What this basically means is anyone can use their bitcoin in whichever manner they desire, regardless how distasteful (for any reason) the use case, and no single entity can do anything to prevent it. – And there are incentives designed into the bitcoin system to also reduce the chance of succeeding (e.g. miners can leave a country, as miners did from China a couple years ago after China cracked down).

If we can agree on this, and not cite distasteful usage (gambling/scams/terrorists/CP/moneylaundering/etc.) as a motivation to target certain transactions, then we (plural, collectively) can move on to other aspects of this controversy that motivate people… such as “layer 1 tx fees are getting too high because of inscriptions txs” and other arguments.

Retropex commented at 6:47 pm on December 11, 2023: none

People lose their money by voluntarily choosing to gamble in the casino

It’s true, but going to a casino does not oblige the entire planet to have an indelible mark of fact that you went to a casino. Inscriptions do.

People also use their bitcoin for other distasteful things

Yes and it doesn’t bother me because they are financial txs.

Bitcoin is a decentralized permissionless network

Indeed, therefore, nodes runners have the right to have options to protect themselves from this attack.

eragmus commented at 10:14 pm on December 11, 2023: none

going to a casino does not oblige the entire planet to have an indelible mark of fact that you went to a casino. Inscriptions do.

The thing is that inscriptions were not simply possible and begun to be used only when Casey released his software. The concept of inserting arbitrary data was already possible, and thus done, throughout bitcoin’s history (this means your node already had arbitrary data, including various distasteful data). You can do a simple google search and see research papers written analyzing bitcoin’s arbitrary data, before Casey’s software.

What this means is whatever you think you’re supporting to solve this issue is not in fact solving it. Or if it solves it in one way, they will use another way to do it anyway. And that other way may increase the UTXO set, while otherwise it would not. Others have already pointed out this criticism many times in this thread (as did I in my first thread response in the last couple days).

Fighting this is a losing battle, if doing so via code, since bitcoin is designed as a neutral (non-biased) network.

A better idea is to take this effort to the social layer (religion/culture/etc.) to educate people that “gambling is bad for your health” or political layer (jail gamblers? lol), and so try to get people to stop doing it.

People also use their bitcoin for other distasteful things

Yes and it doesn’t bother me because they are financial txs.

So your issue is not actually that inscriptions txs enable gambling (falls in the category of distasteful activity), but that these inscriptions txs are not financial txs?

Bitcoin is a decentralized permissionless network

Indeed, therefore, nodes runners have the right to have options to protect themselves from this attack.

“Decentralized” in this context means the default software is not obligated to accept the approach advocated by a certain group, if it means ignoring criticisms offered by other groups, in other words if a proposal is contentious. Individual node runners, who want to ignore the criticisms of other groups, can certainly make their own choice though, such as via forking (Knots).

“Attack” is an inflammatory word to describe people using Bitcoin and paying a bitcoin tx fee to make a type of tx that you do not like. One could choose to describe as an “attack” people using ineffective coinjoin software to make many txs that pay tx fees, for example. It’s subjective, just like “immoral” txs is subjective (gambling inscriptions txs vs. terrorism non-inscriptions txs).

“Permissionless” in this context means that because tx fees are being paid, it is not an “attack” as far as Bitcoin’s design is concerned (tx fee is the anti-DoS mechanism, nothing else, since inherently it is a censorship-resistant network that allows any valid tx). This design also means you have the option to outbid the “spam attack”.

We went through this before 2018, or before 2017, when bigblockers were “attacking” the network with useless non-inscriptions txs, and the only real remedy was to outbid it. The reason this works is because the offending source has limited funds to spend on tx fees. This applied to bigblockers, and this also applies to gamblers (most inscriptions txs afaik).

Out-bidding is one approach to handle higher layer 1 tx fees, but there are other approaches too, which I listed in my first thread comment (improving layer 1 LN txs efficiency via CTV fork for example, covenants fork which iirc is needed for layer 2 LN-alternative Ark to work properly, increasing efficiency of inscriptions txs to use less bytes, extension block fork, a non-contentious block size increase fork based on global median compute / storage / bandwidth / etc., permissionless BitVM sidechains, other permissionless BitVM possibilities, etc.).

conduition commented at 6:15 am on December 12, 2023: none

Yes and it doesn’t bother me because they are financial txs. @Retropex Can I ask your opinion on a hypothetical? I want to understand your perspective by revisiting a scenario i posed earlier.

If i publish a chain of 1000 transactions pointlessly bouncing coins around my own wallet addresses, is that spam? What about a single big (in terms of weight) transaction which only pays from myself to myself? The whole BTC network (including myself) would be better off if i didn’t do that. I’m needlessly inflating the fee market for zero utility. In my humble opinion, inscriptions are similarly redundant because they could be done off-chain, so their on-chain utility to the network is near zero as well.

Consider a two possibilities. Flip a coin, and my wallet will either:

Broadcast a 50 kilobyte inscription reveal transaction.
Broadcast a 50 kilobyte transaction spending a 1-of-1500 P2WSH OP_CHECKMULTISIG output.

Today, any wallet with the funds to do so can create either kind of transaction.
Both scenarios encumber the mempool with the same total weight at the same fee rate.
Both have identical effects on the UTXO set.
If mined, both add an equally ‘indelible mark’, as you put it, to the blockchain permanently.
Both are unusual but consensus-valid transactions.

What distinguishes these two kinds of transactions in your mind?

mmgen commented at 6:39 am on December 12, 2023: none

The Bitcoin whitepaper is embedded in the blockchain in a transaction with 946 1-satoshi multisig outputs.

As @conduition pointed out, there’s nothing to prevent any arbitrary data from being embedded in this way, and in other ways this PR doesn’t address.

And at the risk of belaboring the obvious, I’ll repeat: any mempool-based approach to filtering transactions is futile, because transactions don’t require the mempool to get into a block. The new restrictions will be trivially routed around, and it’s back to square one.

petertodd commented at 8:13 am on December 12, 2023: contributor

On Mon, Dec 11, 2023 at 10:39:42PM -0800, The MMGen Project wrote:

The Bitcoin whitepaper is embedded in the blockchain in a transaction with 946 1-satoshi multisig outputs.

What’s to prevent any arbitrary data from being embedded in this way, and in other ways this PR doesn’t address?

It doesn’t even stop https://github.com/petertodd/python-bitcoinlib/blob/master/examples/publish-text.py, which I wrote in 2015.

Retropex commented at 11:27 am on December 12, 2023: none

@conduition is very relevant as a question.

What fundamentally bothers me with inscriptions is that they do not play the same game as those who make financial transactions.

When you pay to send 10,000 times the same funds to the same wallet, you pay to move Bitcoin from one address to another and even if it’s “useless” it doesn’t bother me because there is no incentive to do that.

On the other hand, inscriptions have an incentive that is external to the Bitcoin protocol, it does not pay to move Bitcoins but to benefit from something else. To better understand what I’m trying to say here is an excellent thread that will probably explain it better than me.

1ma commented at 11:43 am on December 12, 2023: none

If i publish a chain of 1000 transactions pointlessly bouncing coins around my own wallet addresses, is that spam? What about a single big (in terms of weight) transaction which only pays from myself to myself? The whole BTC network (including myself) would be better off if i didn’t do that. I’m needlessly inflating the fee market for zero utility. In my humble opinion, inscriptions are similarly redundant because they could be done off-chain, so their on-chain utility to the network is near zero as well.

Not all spam TXs are the same, but inscriptions certainly are. Sweep transactions moving 1 UTXO from one address to the next do it while trying to economize as much as possible on the fee. They treat sats as money and try to conserve them, therefore they are financial TXs. Same for coinjoin TXs, though some people argue that they aren’t financial TXs they also transfer sats trying to economize on the fee as much as possible. All financial TXs have this general look:

F_8UsHPX0AAgsIc

On the other hand, inscription spam TXs aren’t financial. They don’t treat sats as money, just as some sort of token to pay for the service they’re interested in: inscribing random bytes on the blockchain. These TXs typically spend one output that is just large enough to cover the fees for inscribing the desired data, so 95-98% of the value “transfered” is typically lost as fees:

F_8UyN4WgAAC8hq

When the mempool is clogged with this kind of TXs, users trying to use Bitcoin as money are priced out in droves, because they can’t pay 98% of their UTXOs in fees, so they can only compete by moving orders of magnitude more value than inscriptions. Therefore when inscriptions are setting the floor at $10, they’re not just pricing out people trying to transact $10 onchain, but also $20, $50, $100.. maybe up to $500. This is a huge externality imposed on transactors trying to use the system as intented, and everyone who uses Bitcoin to transact sats has seen and felt it first-hand for much of 2023.

GBIT02LaIAAB8I4

The original Satoshi client didn’t allow embedding data onchain, this has always been an exploit. However I think that Taproot may have opened the door to mitigate this forever.

My understanding is that Schnorr signatures allow stamping data at “zero footprint”, by hiding a hash inside the signature as if it were some sort of steganography technique.

My current view is that in the long term the default mempool policy in Bitcoin Core should be adapted to unstandardize and impose huge fees on all forms of data carrying envelopes to nudge these usages to zero footprint stamping via Schnorr signatures.

petertodd commented at 12:10 pm on December 12, 2023: contributor

The original Satoshi client didn’t allow embedding data onchain, this has always been an exploit.

Bitcoin was released with no standardness rules at all. You absolutely could embed data onchain. You could even publish arbitrary data to the UTXO set easily.

1ma commented at 4:49 pm on December 12, 2023: none

The original Satoshi client didn’t allow embedding data onchain, this has always been an exploit.

Bitcoin was released with no standardness rules at all. You absolutely could embed data onchain. You could even publish arbitrary data to the UTXO set easily.

That was poor wording, but was precisely my point.

Satoshi designed OP_RETURN as a mechanism to prove that some sats were provably unspendable. Then it turned out that the Bitcoin interpreter was too lax and the OP_RETURN opcode could be used to embed random bytes after it (an exploit), and thus spam filters were deployed to mitigate it.

But that’s just a very minor point to argue about. What’s relevant from the previous message is that it proves that inscription spam prices out the intended users of the system very cheaply (i.e. the fee market is broken). And that Schnorr signatures seems to have introduced the possibility of zero footprint data inscription, so mempool policy should eventually nudge very sternly data inscribers towards this option (i.e. unstandardize and jack up the fees for all data carrier envelopes seen in the wild).

And this PR lays the initial foundation for treating all datacarrier opcode sequences the same, so Concept ACK from my end.

eragmus commented at 6:04 pm on December 12, 2023: none

When the mempool is clogged with this kind of TXs, users trying to use Bitcoin as money are priced out in droves, because they can’t pay 98% of their UTXOs in fees, so they can only compete by moving orders of magnitude more value than inscriptions. Therefore when inscriptions are setting the floor at $10, they’re not just pricing out people trying to transact $10 onchain, but also $20, $50, $100.. maybe up to $500.

I think the linked X thread’s analysis and your analysis are both wrong. What is relevant is not fee as a proportion of total value sent (which is just a way to express dislike for txs that don’t conform to one’s desire for “proper” txs), or even fee alone. What is relevant is the fee rate. This information was excluded from the thread’s screenshots.

I found similar txs, both in the same block, and this time did not exclude info to paint a misleading narrative.

Inscription tx:

$0.23 value transferred (doesn’t include the inscription’s value itself)
$6.45 fee
Fee rate: 104 sat/vB (optimal)

Non-Inscription tx:

$2,315 value transferred
$18.67 fee
Fee rate: 184 sat/vB (overpaid 2x) –> optimal fee rate = 92 sat/vB

But yes, the presence of inscription txs adds demand and thus competition for precious block space. That’s actually the good aspect, since say in the year prior to popularization of inscription txs, it was a network literally relying on subsidy to pay miners – blocks weren’t full, 1 sat/vB fee rate was common, fee-to-subsidy ratio was very low. In short, it was an unsustainable network, which was disappointing for something 13 years old.

And no, bitcoin price cannot be relied upon to offset the exponentially-declining subsidy every 4 years, as that is not a conservative approach to security.

We also can’t rely on hopium (vs. evidence) that monetary txs like traditional SoV/MoE will be 100% enough to fill blocks to raise fee rate to an adequate level:

SoV txs are by nature infrequent
Layer 1 MoE txs are also infrequent because must be higher-value MoE txs for fee to be economical + because MoE with bitcoin is fundamentally not attractive: bitcoin’s price volatility, taxes on capital gains and so needing to track and record all txs and calculate gains and do so despite using coinjoin if someone wants tx privacy, lack of consumer protection with reversible transactions, lack of seller adoption compared with credit cards and cash, etc.

This is why there is excitement (not a “psyop”), now that organic free market activity (and not in a bull market, as is usually the case when it happens) is finally producing sustained fees (over 10 months) and thus some meaningful security for the Bitcoin network, and this too only from primitive ordinal inscription infrastructure and early use cases.

Why fees were cheered, even 6 years ago:

The fee rate level is relevant for individual txs, but security of bitcoin is usually considered in aggregate in terms of total fees-to-subsidy ratio (in an average block in a fixed time period), commonly known as the security budget at least as I interpret it.

I’ve speculated that an additional approach to security budget is to examine fees-to-marketcap as a percentage, since security need of bitcoin could be logically considered to be based on how much monetary value is being secured: if $800 billion market cap, and if we say 1% makes sense (idk which % would be ideal, maybe it needs more study to figure out, if even it’s possible to figure out) as the security budget for paying miners, this means $8 billion/year needs to go to miners in fees (based on napkin math, this equals about $25,000 bitcoin price, based on only assuming 6.25 bitcoin subsidy pays for it without fee contribution, luckily subsidy is still high enough + price is also high enough). If market cap rises to $8 trillion, then 1% is $80 billion in fees to miners ($500,000 bitcoin price if only 3.125 bitcoin subsidy pays for it). Just some examples to show the variables involved.

Imagine brains being put to work to really think deeply about what is possible, not just with gambling use case (uninteresting to me, except for the fees generated that improve bitcoin’s “security budget” for lack of a better term), but as the mental block is removed that treats it as an attack, and thus only can see the “cons column” and doesn’t look at the “pros column”, then also with non-gambling use cases…

Example:

https://lnscribe.xyz

https://x.com/polyd_/status/1732456810685083938

1ma commented at 6:16 pm on December 12, 2023: none

When the mempool is clogged with this kind of TXs, users trying to use Bitcoin as money are priced out in droves, because they can’t pay 98% of their UTXOs in fees, so they can only compete by moving orders of magnitude more value than inscriptions. Therefore when inscriptions are setting the floor at $10, they’re not just pricing out people trying to transact $10 onchain, but also $20, $50, $100.. maybe up to $500.

I think the linked X thread’s analysis and your analysis are both wrong. What is relevant is not fee as a proportion of total value sent (which is just a way to express dislike for txs that don’t conform to one’s desire for “proper” txs), or even fee alone. What is relevant is the fee rate. This information was excluded from the thread’s screenshots.

I found similar txs, both in the same block, and this time did not exclude info to paint a misleading narrative.

The fee rate was left out of the screenshots because it’s not relevant to the analysis, but your example proves it’s right all the same.

That inscription is spending an $6.68 UTXO, and the transactor is spending a combined value of $2315. Both are equally competitive in the currently broken fee market (because they were included in the same block) despite the 2 orders of magnitude of difference between their values. So mostly every other transactor between ~$6.68 and ~$2315 is priced out by ~$7 inscriptions.

Again, because they cannot compete with a 96.55% fee ($6.45/$6.68), they can only compete by moving two orders of magnitude more value than the inscriptions setting the floor.

eragmus commented at 6:58 pm on December 12, 2023: none

The fee rate was left out of the screenshots because it’s not relevant to the analysis, but your example proves it’s right all the same.

That inscription is spending an $6.68 UTXO, and the transactor is spending a combined value of $2315. Both are equally competitive in the currently broken fee market (because they were included in the same block) despite the 2 orders of magnitude of difference between their values. So mostly every other transactor between ~$6.68 and ~$2315 is priced out by ~$7 inscriptions.

Again, because they cannot compete with a 96.55% fee ($6.45/$6.68), they can only compete by moving two orders of magnitude more value than the inscriptions setting the floor.

Okay, thanks for clarifying, now I understand the precise point being argued.

The non-inscription tx I cited has a fee % of 0.8%. I don’t know what fee % people are willing to pay to make a layer 1 bitcoin tx, but for example digital payments via centralized credit card infrastructure charge about 3% total afaik (to buyer, and to seller who passes cost to buyer). Now, expecting a decentralized expensive PoW network to be competitive with a centralized network in fee % is not fair, but, even if we do this unfair comparison: 2,315 / (3/0.8) = $617*. It means $617 could be seen as a reasonable amount of value to transfer, for a 3% fee to make sense.
Layer 2 networks like LN exist for smaller transfers of value that are not economical on layer 1. For example, if every other transaction value between ~$7 and ~$617* is priced out by ~$7 inscriptions on layer 1, then users should transfer value in the range of $7-617, actually between $0-617, via LN instead.
I don’t know if this is true yet, but just to cover the bases: if even layer 2 LN txs are starting to get expensive (due to cost of layer 1 txs) and not be cost-effective, then it makes sense to advocate for improving LN’s efficiency. Maybe LN protocol can be improved in some way without a soft fork, or maybe improvement requires a soft fork like CTV for example for channel factories iirc.
If LN is not able to be improved, if it is not as effective as expected, then alternative layer 2 networks should be explored: these days, Ark is getting attention. It needs a covenant soft fork iiuc, and from what I read from people involved, it can at least increase scale by 16x – unless I’m remembering LN scale improvement, but the point is the same: we can scale Bitcoin txs non-custodially via layer 2 networks, and that requires a soft fork, which is where energy and attention should be directed to achieve tangible improvements. – The answer is not to expect low-value txs on layer 1 to be economical (I gave an in-depth explanation of why fees are extremely important for Bitcoin’s security, in my last reply).
As mentioned in a reply some replies back, there are actually layer 1 scaling options too, but we really need to think about whether fees will be negatively impacted (or whether fees will remain because demand will expand to rise to the same fee level, as supply is increased on layer 1, at least to some extent?), since we don’t have consistently jam-packed blocks of high-fee rate transactions. So, it’s likely better to focus on improving layer 2 networks’ efficiency via a soft fork (imagine minimum 16x scale improvement), before focusing on layer 1 scaling (that in some, or all, cases comes with the extra cost of reducing accessibility of mining nodes and non-mining nodes).

1ma commented at 7:27 pm on December 12, 2023: none

The exact threshold at which the TX fee “perverts” is a red herring, IMO.

If all TXs in the mempool are trying to move sats while economizing the fee as much as possible the free market just finds the % at which transactors are willing to transact, be it 0.8%, or 3% or whatever.

The problem arises when you allow in the same market a new kind of TX interested in another use case which doesn’t mind straight up paying >95% of fees, because they’re doing something else that is not transacting while conserving as many sats as possible. They quickly displace the incumbents as an invasive species, as we’ve seen in 2023.

LN channel opening and closing TXs are also economical in that they try to move as many sats as possible while economizing the fee, therefore they’re also vulnerable to the spam. E.g. $10k channel closures would be hit very hard by $1000 inscriptions.

petertodd commented at 8:18 pm on December 12, 2023: contributor

On December 12, 2023 5:49:19 PM GMT+01:00, Unhosted Marcellus @.***> wrote:

The original Satoshi client didn’t allow embedding data onchain, this has always been an exploit.

Bitcoin was released with no standardness rules at all. You absolutely could embed data onchain. You could even publish arbitrary data to the UTXO set easily.

That was poor wording, but was precisely my point.

Satoshi introduced OP_RETURN as a mechanism to prove that some sats were provably unspendable.

Nope. I’m the one who introduced that OP_Return mechanism, and I introduced it as the same time as the data functionality.

luke-jr commented at 11:42 pm on December 12, 2023: member

Can you move the off-topic chatter somewhere else? This PR is strictly a bugfix for existing functionality. Whether you agree or disagree with that functionality is irrelevant.

P.S. OP_RETURN was originally for sending coins to miners

0xakihiko commented at 6:23 am on December 13, 2023: none

Can you move the off-topic chatter somewhere else? This PR is strictly a bugfix for existing functionality. Whether you agree or disagree with that functionality is irrelevant.

P.S. OP_RETURN was originally for sending coins to miners

Because that’s how we fix bugs. One line commits, broken test cases, broken ecosystems and a totalitarian view of discussions.

I recommend coming up with a novel solution to this problem instead of your easily worked around hack.

conduition commented at 7:51 am on December 13, 2023: none

What fundamentally bothers me with inscriptions is that they do not play the same game as those who make financial transactions.

Thanks for that explanation @Retropex. I like the chess club analogy linked in that thread, it feels very appropriate.

So - not to generalize this to everyone supporting this PR - the driving motivation here isn’t to prevent all spam, but to prevent a particular flavor of transaction, which people have an extrinsic (i.e. non-payment) incentive to perform?

I understand your perspective there, but in this case I think it’s futile. Next year, social trends could popularize an entirely new flavor of spam. One could even rebrand this same flavor of spam in a new packaging to bypass Luke’s datacarriersize detection in this PR.

conduition commented at 7:52 am on December 13, 2023: none

I’d like to demonstrate why it is wildly impractical to even detect arbitrary data push transactions, let alone filter them reliably.

A subtle workaround to this PR:

Encrypt the push-data/inscription
Format the ciphertext as hashes, pubkeys, and op-code sequences.
Encode those hashes, pubkeys, etc into a valid-looking script pubkey.
Use that script pubkey as the inscription envelope.
Publish the decryption key after the ciphertext is already included in a block.
Observers can identify, decode, and decrypt the inscription.

The witness script envelope containing the ciphertext is not analytically distinguishable from a normal bitcoin script, until the decryption key is revealed later. Maybe you could use heuristics, like “having too big of a witness” or “fulfilling a certain scripting pattern” to identify such inscriptions, but you’re going to end up with lots of false positives/negatives, and there will always be other workarounds to bypass such heuristics.

https://conduition.io/bitcoin/inviscriptions/

petertodd commented at 8:16 am on December 13, 2023: contributor

@luke-jr

Can you move the off-topic chatter somewhere else? This PR is strictly a bugfix for existing functionality. Whether you agree or disagree with that functionality is irrelevant.

There is not consensus that this PR is a bugfix. Thus all this discussion is relevant.

P.S. OP_RETURN was originally for sending coins to miners

You are refering to speculative discussion. As you know, OP_Return’s functionality was hastily changed by Satoshi to fix a serious exploit. There’s nothing intentional about that.

The actual use of it in Bitcoin Core when consensus code was added was to enable it to create provably unspendable outputs, for both proof-of-burn and data embedment.

1ma commented at 10:21 am on December 13, 2023: none

@conduition thanks for writing that article, it’s a very interesting read but I still feel we are not on the same page yet.

The point of “fighting the spam TXs” is not to prevent all forms of data inscription at all costs, it’s to fix Bitcoin’s fee market. The crux of the problem as described here and here is that inscriptions dramatically overpay fees by design and thus price out large segments of Bitcoin transactors at very little absolute cost, thus degrading the monetary properties of the network.

In theory with Taproot there is another way to inscribe data onchain that you didn’t cover and I alluded to earlier: Schnorr signatures can reportedly be constructed so that they hide some bytes in them, a fact that can be revealed later and anyone can check they were actually there¹.

Any technique for data inscription that is so invisible that it’s exactly just like another transactor TX is great. Because these TXs won’t overpay fees compared to a “real” transactor TX (both are real if they have the same layout and footprint). They just need to pay more fees than transactors at the margin instead of shooting straight to 98%, and transactors can do the same to them (IOW both kinds of users would be trying to economize on the fee, not just transactors).

In this scenario of equal footing inscribers save a ton of fees, and transactors would actually have a chance of pricing out inscribers if the sound money use case has more demand than generic data storage.

Your proposal, while it’s just bitcoin script (like inscriptions, really), suffers from the same problem as inscriptions, the reveal TXs overpays fees compared to transactors (even more onerously IIUC), so if it picked steam it would disrupt the fee market in exactly the same obvious way, and then would prompt people like me who only care about LN and onchain transacting to e.g. unstandardize the OP_IF opcode as vulnerable. Conversely a chain of 1000 sweep Taproot TXs (1 input 1 output) hiding a chunk of a message in each signature would be fine, etc.

IMO mempool policy should eventually reflect all that and nudge inscribers to non-disruptive ways to inscribe data. Maybe also by jacking up fees for arbitrary bytes which is an avenue that hasn’t been explored until very recently, when Knots v25.1 removed the SegWit discount on inscriptions.

https://www.youtube.com/watch?v=gF4Mkkhyz1Q&t=1705s ↩︎

1440000bytes commented at 5:47 pm on December 13, 2023: none

Since I commented here with disagreement to approach: #28408 (comment)

I am suggesting an alternative approach and its up to PR author if he wants to make changes based on it:

Do not mix everything. Keep OP_RETURN separate and provide a config option where users can decide limits for data in witness which is disabled by default.
Add a disclaimer in the PR description that you are the CTO of a mining pool and this pull request can affect it.

Some questions:

Was CVE justified? You can google CVE ID and see articles about it. A seasoned Bitcoin developer asking for a CVE ID should hold significance.
If its really a vulnerability and you shared a patch months ago that community agreed with, why are such transactions still being relayed in the p2p network?
How does this affect miners or their block templates since most of them use core with patches?

eragmus commented at 12:56 pm on December 14, 2023: none

The problem arises when you allow in the same market a new kind of TX interested in another use case which doesn’t mind straight up paying >95% of fees, because they’re doing something else that is not transacting while conserving as many sats as possible. They quickly displace the incumbents as an invasive species, as we’ve seen in 2023.

LN channel opening and closing TXs are also economical in that they try to move as many sats as possible while economizing the fee, therefore they’re also vulnerable to the spam. E.g. $10k channel closures would be hit very hard by $1000 inscriptions.

I’ve allowed extra time to ponder, in case I’m not understanding a new argument if it’s being made, but it seems there really is no new argument given. So, I’d urge you to carefully reread my full prior reply, as that already comprehensively addressed your point.

I said the focus needs to be on fee rate, as fee rate determines priority. Some inscriptions txs get the segwit discount, but so do non-inscriptions txs that use segwit. – And lower-value non-inscriptions txs that get priced out should not have any expectation to be viable on layer 1, regardless if priced out by inscriptions txs now OR higher-value non-inscriptions txs like during bull markets, and so should use other layers like LN.
And I’ll add: Liquid, which has its own set of tradeoffs and can make sense for certain roles, certainly better than custodial LN I’d imagine, as not every segment of payments (like very-low-value payments) benefits from full decentralization (decentralization’s censorship-resistance should be used when it is actually needed, as that is when decentralization’s inherently higher cost makes sense) – “coffee payments do not go on layer 1”.
I also mentioned advocating LN improvement (if LN still does not work well in a high-fee layer 1 environment that it was supposed to be designed for, despite being in development for what 8 years?), such as via CTV, and LN-alternative of Ark via covenants, which can expand scaling by 16x minimum according to discussion I was reading from people involved. And layer 1 scaling, if none of the other options are enough and if it makes sense.

Finally, I present this new X thread (by Glassnode’s Lead On-chain Analyst) with “counter-intuitive facts about inscriptions”, such as that inscriptions txs “make up less than 10% of block data size (bytes)”. This seems relevant for improving understanding.

https://x.com/checkmatey/status/1735085770816532554

The-Sycorax commented at 0:51 am on December 15, 2023: none

The sheer amount of spam caused by inscriptions on the Bitcoin blockchain is actually quite alarming, it should be addressed comprehensively, and in a way that dose not harm the BRC-20 market or people’s livelihoods.

Some individuals are not considering the nature of the vulnerability, it has nothing to do with getting rid of inscriptions. It has to do with the network congestion caused by these types of transactions. It’s not just a matter of higher fees or slower processing times; this situation poses a deeper risk to the network’s integrity. This vulnerability could potentially be exploited as a vector for DDoS attacks, perhaps via transaction flooding or something similar. In fact I’m willing to bet that this is not just a theoretical risk but a present and active one. Such a vulnerability, if exploited, could have far-reaching and detrimental impacts that undermines the security and reliability of the entire system.

There are also implications for the network’s decentralization. Nodes with lesser computational resources may struggle to keep up with the increased demand, potentially leading to a more centralized network topology. This goes against the fundamental ethos of Bitcoin and raises critical questions about the inclusivity and fairness of the blockchain.

For a clearer understanding of the magnitude of this problem, I recommend visiting https://bitcoinstrings.com/. This site provides an extensive archive of all ASCII strings that have ever been embedded within Bitcoin’s blockchain, similar to what you’d see by running: cd .bitcoin/blocks/ && strings -n20 *.dat.

Starting from blk03374.txt, the problem becomes increasingly apparent. As you progress through the block files, you’ll notice that the ungodly extent of spam caused by this vulnerability worsens significantly, predominantly from BRC-20 inscriptions (e.g. blk03570.txt seems to just be flooded and never ending).

Another alarming trend that can also be observed alongside this spam, is the disproportionate and excessive storage of large data directly on the blockchain. This includes entire websites, substantial code repositories, JSON data, and even large text bodies like portions of novels. This can be observed up until a certain point, after-which most of the block files will just contain an endless amount BRC-20 json data. This practice of storing excessively large amounts of data directly on the blockchain further exacerbates the already pressing issue of network congestion and raises serious concerns about the blockchain’s capacity and intended use as a transactional ledger.

Most of the data observed before blk03374 dose not appear to show signs of this sort of spam, with the exception of data found embedded in the blockchain’s early history (e.g. blk00172.txt).

The data embedded in the blockchain clearly indicates that the exploitation of this vulnerability needs to be addressed urgently. It is imperative to develop and implement measures that mitigate these aforementioned risks but without adversely affecting the BRC-20 market or the livelihoods of those who depend on it. This calls for a balanced approach that upholds the principles of blockchain technology while adapting to its evolving uses.

conduition commented at 5:12 pm on December 17, 2023: none

The point of “fighting the spam TXs” is not to prevent all forms of data inscription at all costs, it’s to fix Bitcoin’s fee market. The crux of the problem as described #28408 (comment) and #28408 (comment) is that inscriptions dramatically overpay fees by design and thus price out large segments of Bitcoin transactors at very little absolute cost, thus degrading the monetary properties of the network.

Some individuals are not considering the nature of the vulnerability, it has nothing to do with getting rid of inscriptions. It has to do with the network congestion caused by these types of transactions. @1ma @The-Sycorax I strongly agree with both of you on these points. It’d better for the whole network if people simply used OpenTimestamps or Taproot commitments to prove data provenance off-chain. I would strongly urge any devs who use ordinals to educate themselves, and consider whether off-chain commitment structures like TapRoot or OTS are more appropriate for their use case.

However my point as it relates to this PR is that preventing the upload of arbitrary on-chain data is practically impossible. I hope to demonstrate this through the concept of Inviscriptions, which are close to uncensorable AFAICT.

This is why I concept-nACK’d this PR: It does nothing to address the core issue of mempool congestion. Even if 100% of bitcoin nodes adopt this code, inscriptions of a different form would still persist in the mempool, provided demand for inscriptions also persists.

The only practical fixes I can see for the problem of mempool and fee market congestion are:

Ask devs who make ordinal/inscription apps to use protocols with more efficient footprints (like OpenTimestamps).
Wait for ordinal hype (demand) to die down, so that normal transactions once more outprice them in the fee market.

This PR would only erect a minor barrier which forces the ordinals community to construct a new standard for inscriptions. @casey would likely bear the bulk of the workload in shepherding such a transition.

ben-arnao commented at 7:38 am on December 20, 2023: none

Just my two cents.. if you look at this from a perspective of a bad actor paying to hurt BTC network, as long as there is a cost required to keep up the attack what is the issue? Trying to filter txs that we think are not legitimate seems like a risky road to go down.

From a game theory perspective, if all BTC was mined and distributed evenly to everybody on earth and no fiat existed, people wanting to use ledger for inscriptions will need to continuously earn equal or more BTC than they’ve paid to be able to continue to put upward pressure on fee pricing. There is a lot of de-incentivization pressure on inscriptions in the long run. I think it’s a novel idea people are having fun with now, but I believe it will run it’s course. Ultimately it will come down to the value placed on transferring funds, versus the price per byte of data stored on the ledger.

eragmus commented at 9:16 pm on December 20, 2023: none

if people simply used OpenTimestamps or Taproot commitments to prove data provenance off-chain. I would strongly urge any devs who use ordinals to educate themselves, and consider whether off-chain commitment structures like TapRoot or OTS are more appropriate for their use case. @conduition The reason people are inscribing is because they value the bitcoin layer 1 block space/weight for permanence, convenience, simplicity of design, etc. They value it and are hence willing to pay for it. The market already decided. I heard from a guy who runs various inscription businesses that he even tried to do it offchain, but users were not interested in saving money on the offchain tx fee by sacrificing the benefits of onchain; users were only interested when he did it onchain.

Even if 100% of bitcoin nodes adopt this code, inscriptions of a different form would still persist in the mempool, provided demand for inscriptions also persists. @conduition No need to switch to a different inscription form, assuming you mean 100% of non-mining nodes adopt it. The mining nodes (miners) are financially incentivized to accept the inscriptions, so they will not adopt such code, so inscriptions txs will be sent directly to miners out of band (such as via API) to dark/private miner mempools.

This then creates a new problem of non-miner public mempools not working properly to calculate estimated tx fee rate. And then that means tx fee rate estimation will also move to centralized miner mempools that maybe will be made publicly viewable. So a user loses ability to use their own node to get an accurate view of the mempool, needing to rely on a centralized mempool to figure out their tx fee rate.

mmgen commented at 9:08 am on December 21, 2023: none

@conduition No need to switch to a different inscription form, assuming you mean 100% of non-mining nodes adopt it. The mining nodes (miners) are financially incentivized to accept the inscriptions, so they will not adopt such code, so inscriptions txs will be sent directly to miners out of band (such as via API) to dark/private miner mempools.

Yes, this is the most important point, the reason that this patch will accomplish absolutely nothing at best.

farahats9 commented at 3:46 pm on December 21, 2023: none

Just wanted to add my 2 cents here as a layman using and holding bitcoin. If the transaction fee rates remain this high for someone using bitcoin to transfer money from wallet A to wallet B then I don’t see a future for bitcoin.

The original goal of bitcoin is to make it a currency and a valued asset, if you sacrifice doing this in order to have secondary features then you will fail at both.

If this PR will fix the fee rates back to normal I am on board.

alpeshvas commented at 6:28 pm on December 21, 2023: none

Just wanted to add my 2 cents here as a layman using and holding bitcoin. If the transaction fee rates remain this high for someone using bitcoin to transfer money from wallet A to wallet B then I don’t see a future for bitcoin.

The original goal of bitcoin is to make it a currency and a valued asset, if you sacrifice doing this in order to have secondary features then you will fail at both.

If this PR will fix the fee rates back to normal I am on board.

Fee rates will anyway go higher as demand rises (forget inscriptions) post ETF approvals and more mainstream adoption as demand for blockspace will also go up. Concept NACK

petertodd commented at 6:59 pm on December 21, 2023: contributor

On Thu, Dec 21, 2023 at 07:47:05AM -0800, farahats9 wrote:

Just wanted to add my 2 cents here as a layman using and holding bitcoin. If the transaction fee rates remain this high for someone using bitcoin to transfer money from wallet A to wallet B then I don’t see a future for bitcoin.

The original goal of bitcoin is to make it a currency and a valued asset, if you sacrifice doing this in order to have secondary features then you will fail at both.

If this PR will fix the fee rates back to normal I am on board.

It will not. Miners will not reject these transactions, as they pay significant fees (and in turn, cause others to pay significant fees). Secondly, BRC-20 and similar token issuance and trades drive the majority of token-related fees right now, and they don’t need more than 80 bytes of data.

PerpetualWar commented at 7:42 pm on December 21, 2023: none

Just wanted to add my 2 cents here as a layman using and holding bitcoin. If the transaction fee rates remain this high for someone using bitcoin to transfer money from wallet A to wallet B then I don’t see a future for bitcoin. The original goal of bitcoin is to make it a currency and a valued asset, if you sacrifice doing this in order to have secondary features then you will fail at both. If this PR will fix the fee rates back to normal I am on board.

Fee rates will anyway go higher as demand rises (forget inscriptions) post ETF approvals and more mainstream adoption as demand for blockspace will also go up.

In short, issue is not with the inscriptions but with the astronomical fees in general (which will get worse). And there is no solution for that problem?

alpeshvas commented at 6:53 am on December 22, 2023: none

Just wanted to add my 2 cents here as a layman using and holding bitcoin. If the transaction fee rates remain this high for someone using bitcoin to transfer money from wallet A to wallet B then I don’t see a future for bitcoin. The original goal of bitcoin is to make it a currency and a valued asset, if you sacrifice doing this in order to have secondary features then you will fail at both. If this PR will fix the fee rates back to normal I am on board.

Fee rates will anyway go higher as demand rises (forget inscriptions) post ETF approvals and more mainstream adoption as demand for blockspace will also go up.

In short, issue is not with the inscriptions but with the astronomical fees in general (which will get worse). And there is no solution for that problem?

Filtering is definitely not the solution, I would say that’s a temporary hack and will require permanent solution like lighting.

conduition commented at 9:15 pm on December 22, 2023: none

I heard from a guy who runs various inscription businesses that he even tried to do it offchain, but users were not interested in saving money on the offchain tx fee by sacrificing the benefits of onchain; users were only interested when he did it onchain. @eragmus Woah. That speaks volumes about the users who are paying these exorbitant fees. Thanks for that account.

BitcoinMechanic commented at 2:09 am on December 26, 2023: none

Filtering is a very useful step. It is irrelevant to continually bring up the point that miners can still include this stuff in blocks.

Miners get to decide what goes in blocks and if the wider network is strongly indicating that it (correctly) considers a use-case to be undesirable they can choose to mine templates that do not include such “transactions”. Until now there has been no signalling of this and no good option beyond solo mining. Ocean pool (disclaimer: my employer) provides this option but has not been around for even a month and it already enjoys 0.1% of the hashrate.

It may very well be the case that miners indeed do not want to make life harder for node runners by including data that is of no relevance to them.

GregTonoski commented at 1:42 pm on December 27, 2023: none

Why not depracating OP_IF in SegWit v1 (TapRoot) txs?

ybaidiuk commented at 6:21 pm on December 27, 2023: none

Ok filter is bad idea because of censoring. Also, just disable OP_RETRUN is not an option, but we still have free market violation (fee) People do not pay full price to put data in blockchain, they do abuse of fee-free size of OP_RETRUN (83 bytes now).

In this case, will be doing nothing is a good solution. But i think the best option will be to reduce size of OP_RETURN to 40 bytes like it was before. It will make fee-abuse more expensive and create stimulation to move data into side chains.

eragmus commented at 11:48 pm on December 30, 2023: none

Filtering is a very useful step. It is irrelevant to continually bring up the point that miners can still include this stuff in blocks.

Filtering by non-mining nodes is irrelevant to whether mining nodes (miners) sell their block space to those who want to buy their block space. Miners are conducting business, they have direct skin in the game, and mining is designed as a hyper competitive business.

Simultaneously, it is harmful to bitcoin for many non-mining nodes to do this, since it incentivizes private/dark miner mempools, as has been discussed many times in this thread. This means decentralized mempool gets less useful, and centralized mempool gets more useful. It also centralizes mining further, since someone will want to send their tx directly to a big miner instead of a small miner.

if the wider network is strongly indicating that it (correctly) considers a use-case to be undesirable they can choose to mine templates that do not include such “transactions”.

Miners have no obligation to care what some uneconomic non-mining nodes signal about whether they subjectively don’t value certain data. That’s because bitcoin is neutral, and other people do subjectively value the block space they are buying from miners.

Until now there has been no signalling of this and no good option beyond solo mining. Ocean pool (disclaimer: my employer) provides this option but has not been around for even a month and it already enjoys 0.1% of the hashrate.

What is not mentioned is the 0.1% is based on Ocean’s investors’ temporary subsidies:

0% fee on revenue (for first 2 months, so 1 month left?)
bonus payout for first 8 blocks of work (about 5 blocks of work left, so 1.25 months left)
paying bills of Ocean’s 1-2 biggest accounts that have 45-60% of Ocean’s hashrate (how much longer is this happening?) – BitcoinMechanic (Ocean employee) has responded: “We are not paying anyone’s power bills. What got leaked was an agreement that never went anywhere.”
any other disclosed/undisclosed subsidies

Let’s see what happens when all subsidies are removed.

Plus, the current bitcoin subsidy is still high at 6.25/block, and bitcoin price is relatively high at $40,000+. So, that means Ocean’s miners can afford to care less about missing out on fees from subjectively-valued arbitrary data tx fees. – Imagine what happens to subsidy after 1 halving in 4 months, and then after 4 years 4 months after another halving, and so on. Then, fees get far more important, not less important (ignoring bitcoin price, because price can do anything due to external uncontrollable economic/political events, so it can’t be relied upon to pad miners’ margins to allow for ideological non-feemaxing mining).

It may very well be the case that miners indeed do not want to make life harder for node runners by including data that is of no relevance to them.

The block size limits were already accepted by consensus during segwit, so node runners’ lives are not any harder than they would be if blocks were full (full blocks are the healthy and desired state) due to “normal” txs.

Also, blocks are only on average filled with 10% data of inscriptions, see data I posted some replies back by ‘checkmate’.

And, inscriptions’ data can be pruned for pruned nodes. (There are other protocols these days that can’t be pruned, but these only exist because of antagonism and threats made against inscriptions by some, as was predicted to happen, so it should be a hint not to do that to avoid creating a problem.)

DoctorBuzz1 commented at 11:26 am on December 31, 2023: none

Filtering by non-mining nodes is irrelevant to whether mining nodes (miners) sell their block space to those who want to buy their block space. Miners are conducting business, they have direct skin in the game, and mining is designed as a hyper competitive business.

Miners have no obligation to care what some uneconomic non-mining nodes signal about whether they subjectively don’t value certain data. That’s because bitcoin is neutral, and other people do subjectively value the block space they are buying from miners.

Miners would be most incentivized to use a decentralized pool like Ocean (regardless of the template they choose… but if they believed Bitcoin to be money and not just a permisionless, immutable blockchain, they would indeed filter the spam to make the MONETARY network usable!), otherwise miners are allowing coinbase Tx custodians to strip “rare” sats, and pay more than 2x the Tx fees overall in order to get their payout (esp when considering the automatic stripping of all these 546 Sat Txs). See here: https://twitter.com/DoctorBuzz1/status/1740720939321671913

Also, blocks are only on average filled with 10% data of inscriptions, see data I posted some replies back by ‘checkmate’.

While 10% is not as bad as it was when fees were lower, pushing spam to the back (bottom?) of the mempool would allow the monetary Txs from the mempool to clear within a week or so. This is a GOOD thing for a decentralized MONETARY ledger. This is GOOD for Layer 2 solutions to open, close. Sub-$2 Txs were EASILY attainable before Ordinals took over 50% of block space in Feb 2023, and cheap Txs are something the network at least OCCASIONALY needs for scaling to exist, with or without OP_CTV.

A global monetary system MUST be efficient, focused… which I believe Core has made the correct steps in this direction up until now (small blocks made sense up until Feb, when 1 sat / vByte Txs became a distant memory), but I hope that this focus is not lost to the belief that Bitcoin is “JUST a permisionless blockchain where anything can be stored forever”.

REMEMBER WHEN SATOSHI SAID THIS?? –

“Piling every proof-of-work quorum system in the world into one dataset doesn’t scale.

Bitcoin and BitDNS can be used separately. Users shouldn’t have to download all of both to use one or the other.

The networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it’s easy for lots of users and small devices.” - Satoshi (Dec. 2010)

TWO DAYS LATER, he drops his last message on BitcoinTalk (that starts with this), and then he never posted there again –

“There’s more work to do on DoS, but I’m doing a quick build of what I have so far in case it’s needed, before venturing into more complex ideas."

Point blank!! Context is key! What IS Bitcoin?

And also, checkmatey’s graphs have misrepresented inscribed images as text. See here: https://twitter.com/DoctorBuzz1/status/1741401153781289083

If Bitcoin is MONEY (it is!)… then non-monetary Txs should be reduced as much as possible, and by every means necessary… otherwise the long-term value proposition of Bitcoin is incredibly weakened. Many people are using it as their entire savings, retirement accounts because they believe it’s currently the best money. But a limited block size WITH rampant file storage will definitely lead people to other chains that “just work”. If we’re going to limit its ACTUAL use-case, then BCH unfortunately starts to look better and better every day. :-(

DoctorBuzz1 commented at 7:51 pm on December 31, 2023: none

One more thing about the BRC-20 style crap…. isn’t this something appropriate for isDust()??

I’m sure I don’t have these variables correct (and I still think in cents, so bear with me), but using the example above….

If a (Tx == $0.23) && (TxFee ==$6.45)… then couldn’t something like this be fairly usable??

If (Tx < 3TxFee) { isDust = True;}

Or some other ratio that makes sense like “If (Tx < 2TxFee)”?? I’m personally not going to send a $10 Tx for a $5 fee, honestly, but someone might. But something’s definitely WRONG with a monetary system where a Tx <= its TxFee. Most will think this goes too far, and I’m sure there are use-cases I’m not considering…. but it seems like isDust() could help with those inefficient 546 Sat Txs, which certainly APPEAR to be unusable, unspendable DUST!

!!! EDIT: !!! EDIT: !!! EDIT: !!!

Here’s just ONE of countless examples of “text/html” Ordinal Txs (which are actually IMAGES, in case you didn’t click thru!)…. https://ordinals.com/tx/a1b126f6006d6814228bfe0272bd5b85b013a5fcbcdd025eb7216125e1d2fc17

1 Input 90198e32540167106594968eec543dfba66ed9f3f42ef130e78d17f4b9b526c7:3 1 Output a1b126f6006d6814228bfe0272bd5b85b013a5fcbcdd025eb7216125e1d2fc17:0 value 10000 script pubkey OP_PUSHNUM_1 OP_PUSHBYTES_32 408909d3a25378eb035c01d4e04510551a4eb808484321d443d04e7842096063 address bc1pgzysn5az2duwkq6uq82wq3gs25dyawqgfppjr4zr6p88sssfvp3sl2rcw7

On mempool.space… https://mempool.space/tx/a1b126f6006d6814228bfe0272bd5b85b013a5fcbcdd025eb7216125e1d2fc17#vout=0

Tx = 10,000 Sats TxFee = 64,610 Sats !!!!

This is the DEAD giveaway….. When somebody is paying over 6x as much for the Tx Fee than their actual Tx, then this is OBVIOUSLY spam!!!

Soo, it looks like I had my multipier backwards?? Should be…..

If (3Tx < TxFee) { isDust = True;}

BitcoinMechanic commented at 6:13 am on January 1, 2024: none

Filtering is a very useful step. It is irrelevant to continually bring up the point that miners can still include this stuff in blocks.

Filtering by non-mining nodes is irrelevant to whether mining nodes (miners) sell their block space to those who want to buy their block space. Miners are conducting business, they have direct skin in the game, and mining is designed as a hyper competitive business.

Simultaneously, it is harmful to bitcoin for many non-mining nodes to do this, since it incentivizes private/dark miner mempools, as has been discussed many times in this thread. This means decentralized mempool gets less useful, and centralized mempool gets more useful. It also centralizes mining further, since someone will want to send their tx directly to a big miner instead of a small miner.

if the wider network is strongly indicating that it (correctly) considers a use-case to be undesirable they can choose to mine templates that do not include such “transactions”.

Miners have no obligation to care what some uneconomic non-mining nodes signal about whether they subjectively don’t value certain data. That’s because bitcoin is neutral, and other people do subjectively value the block space they are buying from miners.

Until now there has been no signalling of this and no good option beyond solo mining. Ocean pool (disclaimer: my employer) provides this option but has not been around for even a month and it already enjoys 0.1% of the hashrate.

What is not mentioned is the 0.1% is based on Ocean’s investors’ temporary subsidies:
* 0% fee on revenue (for first 2 months, so 1 month left?)

* bonus payout for first 8 blocks of work (about 5 blocks of work left, so 1.25 months left)

* [paying bills](https://x.com/checksum0/status/1737267990624604459?s=46) of Ocean's 1-2 biggest accounts that have 45-60% of Ocean's hashrate (how much longer is this happening?)

* any other disclosed/undisclosed subsidies
Let’s see what happens when all subsidies are removed.

Plus, the current bitcoin subsidy is still high at 6.25/block, and bitcoin price is relatively high at $40,000+. So, that means Ocean’s miners can afford to care less about missing out on fees from subjectively-valued arbitrary data tx fees. – Imagine what happens to subsidy after 1 halving in 4 months, and then after 4 years 4 months after another halving, and so on. Then, fees get far more important, not less important (ignoring bitcoin price, because price can do anything due to external uncontrollable economic/political events, so it can’t be relied upon to pad miners’ margins to allow for ideological non-feemaxing mining).

It may very well be the case that miners indeed do not want to make life harder for node runners by including data that is of no relevance to them.

The block size limits were already accepted by consensus during segwit, so node runners’ lives are not any harder than they would be if blocks were full (full blocks are the healthy and desired state) due to “normal” txs.

Also, blocks are only on average filled with 10% data of inscriptions, see data I posted some replies back by ‘checkmate’.

And, inscriptions’ data can be pruned for pruned nodes. (There are other protocols these days that can’t be pruned, but these only exist because of antagonism and threats made against inscriptions by some, as was predicted to happen, so it should be a hint not to do that to avoid creating a problem.)

Hi @eragmus

You’ve cited a tweet that cites “leaks” making claims about Ocean paying power bills for our miners.

We are not paying anyone’s power bills. What got leaked was an agreement that never went anywhere.

I’ll ask that you delete your dishonest post here or make a clear correction admitting the dishonesty of your claim.

Edit: There are also no subsidies of any kind on our pool. You have no idea what you are talking about.

eragmus commented at 3:48 pm on January 1, 2024: none

Until now there has been no signalling of this and no good option beyond solo mining. Ocean pool (disclaimer: my employer) provides this option but has not been around for even a month and it already enjoys 0.1% of the hashrate.

What is not mentioned is the 0.1% is based on Ocean’s investors’ temporary subsidies:
* 0% fee on revenue (for first 2 months, so 1 month left?)
* bonus payout for first 8 blocks of work (about 5 blocks of work left, so 1.25 months left)
* [paying bills](https://x.com/checksum0/status/1737267990624604459?s=46) of Ocean's 1-2 biggest accounts that have 45-60% of Ocean's hashrate (how much longer is this happening?)
* any other disclosed/undisclosed subsidies
Let’s see what happens when all subsidies are removed.

Plus, the current bitcoin subsidy is still high at 6.25/block, and bitcoin price is relatively high at $40,000+. So, that means Ocean’s miners can afford to care less about missing out on fees from subjectively-valued arbitrary data tx fees. – Imagine what happens to subsidy after 1 halving in 4 months, and then after 4 years 4 months after another halving, and so on. Then, fees get far more important, not less important (ignoring bitcoin price, because price can do anything due to external uncontrollable economic/political events, so it can’t be relied upon to pad miners’ margins to allow for ideological non-feemaxing mining).

You’ve cited a tweet that cites “leaks” making claims about Ocean paying power bills for our miners.

We are not paying anyone’s power bills. What got leaked was an agreement that never went anywhere.

Hi @BitcoinMechanic.

Thank you for adding clarity to the conversation. So, the leaked agreement was not actually implemented. And, no Ocean miners are having their bills (power bills, specifically) paid.

I’ll ask that you delete your dishonest post here or make a clear correction admitting the dishonesty of your claim.

I’ll certainly update the original post to reflect your newly-provided information. (But obviously would make 0% sense to delete the entire post over this point, and that too a point that was 100% honest as far as my understanding of the information was concerned and even cited a source).

Edit: There are also no subsidies of any kind on our pool. You have no idea what you are talking about.

Bitcoin’s protocol subsidizes hashrate (to incentivize it to mine bitcoin), at the expense of hodlers, via its temporary ‘block subsidy’… and thereby increases its miners’ revenue beyond Bitcoin’s block fees.

Ocean pool subsidizes hashrate (to incentivize it to join Ocean), at the expense of Ocean’s investors, via its temporary block work bonus + temporary 0% fee on block revenue… and thereby increases its miners’ revenue beyond Bitcoin’s block reward + beyond what they would get at competing pools that lack the 0% fee.

If you’re trying to make a semantic argument about “subsidy” to avoid confronting the actual obvious argument, then that won’t work.

Ocean’s “0.1% hashrate in a month” achievement must be caveated with this context, to help avoid what can be otherwise interpreted as a dishonest promotional post (aka Ocean advertisement).

It’s also relevant that Ocean has a very high-profile investor, Jack, and Core dev (Luke), which is free advertising that has made Ocean more well-known than a competing new pool would otherwise be. This is separate from the merits of the ideological approach.

On a related and serious note, it has come to my attention that Ocean’s investors include various “Bitcoin influencers”. This should obviously be disclosed by both these investor “influencers” and by Ocean, to avoid conflicts of interest, to provide context for when those investor “influencers” promote Ocean and Ocean’s ideological agenda (that serves Ocean by redirecting hashrate from others to Ocean, and therefore serves themselves as investors in Ocean) on various platforms.

However, I cannot find the list of Ocean’s investors on https://ocean.xyz (startups usually disclose their investors on their website). It has been more than 1 month since launch. Has Ocean disclosed its investors? If so, where can this information be found? If not, when will this disclosure be made available, in the interest of transparency? Bitcoiners surely deserve to know.

Happy New Year.

BitcoinMechanic commented at 6:00 pm on January 1, 2024: none

Ocean pool subsidizes hashrate (to incentivize it to join Ocean), at the expense of Ocean’s investors

This is completely false. Zero miners have received any income that didn’t come directly from blocks found which were made up 100% of transactions available to any miner. Nothing out of band has happened in any capacity. You simply do not understand how PPLNS or PPLNS reminiscent systems work and are arguing from a position of inexperience.

edit: I request that you stop talking about Ocean entirely as 1. It is not relevant to this discussion beyond being an option for miners who wish to use a template with updated spam filtration. 2. You clearly have a poor understanding of how it operates.

eragmus commented at 6:50 pm on January 1, 2024: none

Ocean pool subsidizes hashrate (to incentivize it to join Ocean), at the expense of Ocean’s investors

This is completely false. Zero miners have received any income that didn’t come directly from blocks found which were made up 100% of transactions available to any miner. Nothing out of band has happened in any capacity. You simply do not understand how PPLNS or PPLNS reminiscent systems work and are arguing from a position of inexperience.

Are you denying that Ocean temporarily has a 0% fee on revenue (not charging a fee is a cost for Ocean that is paid by Ocean’s investors) + a block work bonus (paid by investors)?

Or are you disagreeing with the details of how they work? If nitpicking with such details/semantics, while ignoring the overall argument, then that is called a weak evasive response. These 2 policies are obviously relevant in the achievement of Ocean’s 0.1% hashrate in 1 month… which is what I have repeated a few times now.

edit: I request that you stop talking about Ocean entirely as 1. It is not relevant to this discussion beyond being an option for miners who wish to use a template with updated spam filtration. 2. You clearly have a poor understanding of how it operates.

You, the Ocean employee, are the one who brought up Ocean’s 0.1% hashrate into this discussion, as a reason for people to support the change to Bitcoin Core. Therefore, Ocean is fair game.

I request that you stop ignoring the request for Ocean’s list of investors:

On a related and serious note, it has come to my attention that Ocean’s investors include various “Bitcoin influencers”. This should obviously be disclosed by both these investor “influencers” and by Ocean, to avoid conflicts of interest, to provide context for when those investor “influencers” promote Ocean and Ocean’s ideological agenda (that serves Ocean by redirecting hashrate from others to Ocean, and therefore serves themselves as investors in Ocean) on various platforms.

However, I cannot find the list of Ocean’s investors on https://ocean.xyz (startups usually disclose their investors on their website). It has been more than 1 month since launch. Has Ocean disclosed its investors? If so, where can this information be found? If not, when will this disclosure be made available, in the interest of transparency? Bitcoiners surely deserve to know.

It is even highly relevant to this PR change to Bitcoin Core, since this discussion could already have had participation from Ocean investors (who are or are not “Bitcoin influencers”) who have not disclosed their conflict of interest with Ocean (kudos to you for voluntarily disclosing you are an employee of Ocean). A list of Ocean’s investors is in the interest of all bitcoiners, especially where this topic is concerned.

in src/script/script.cpp:332 in 4d2ec0671a

327+            inside_noop = 1;
328+            data_began = opcode_it;
329+        // Match <data> OP_DROP
330+        } else if (opcode <= OP_PUSHDATA4) {
331+            data_began = opcode_it;
332+        } else if (opcode == OP_DROP && last_opcode <= OP_PUSHDATA4) {

rot13maxi commented at 2:15 am on January 2, 2024:

have we seen protocols using <data> OP_DROP in the wild, or is this a pre-emptive check?

wizkid057 commented at 2:24 am on January 2, 2024: none

Approach ACK.

Don’t let perfect be the enemy of good. Spam is already filtered at various levels in the code, and has been for over a decade. All this PR does is apply an existing limit on datacarriersize to data carrying of a different form of data carrying that is clearly an unintended exploit. This is a no brainer place to start with correcting that.

Discussion about OCEAN seems quite off topic here (perhaps only except for it being the only pool using this PR in practice), but it’s important to note a rebuttal to the misinformation above: OCEAN has not paid any miners anything that wasn’t derived from the rewards from blocks found by the pool. The “bonus” shown is not something paid from other funds (investors or otherwise), it’s just that the reward system’s sharelog is not yet full, so shares are weighted more heavily since there are fewer in the log, and we’re showing that delta as “a bonus”.

ns-xvrn commented at 3:00 am on January 2, 2024: contributor

Concept ACK

eragmus commented at 6:53 am on January 2, 2024: none

OCEAN has not paid any miners anything that wasn’t derived from the rewards from blocks found by the pool. The “bonus” shown is not something paid from other funds (investors or otherwise), it’s just that the reward system’s sharelog is not yet full, so shares are weighted more heavily since there are fewer in the log, and we’re showing that delta as “a bonus”.

Thanks for clarifying the source of the bonus. If Ocean reps don’t provide the actual information, then obviously people will speculate, and cannot be faulted for doing so.

This is just a technical Ocean clarification, and indeed not relevant to this proposed Bitcoin Core change.

The relevance is that the 2 temporary incentive policies (0% fee + bonus) are connected with the achievement of Ocean’s 0.1% hashrate in 1 month (being trumpeted as evidence of popularity of Ocean’s approach). And this was the core argument being repeatedly made, but ignored.

It shouldn’t be hard to grasp the main argument and admit what is obvious (or directly dispute it), instead of being evasive through nitpicking.

EDIT:

The person I responded to is apparently another employee of Ocean (I’m not aware that it was disclosed here?).

On that note, I reiterate the request for every person with a conflict-of-interest (incl. investors, employees, etc.) in Ocean to be disclosed.

This is NOT about doubting honesty, character, intentions, etc. I’m sure everyone is trying to be honest and cares about Bitcoin, regardless of affiliation. And arguments should of course be judged on their merit, not on who said it. But, this is also about unintentional bias affecting personal views (e.g. attempts to police the discussion of Ocean’s relevance to this proposal, by Ocean employees no less), which is relevant for this specific proposal to change the open-source Bitcoin Core software. Again, kudos to BitcoinMechanic for disclosing his conflict, but every Ocean employee/investor should disclose & be disclosed by Ocean.

wizkid057 commented at 1:56 am on January 4, 2024: none

Interesting standard. I don’t see anyone else disclosing their employer, investors, etc when replying here… and there are definitely people commenting here who have clear conflicts of interest (mostly against this PR). So, I’m going to reject the entire premise of a suggestion that OCEAN associated people alone be required to disclose that. Perhaps if I see some more broad application of such a thing, I’d reconsider, but otherwise it’s a pointless and ridiculous ask.

That said, I figured my own affiliation was beyond obvious having been in the Bitcoin space for well over a decade, having previously run the Eligius pool with Luke, etc.

eragmus commented at 2:19 am on January 4, 2024: none

That said, I figured my own affiliation was beyond obvious having been in the Bitcoin space for well over a decade, having previously run the Eligius pool with Luke, etc.

Not all of us, like myself, are so familiar with the mining ecosystem, so I had no idea who you were until I realized it for myself coincidentally.

Interesting standard. I don’t see anyone else disclosing their employer, investors, etc when replying here… Perhaps if I see some more broad application of such a thing, I’d reconsider, but otherwise it’s a pointless and ridiculous ask.

Totally fair. I don’t know why terms of involvement here do not require disclosure of conflicts of interest (employment, investment, etc.). Well, it might be infeasible if there is a lot of information to display, but ideally there would be a way to do it to get the most benefit out of it efficiently. Like requiring a “signature line” on each post that makes relevant disclosure. It seems like a basic standard to require.

The separate point is that Ocean itself should be disclosing its employees and investors, so at least anyone can visit its website and see for themselves.

dzyphr commented at 2:21 am on January 4, 2024: none

Concept ACK The current state of the datacarriersize exploit allows users of non-Bitcoin-related protocols to piggyback off of the good will of full node runners. Regular users pay for every single vByte and unrelated protocol users do not. This occurs while the unrelated protocol spams the UTXO set, creating an non-scalable setting for anyone looking to run infrastructure. Being as that a dense full node graph is vital to the success of Bitcoin as a network, it would be detrimental to continue to allow the network to be spammed by people intentionally abusing full node runner storage space.

cculianu commented at 12:21 pm on January 4, 2024: none

Concept ACK The transactions targeted by this pull-req. are a very significant source of prohibitive cost for regular node operators. It is very unlikely that regular node operators will give up mitigating that source of operative cost. Regular policy rule for these transactions would encourage the economical resource usage of mempools - not harming any miners - neither changing any fee estimation already on the field.

As long as miners continue to mine these transactions they will end up in blocks, requiring node operators to process those transactions.

So why does standardness exist in the first place in Bitcoin as a thing? Why have a relay policy vs consensus policy if miners can mine non-standard anyway? Your argument seems extremely close to saying standardness as a concept doesn’t work. This has clearly been shown to not be true. Standardness works, and is effective.

Your argument is underhanded in a way in that it sort of argues that standardness doesn’t work, which is demonstrably untrue.

It’s always been the case that: By discouraging some expensive/big/data carrier style scripts and txns, via relay policy, effectively the network (almost) never sees these transactions. So… standardness works.

Censoring those transactions simply shifts when that bandwidth usage happens. Indeed, it’ll make block propagation happen somewhat slower for some users/miners due to interference with compact blocks. This is harmful to many users, as well as some smaller miners.

Maybe. It depends on what you consider the purpose of Bitcoin is. In the past, it was long agreed-upon that Bitcoin is not a data carrier network. Options such as -datacarriersize= exist(ed) for a reason. It was always the case that nobody liked for Bitcoin to become a data carrier coin.

If you defined Bitcoin as being a network that permits data carrier stuff, then you would consider this censorship.

If you don’t, then you would consider this just a decent relay policy to discourage undesirable use of the network.

It all depends on what you consider legitimate or not. From the this comment, it appears you consider Bitcoin as a data carrier coin to be a legitimate use-case.

Just openly say so then..!

Secondly, fee estimation requires knowledge of unconfirmed transactions to determine what the next block will likely consist of. Censoring unconfirmed transactions that could be included in blocks makes it harder to estimate fees correctly because you lack information about the true total demand for blockspace.

Again, this is like arguing that standardness as a relay rule doesn’t work or something. You’re assuming that standardness is never an effective technique for reducing unwanted txns from existing. You’re assuming miners will routinely ignore standardness (which empirically has not been the case) and mine non-standard willy nilly all the time anyway. It’s a rare exception for miners to mine non-standard, not the other way around. Your assumption is not realistic and not likely to occur.

michaelfolkson commented at 12:49 pm on January 4, 2024: contributor

Concept NACK.

The high fee rate, consensus valid transactions that Ocean mines is Ocean’s business but trying to prevent high fee rate, consensus valid transactions from finding their way to all miners is a losing game. Even if this PR was merged the transactions could be submitted to miners out of band.
Transactions are just bytes with constraints imposed on them by the consensus rules. There is an endless list of ways small chunks of data (ie bytes) can be embedded in consensus valid transactions. If the current method was addressed using policy (or taken to extremes consensus) a different method would be used and then a different method and then a different method etc. Ocean can move quicker than Core so perhaps Ocean can engage in this game of tit-for-tat or whack-a-mole but Core would look ridiculous if it was to do so. It would also elevate these use cases as they would be making a mockery of the Core project and it would be obvious for everyone to see. Even assuming it was possible for the consensus rules to prevent small chunks of data being embedded in transactions this change should have a BIP and outline how it completely and exhaustively closes every loophole.

desi-bitcoiner commented at 3:59 pm on January 4, 2024: none

Concept ACK

darosior commented at 4:38 pm on January 4, 2024: member

Can a maintainer please close this PR? It’s clear this is not going anywhere and is just spamming the repository.

Most regular contributors to this project who gave their opinion here and elsewhere are against making this change. Nothing’s preventing people interested in this code change to fork the project and develop their own Bitcoin P2P client. (As a matter of fact OP is already maintaining such a client, people interested in this could contribute to this project instead of arguing here.)

1ma commented at 7:03 pm on January 4, 2024: none

In order to be consistent with the documentation of datacarriersize, this PR needs to roll back the changes recently made in src/init.cpp by this other PR: #27832

Not sure about the tests it added.

sipa commented at 9:54 pm on January 4, 2024: member

Concept NACK.

I do not believe this to be in the interest of users of our software. The point of participating in transaction relay and having a mempool is being able to make a prediction about what the next blocks will look like. Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.

Of course, anyone is free to run, or provide, software that relays/keeps/mines whatever they want, but if your goal isn’t to have a realistic mempool, you can just as well run in -blocksonly mode. This has significantly greater resource savings, if that is the goal.

To the extent that this is an attempt to not just not see certain transactions, but also to discourage their use, this will at best cause those transactions to be routed around nodes implementing this, or at worst result in a practice of transactions submitted directly to miners, which has serious risks for the centralization of mining. While non-standardness has historically been used to discourage burdensome practices, I believe this is (a) far less relevant these days where full blocks are the norm so it won’t reduce node operation costs anyway and (b) powerless to stop transactions for which an existing market already exists - one which pays dozens of BTC in fee per day.

I believe the demand for blockspace many of these transactions pose is grossly misguided, but choosing to not see them is burying your head in the sand.

dzyphr commented at 10:36 pm on January 4, 2024: none

Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.

I would agree on this point’s premise however to me it is not clear that this PR attempts to do this, it applies the same standard of datacarrier cost to transactions that currently do not encounter it and makes exceeding the limit nonstandard which is a policy used to deter other kinds of unwanted transaction formats. Currently the code enforces that those who do use it get a discount which creates incentive for the UTXO set spam.

Of course, anyone is free to run, or provide, software that relays/keeps/mines whatever they want, but if your goal isn’t to have a realistic mempool, you can just as well run in -blocksonly mode. This has significantly greater resource savings, if that is the goal.

The concept of “realistic” totally depends on where transactions are propagating, the goal is clearly not to remove the utility of the mempool entirely but only to improve it’s spam filtration policies. When widely adopted that will become the “realistic” mempool.

To the extent that this is an attempt to not just not see certain transactions, but also to discourage their use, this will at best cause those transactions to be routed around nodes implementing this, or at worst result in a practice of transactions submitted directly to miners

The claim is that this will lead to out of band transactions however it is clear that currently the pools who post the most blocks on to the network already accept plenty of out of band transactions. Sometimes they have gone as far as to excluded an entire block of transactions for a single out of band one. (4mb wizard)

which has serious risks for the centralization of mining. While non-standardness has historically been used to discourage burdensome practices, I believe this is (a) far less relevant these days where full blocks are the norm so it won’t reduce node operation costs anyway and (b) powerless to stop transactions for which an existing market already exists - one which pays dozens of BTC in fee per day.

If this is true why are there any standardness rules, should we not operate under the assumption that every transaction properly paying a miner is valid?

I believe the demand for blockspace many of these transactions pose is grossly misguided, but choosing to not see them is burying your head in the sand.

In this sentence the word demand is being used ambitiously, there is no evidence it is organic or substantial compared to normal financial transactions. The blocks with filtered templates for example see an average decrease of about .01 BTC per block in miner subsidy.

BitcoinMechanic commented at 0:50 am on January 5, 2024: none

To the extent that this is an attempt to not just not see certain transactions, but also to discourage their use, this will at best cause those transactions to be routed around nodes implementing this, or at worst result in a practice of transactions submitted directly to miners, which has serious risks for the centralization of mining. While non-standardness has historically been used to discourage burdensome practices, I believe this is (a) far less relevant these days where full blocks are the norm so it won’t reduce node operation costs anyway and (b) powerless to stop transactions for which an existing market already exists - one which pays dozens of BTC in fee per day.

I think this is upside-down. Mining is centralized beyond what’s acceptable anyway - at least with regard to block template construction. The reason we would resort to such desperation (abandoning anything more restrictive in default mempool policy, or even remove existing restrictions) to try and hold back the tide here is only good in so far as it at least acknowledges this rarely talked about problem. Other than that it’s a losing battle. You cannot have a template constructing entity with 30% of the hashrate pointed at it and simply ask them to respect the mempool and never charge an out-of-band premium for blockspace.

A real fix to this requires making it more feasible for miners to make their own templates. I don’t want to derail this discussion any further than to say I agree that we have this problem (increasingly irrelevant mempool), but no - the solution is not to beg huge pools to respect the mempool, it’s to break up template construction.

As an argument against mitigating spam by updating spam filters, “muh mempool” should be dismissed as a non-serious approach to a very serious problem.

eragmus commented at 0:51 am on January 5, 2024: none

Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.

I would agree on this point’s premise however to me it is not clear that this PR attempts to do this, it applies the same standard of datacarrier cost to transactions that currently do not encounter it and makes exceeding the limit nonstandard which is a policy used to deter other kinds of unwanted transaction formats. Currently the code enforces that those who do use it get a discount which creates incentive for the UTXO set spam.

It only deterred it in the past, due to lack of economic demand. 36.2% of 2023’s fees came from non-traditional txs, so we no longer live in the old era that lacked demand.

And the discount with segwit, if that’s what you mean, does the opposite of creating incentive to increase the UTXO set.

Of course, anyone is free to run, or provide, software that relays/keeps/mines whatever they want, but if your goal isn’t to have a realistic mempool, you can just as well run in -blocksonly mode. This has significantly greater resource savings, if that is the goal.

The concept of “realistic” totally depends on where transactions are propagating, the goal is clearly not to remove the utility of the mempool entirely but only to improve it’s spam filtration policies. When widely adopted that will become the “realistic” mempool.

The point is the large economic demand is what will not allow it to be widely adopted, in terms of actually stopping miners from accessing those txs. Hence, the result of such filters is not achieving the goal, and rather would create an unrealistic mempool.

To the extent that this is an attempt to not just not see certain transactions, but also to discourage their use, this will at best cause those transactions to be routed around nodes implementing this, or at worst result in a practice of transactions submitted directly to miners

The claim is that this will lead to out of band transactions however it is clear that currently the pools who post the most blocks on to the network already accept plenty of out of band transactions. Sometimes they have gone as far as to excluded an entire block of transactions for a single out of band one. (4mb wizard)

The fact that a bad result (of out of band txs) is already happening is not an argument to make the bad result be amplified by implementing foolish policy.

It is an argument to address the reason for the current out of band txs, which I suppose would mean to allow mempool relay policies to reflect consensus policies.

which has serious risks for the centralization of mining. While non-standardness has historically been used to discourage burdensome practices, I believe this is (a) far less relevant these days where full blocks are the norm so it won’t reduce node operation costs anyway and (b) powerless to stop transactions for which an existing market already exists - one which pays dozens of BTC in fee per day.

If this is true why are there any standardness rules, should we not operate under the assumption that every transaction properly paying a miner is valid?

That’s what I think, and iiuc, it is also what @petertodd has logically reasoned. Bitcoin has perhaps matured to the point where standardness rules should reflect consensus rules. In practice, since op-return is the best place for arbitrary data, op-return limits should be removed (the opposite of what this proposal seeks).

This will not just remove the contradiction to ensure logical consistency, but as I understand it, it would also have the benefit of reducing mining centralization force + mempool centralization force, by removing the need for those currently non-standard txs to be sent to large miners’ private mempools.

I believe the demand for blockspace many of these transactions pose is grossly misguided, but choosing to not see them is burying your head in the sand.

In this sentence the word demand is being used ambitiously, there is no evidence it is organic or substantial compared to normal financial transactions. The blocks with filtered templates for example see an average decrease of about .01 BTC per block in miner subsidy.

On the contrary, there is plenty of evidence. The mempool.space organization recently did the most comprehensive analysis I’ve seen, discovering 36.2% of 2023’s fees were paid by those txs.

36.2% = 8,482 BTC (roughly $250 million, adjusted for bitcoin’s price during that period)

Those txs only really began ramping up around the end of Jan, so for ~340 days in 2023.

8,482 BTC / 340 days = ~25 BTC/day

25 BTC/day / 144 blocks/day = ~0.17 BTC/block on average

dzyphr commented at 1:08 am on January 5, 2024: none

“It only deterred it in the past, due to lack of economic demand. 36.2% of 2023’s fees came from non-traditional txs, so we no longer live in the old era that lacked demand.And the discount with segwit, if that’s what you mean, does the opposite of creating incentive to increase the UTXO set.”

You are again using the word demand completely ambitiously, there is little to no evidence that these are organic or sustainable flows of Bitcoin funding scam protocols. You are free to prove that the discount doesn’t exist, however asserting it does nothing. It exists, it is the reason we are talking here in the first place. You clearly haven’t even looked at this PR.

“The point is the large economic demand is what will not allow it to be widely adopted, in terms of actually stopping miners from accessing those txs. Hence, the result of such filters is not achieving the goal, and rather would create an unrealistic mempool.”

The economic demand is not very large, it is demonstrably small compared to historical usage of actual Bitcoin not related to offchain scam tokens.

“The fact that a bad result (of out of band txs) is already happening is not an argument to make the bad result be amplified by implementing foolish policy.It is an argument to address the reason for the current out of band txs, which I suppose would mean to allow mempool relay policies to reflect consensus policies.”

You haven’t provided any reasonable evidence as to why the policy is foolish, so I will dismiss that as a non sequitur. The mempool is currently not even close to facilitating the exact same transactions that end up in blocks, out of band relay has become a moot point because the current mempool situation already provides incentive for hosting it.

“That’s what I think, and iiuc, it is also what @petertodd has logically reasoned. Bitcoin has perhaps matured to the point where standardness rules should reflect consensus rules. In practice, since op-return is the best place for arbitrary data, op-return limits should be removed (the opposite of what this proposal seeks).This will not just remove the contradiction to ensure logical consistency, but as I understand it, it would also have the benefit of reducing mining centralization force + mempool centralization force, by removing the need for those currently non-standard txs to be sent to large miners’ private mempools.”

You have simply failed to understand the irony of what I am pointing out, standardness rules are to enforce pro-Bitcoin rules as in things that improve not harm the scalability of the network. If they were not why not then why have something like a script interpreter anyway? Why not just send C++ code to the miners to execute? It would be more optimal that way to send arbitrary data.

“On the contrary, there is plenty of evidence. The mempool.space organization recently did the most comprehensive analysis I’ve seen, discovering 36.2% of 2023’s fees were paid by those txs.”

OK, and was Bitcoin started in 2023? Lets see the comprehensive all time analysis of normal transactions verses “tokens, stamps, NFT” and any other protocol relying on auxiliary software that is not officially recognized by Bitcoin core. You would see how utterly miniscule this is over that gap, but instead you provided a very obviously biased metric during the time at which the spam has been the heaviest.

luke-jr commented at 2:40 am on January 5, 2024: member

The point of participating in transaction relay and having a mempool is being able to make a prediction about what the next blocks will look like.

No, it is not and never has been. The closest it comes to that, is the point of influencing what the next blocks will look like, as you said yourself years ago to justify Compact Blocks.

Predicting the next block can only ever be a possibility if you assume a centralized mining ecosystem, something to actively work against.

Of course, anyone is free to run, or provide, software that relays/keeps/mines whatever they want, but if your goal isn’t to have a realistic mempool, you can just as well run in -blocksonly mode.

How will that mine anything other than empty blocks? How will it reward honest miners and penalize harmful miners?

To the extent that this is an attempt to not just not see certain transactions, but also to discourage their use, this will at best cause those transactions to be routed around nodes implementing this, or at worst result in a practice of transactions submitted directly to miners, which has serious risks for the centralization of mining.

On the contrary, the efforts in recent years to impose a single Core-dictated policy on nodes, is in itself just another form of centralization. If miners actively work against users, they are malicious, and need to be replaced entirely with a PoW change. But that hasn’t been demonstrated yet, it’s just being thrown around here as FUD against mitigating an actively exploited vulnerability.

ben-arnao commented at 3:49 am on January 5, 2024: none

All these people really care about is being able to inscribe data in an immutable and decentralized manner, they don’t really care about it being done on BTC blockchain in particular. I feel like if someone came along and created a solution for this purpose purely run on fees (basically a blockchain without the concept of token ownership) this would probably solve the problem IMO. Obviously there would be the issue of needing to somehow pay miners, but that part not being centralized isn’t necessarily an issue. However there’s not really any profit incentive to do so.

eragmus commented at 3:59 am on January 5, 2024: none

All these people really care about is being able to inscribe data in an immutable and decentralized manner, they don’t really care about it being done on BTC blockchain in particular. I feel like if someone came along and created a solution for this purpose purely run on fees (basically a blockchain without the concept of token ownership) this would probably solve the problem IMO. Obviously there would be the issue of needing to somehow pay miners, but that part not being centralized isn’t necessarily an issue. However there’s not really any profit incentive to do so.

Bitcoin is the best “immutable and decentralized” network in existence, so those who care about that part (& are willing to pay the fee to do so) have no incentive to use anything else. The ones who don’t care use a centralized shitcoin like Solana, or keep using Ethereum (out of inertia, or hope it’s a good enough medium option).

dzyphr commented at 4:15 am on January 5, 2024: none

All these people really care about is being able to inscribe data in an immutable and decentralized manner, they don’t really care about it being done on BTC blockchain in particular. I feel like if someone came along and created a solution for this purpose purely run on fees (basically a blockchain without the concept of token ownership) this would probably solve the problem IMO. Obviously there would be the issue of needing to somehow pay miners, but that part not being centralized isn’t necessarily an issue. However there’s not really any profit incentive to do so.

It is a complete fallacy to start imagining reasoning for organic usage in an instance where the entities funding it have literally admitted they are doing so in an effort to harm the Bitcoin network. They care about bloating the UTXO set and making regular transaction costs prohibitive for the end users of Bitcoin, something that can clearly be seen by all users.

eragmus commented at 4:44 am on January 5, 2024: none

“It only deterred it in the past, due to lack of economic demand. 36.2% of 2023’s fees came from non-traditional txs, so we no longer live in the old era that lacked demand.And the discount with segwit, if that’s what you mean, does the opposite of creating incentive to increase the UTXO set.”

You are again using the word demand completely ambitiously, there is little to no evidence that these are organic or sustainable flows of Bitcoin funding scam protocols. You are free to prove that the discount doesn’t exist, however asserting it does nothing. It exists, it is the reason we are talking here in the first place. You clearly haven’t even looked at this PR.

Re-read what I said re: discount. I did not say discount doesn’t exist.

As for ‘demand’ word: I have been obsessively following this issue since late Jan 2023, off and on, and all the information I have encountered (which includes what some directly involved in the arbitrary data ecosystem say publicly and privately to me + what bitcoiners actually involved in buying/selling arbitrary data tokens say) tells me the ‘demand’ does in fact exist. The massive fees paid ($250 million, more than 1/3 of total fees) is also one clear metric that there is real demand.

As for whether ‘demand’ is sustainable, no one can see the future, but:

If it’s NOT sustainable demand, then there is no problem (it is high time preference behavior to engage in filter changes and so on) +
If it IS sustainable demand, then the proposed solution is broken because it doesn’t factor in the real and significant economic demand (the response of changing PoW if miners don’t obey the more restrictive filters is ludicrous and just a meme).

re: “scam protocols” – This is a subjective analysis, and if that’s how you feel, you are entitled to not engage with those arbitrary data tokens. Yet, Bitcoin is neutral money that doesn’t concern itself with moralizing about ‘scam activity’ vs. ’non-scam activity’. Value is subjective, so those who want to engage with arbitrary data (no matter how stupid I think it is; I think it’s stupid personally and can’t ever imagine engaging, but I don’t think it can be generalized as ‘scam’) are entitled to engage with it.

“The point is the large economic demand is what will not allow it to be widely adopted, in terms of actually stopping miners from accessing those txs. Hence, the result of such filters is not achieving the goal, and rather would create an unrealistic mempool.”

The economic demand is not very large, it is demonstrably small compared to historical usage of actual Bitcoin not related to offchain scam tokens.

re: “scam tokens” – addressed already just now

re: “usage of actual bitcoin” – Value is subjective, what is considered ‘actual usage’ is defined very simply by valid txs ordered by fee rate. The highest fee rate txs get confirmed by miners with highest priority.

Economic demand represented by more than 1/3 of fees in 2023 being from arbitrary data is what is considered significant/large, by any objective metric. I don’t know what you are thinking of by historical usage, but you can pull up a chart from mempool.space or somewhere else, and see that in the year before arbitrary data protocols, i.e. 2022 (and also second half of 2021), there was almost zero fee pressure due to low tx demand. The network was basically dead from a fee-generating-activity point of view, which is not what the design of small-block Bitcoin was supposed to result in. And in general, we have had big fee spikes due to bull markets, with empty mempools in between. 2023 is basically the first year that was not a bull market that yet we had very significant fee pressure, and it was due to arbitrary data protocols.

“The fact that a bad result (of out of band txs) is already happening is not an argument to make the bad result be amplified by implementing foolish policy.It is an argument to address the reason for the current out of band txs, which I suppose would mean to allow mempool relay policies to reflect consensus policies.”

You haven’t provided any reasonable evidence as to why the policy is foolish, so I will dismiss that as a non sequitur. The mempool is currently not even close to facilitating the exact same transactions that end up in blocks, out of band relay has become a moot point because the current mempool situation already provides incentive for hosting it.

The policy is foolish, since the economic demand means miners will accept the txs out of band (with various negative consequences), as already explained by myself like a dozen (or at least 5?) times in this thread, and I’d hope you would have already browsed through the thread before commenting? Even sipa said it, and others said it more recently too.

Mempool is actually very close, as can be seen from high ‘health’ score on mempool.space of mined blocks.

And I already addressed the out of band point in the rest of my last response (saying that maybe we should eliminate datacarriersize limit, as the logical response, to decrease incentive for out of band payments).

“That’s what I think, and iiuc, it is also what @petertodd has logically reasoned. Bitcoin has perhaps matured to the point where standardness rules should reflect consensus rules. In practice, since op-return is the best place for arbitrary data, op-return limits should be removed (the opposite of what this proposal seeks).This will not just remove the contradiction to ensure logical consistency, but as I understand it, it would also have the benefit of reducing mining centralization force + mempool centralization force, by removing the need for those currently non-standard txs to be sent to large miners’ private mempools.”

You have simply failed to understand the irony of what I am pointing out, standardness rules are to enforce pro-Bitcoin rules as in things that improve not harm the scalability of the network. If they were not why not then why have something like a script interpreter anyway? Why not just send C++ code to the miners to execute? It would be more optimal that way to send arbitrary data.

‘Scalability of network’ does not make sense to be determined by policing which txs are “good” and which are “bad”. This is because valid txs that pay competitive fee rate is how it is determined. (Don’t want to repeat it for the nth time, but the filters are irrelevant in the face of significant economic demand, which is what exists). Bitcoin works on economic incentives.

Scalability is enhanced by increasing value density of txs for each layer 1 tx, like by improving the amortizing of layer 1 tx fee through layer 2 (like LN) networks that allow making many txs, and by increasing efficiency of layer 1 usage like sharing UTXOs between many people. This allows more transactions for a cheaper effective layer 1 fee, and also helps pay competitive fee vs. arbitrary data protocols’ txs and price some or all of it out.

“On the contrary, there is plenty of evidence. The mempool.space organization recently did the most comprehensive analysis I’ve seen, discovering 36.2% of 2023’s fees were paid by those txs.”

OK, and was Bitcoin started in 2023? Lets see the comprehensive all time analysis of normal transactions verses “tokens, stamps, NFT” and any other protocol relying on auxiliary software that is not officially recognized by Bitcoin core. You would see how utterly miniscule this is over that gap, but instead you provided a very obviously biased metric during the time at which the spam has been the heaviest.

re: “spam” – Value is subjective, what is considered ’not spam’ is defined very simply by valid txs ordered by fee rate. The highest fee rate txs get confirmed by miners with highest priority, while ‘spam’ includes txs without competitive fee rate. In Bitcoin, the real anti-spam anti-DoS mechanism is fee rate. The system operates on economic incentives. Bitcoin is anarchic, any technically valid tx is valid. Trying to moralize how Bitcoin is used is a fool’s errand + is anti-Bitcoin’s core ethos of its permissionless, censorship-resistant nature.

re: fees, from my prior answer in this response: “I don’t know what you are thinking of by historical usage, but you can pull up a chart from mempool.space or somewhere else, and see that in the year before arbitrary data protocols, i.e. 2022 (and also second half of 2021), there was almost zero fee pressure due to low tx demand. The network was basically dead from a fee-generating-activity point of view, which is not what the design of small-block Bitcoin was supposed to result in. And in general, we have had big fee spikes due to bull markets, with empty mempools in between. 2023 is basically the first year that was not a bull market that yet we had very significant fee pressure, and it was due to arbitrary data protocols.”

And I’ll add that there is nothing biased about this, as 2023 is precisely when everything changed in Bitcoin re: arbitrary data, as it is when Casey unveiled his inscriptions protocol + then it was followed by many other arbitrary data protocols. So the fees are focusing on when it actually began. We didn’t have such huge economic demand previously in Bitcoin’s history. That’s why I’m saying we are in a New Era, so the past thinking revolving around ‘spam filters’ is no longer relevant.

dzyphr commented at 4:54 am on January 5, 2024: none

And I’ll add that there is nothing biased about this, as 2023 is precisely when everything changed in Bitcoin re: arbitrary data, as it is when Casey unveiled his inscriptions protocol + then it was followed by many other arbitrary data protocols. So the fees are focusing on when it actually began. We didn’t have such huge economic demand previously in Bitcoin’s history. That’s why I’m saying we are in a New Era, so the past thinking revolving around ‘spam filters’ is no longer relevant.

Your bias is more than clear, I wont be listening to ideological BSV logic. If you have a serious response you are free to post it, but purely ideological biased comments are completely antithetical to our reason to be having this conversation in the first place.

And for a hint on how to lie better in the future, unbiased people don’t have to go around announcing their unbiased status. They simply do not have alterior motives.

dzyphr commented at 5:12 am on January 5, 2024: none

“re: “scam protocols” – This is a subjective analysis,”

No it literally is not. They are convincing new and uniformed users that there exists such a thing as satoshis that are more rare than other satoshis. Not only is this completely false and a scam, but if legitimized even a little bit would completely destroy the value proposition of anyone unfortunate enough to encounter this as their experience with Bitcoin.

Other protocols sell cheaply random generated JPEGs that are not even owned by the recipient in any realistic way, they are totally public domain. Another scam.

If you cannot see how this makes Bitcoin look like a scam and not money to be taken seriously you should feel sick to your stomach.

eragmus commented at 5:13 am on January 5, 2024: none

And I’ll add that there is nothing biased about this, as 2023 is precisely when everything changed in Bitcoin re: arbitrary data, as it is when Casey unveiled his inscriptions protocol + then it was followed by many other arbitrary data protocols. So the fees are focusing on when it actually began. We didn’t have such huge economic demand previously in Bitcoin’s history. That’s why I’m saying we are in a New Era, so the past thinking revolving around ‘spam filters’ is no longer relevant.

Your bias is more than clear, I wont be listening to ideological BSV logic. If you have a serious response you are free to post it, but purely ideological biased comments are completely antithetical to our reason to be having this conversation in the first place.

And for a hint on how to lie better in the future, unbiased people don’t have to go around announcing their unbiased status. They simply do not have alterior motives.

I don’t know what this insanity is, that you are replying with. I wrote a detailed response to explain how Bitcoin actually works in the real world, instead of in an idealistic fairytale world, and you cherry-picked one piece of it to reply to with nothing constructive, and somehow you thought this was acceptable? If you’re not interested in a proper conversation, that’s your prerogative, but don’t suddenly make insane ad-hominem baseless accusations (BSV, really, could you not go any lower?), and then expect to be taken seriously after such a display.

dzyphr commented at 5:15 am on January 5, 2024: none

eragmus

You are quite literally word for word repeating talking points made by BSV users who intend to harm Bitcoin by spamming the UTXO set and creating an unreasonably high fee environment in which the average end user is incentivised not to participate or if so forced into a custodial solution from which their Bitcoin fails to actually be a bearer instrument.

https://www.youtube.com/watch?v=-RswZDQTqsI

All the connections were made by a random pleb in this video, don’t think that because you pretend not to notice or actually are dumb enough not to notice that we wont. We notice the connections.

dzyphr commented at 5:22 am on January 5, 2024: none

Furthermore you have made so many straw-man arguments in your response that I can only consider it an insult on the face of it, if anyone seriously holds any weight to the complete misrepresentation of my points you made in the future I will respond to it in full detail.

eragmus commented at 6:20 am on January 5, 2024: none

You are quite literally word for word repeating talking points made by BSV users

I don’t care what BSV people say, and I don’t listen to them. Go argue the points themselves, if you can, don’t argue based on who makes which points.

harm Bitcoin by spamming the UTXO set

Inscriptions don’t do that, unless you mean STAMPS or something else.

And UTXO set increase affects pruned nodes’ storage requirement (not RAM, as is commonly misstated on Twitter), and based on conversation with some, only minimally. Regardless, they can pay less by using Inscriptions, yet pay more because they hear threats/antagonism from others to try to filter inscriptions, so they get worried. That’s the whole point of the argument that was made all the back in Jan 2023 by Poelstra, and previously by Casey, that op-return is the best way to do it, and interfering will worsen the issue.

creating an unreasonably high fee environment in which the average end user is incentivised not to participate or if so forced into a custodial solution from which their Bitcoin fails to actually be a bearer instrument

Then support efforts to actually scale Bitcoin, like improving layer 2 LN and ARK via efforts like CTV and/or other covenants proposals, and improving efficiency of layer 1. I already addressed this point. This PR’s filter change is a larp.

Broadly though, as I explained in a prior post to someone else, the txs where it is not economic to pay the tx fee can still be made if using layer 2 like LN (and sidechains like Liquid, with the new Aqua wallet recently released). So the problem is far overstated, and would be the case even if the bull market arrived and caused a big spike in tx demand and thus tx fees.

So this is not unique, and it is not unsolvable, and it can be improved by focusing energy on actually scaling Bitcoin.

All the connections were made by a random pleb in this video, don’t think that because you pretend not to notice or actually are dumb enough not to notice that we wont. We notice the connections

Yeah, typical conspiracy theories, and conspiracy theorists always sound the same (but sometimes they are right). We already had such behavior from bcashers during the block size controversies of the past, and they were famous for becoming deranged because they ended up on the wrong side of reality (sound familiar right now?). The conspiracy theory arguments basically revolve around guilt by association, speculation, misunderstanding, catastrophization, correlation vs. causation fallacy, etc.

But I’ll add that if BSVers are serious about wanting to push for a block size increase fork on Bitcoin, then most people in my camp (like 99%?) will obviously be 100% against it. So it’s not a real concern.

Bigblockers think they are harming bitcoin because they don’t understand how bitcoin works (since they supported big blocks vs. the small block design that bitcoin has). I saw another video where a BSVer is gloating about the fee increases and saying he is spinning up projects to build on bitcoin, but he showed he doesn’t understand bitcoin’s small-block design and how and why it works.

And whatever involvement BSVers have with the arbitrary data protocols ecosystem is not something that can be prevented. It’s obviously a free market.

And Udi trolls a lot as a marketing tactic, then some take him literally and seriously and miss the joke. But if he also pushes some contentious fork, then it’s the same story, it would be evaluated on merits, not blindly accepted obviously.

Furthermore you have made so many straw-man arguments in your response

Go prove it, don’t make things up because you lack arguments. I tried to directly respond to specific arguments, while also providing extra related information. Maybe you don’t understand what strawman argument means.

“re: “scam protocols” – This is a subjective analysis,”

No it literally is not. They are convincing new and uniformed users that there exists such a thing as satoshis that are more rare than other satoshis. Not only is this completely false and a scam, but if legitimized even a little bit would completely destroy the value proposition of anyone unfortunate enough to encounter this as their experience with Bitcoin.

Nah. First of all, what you are referring to here is “ordinals”, which is a collective hallucination Casey developed and some people chose to believe in, similar to the idea of numismatic collector coins. (People earlier last year were saying it is an attack on fungibility and making other irrational arguments, none of which were true if you applied the slightest logic to it.)

It is not false nor scam, it is what some choose to believe. Some people are collectors, they do what seems to be weird, like this. Some large mining pools, like F2pool iirc, already engage in “ordinal theory”, since there is a market for “rare sats” and so on. It cannot be stopped, and anyone can make any proposal, then it’s up to the market if it cares or not.

Other protocols sell cheaply random generated JPEGs that are not even owned by the recipient in any realistic way, they are totally public domain. Another scam.

I don’t pretend to be an expert or understand any of this deeply btw, since I don’t do it myself, but it is not a “scam” to buy a jpeg, stupid maybe depending what you value, but not a scam, unless the buyer is being misrepresented about what they are buying. If the buyer knows what it is, then it’s not a scam, there is no fraud, they own the private key to the jpeg asset and so claim ownership, and then can and do engage in market buy/sell transactions with others who care about such stuff.

If you cannot see how this makes Bitcoin look like a scam and not money to be taken seriously you should feel sick to your stomach.

People are gambling, like they gamble with lottery tickets/casinos/penny stock trading/leveraged trading/etc. Gambling is not scamming. I know it’s popular to call anything and everything a scam, but scam only comes into play if fraud is involved. If the buyer is aware of the situation, it cannot be a scam.

And, as I already said, ‘scam or not’ is irrelevant to how the Bitcoin protocol, which is neutral, functions. This is not a centralized system. This is a decentralized system. You should think about what that means, instead of trying to force your morality onto a neutral value-transfer protocol like Bitcoin, in which value is subjectively determined (just like Bitcoin itself is subjectively valuable by some, and not by others who claim it is virtual nothingness).

It does not make Bitcoin look like a scam, any more than people using Bitcoin to actually scam people (like with Plus Token or whatever that was called, and the other scams done over the years across the world using Bitcoin) made Bitcoin look like a scam. That is to say, I guess it’s subjectively determined again. Some will not be interested in a decentralized permissionless system (with everything it entails – they’ll go to centralized fiat land), while others will respect the unique value offered by a decentralized system.

You can only control how you yourself use Bitcoin, NOT how others use Bitcoin.

You need to learn to remove your ego from Bitcoin. Bitcoin is not about you.

People with big egos in Bitcoin’s history tended to decide they knew better than Bitcoin, and tragedies ensued from that fatal error. This situation is not the first time it is starting to happen, and it won’t be the last time.

DoctorBuzz1 commented at 6:33 am on January 5, 2024: none

eragmus, there are ALREADY out of band Txs happening with ViaBtc…. See their latest block with 20 to 30 sat/vByte Txs: https://mempool.space/block/00000000000000000001b26d226a7993950d14bec4acce2d85eeb9974a63d9bf

It seems to me that there are 2 camps here.. Those that think the standard Txs (including IsDust() ) should be defined for the benefit of the monetary network as a whole…. and then those, who think that these standard Txs should be defined by miners, pools on an individual basis. GetDustThreashold() includes the following comment:

“If you’d pay more in fees than the value of the output to spend something, then we consider it dust.”

These standard Tx policies are obviously GOOD for the efficiency of the monetary network, and dust obviously shouldn’t be hardcoded at 3 sat/vByte if the network never again drops below 20~40 sat/vByte.

The integrity of the network and the real worth to miners is not short-term fees, but long-term growth and adoption of the MONETARY network itself. “Permisionless file storage” and dusty tokens that price out monetary Txs do NOT make a good combatant to the central banks, which IS the purpose of Bitcoin.. as evidenced in the Genesis Block itself. Nowhere did Satoshi Nakamoto mention the right to “trustlessly inscribe cartoons”, but he definitely mentioned that Bitcoiners would want to keep the network slim, efficient, and focused. I truly hope that this goal is not lost on others, miners and core devs included.

Most people know that to truly understand Bitcoin itself, you need to study cryptography, economics, programming, etc. This specific issue definitely needs some study in history and even language (defining things like “Bitcoin” itself, “standard Tx”, “dust”, etc. To throw all this out because it makes miners happy in the short-term is… well, short-sighted to say the least, while a large portion of Bitcoiners would say it’s sacrilegious. To take something as sacred as freedom money, a tool to exit the fiat system, and then boast about fiat gains, is completely losing sight of the mission.

alpeshvas commented at 6:34 am on January 5, 2024: none

This has now become a complete noise discussion.

dzyphr commented at 6:38 am on January 5, 2024: none

your longer paragraph has only proven my point further, until I see calm and collected responses to my original counterarguments to Pieter’s false claims about the current attack on the Bitcoin network, I refuse to sift through straw man arguments formulated by someone who talks like Craig Wright and respond to each of them individually. As you can see someone else has already pointed out your base fallacy about out of band txs.

dzyphr commented at 6:39 am on January 5, 2024: none

This has now become a complete noise discussion.

maybe then contribute factual responses instead of ones based in pure speculation, ideology, and ignorance of publicly available facts.

eragmus commented at 6:50 am on January 5, 2024: none

eragmus, there are ALREADY out of band Txs happening with ViaBtc…. See their latest block with 20 to 30 sat/vByte Txs: https://mempool.space/block/00000000000000000001b26d226a7993950d14bec4acce2d85eeb9974a63d9bf

Read my arguments more carefully? Nowhere did I deny out of band txs are already happening. I said they will only get worse, if filtering is used as a policy response. And I said out of band txs can be logically reduced, if relay policies are aligned with consensus policies, instead of being out of sync and thus creating a reason for out of band txs.

The integrity of the network and the real worth to miners is not short-term fees, but long-term growth and adoption of the MONETARY network itself. “Permisionless file storage” and dusty tokens that price out monetary Txs do NOT make a good combatant to the central banks, which IS the purpose of Bitcoin.. as evidenced in the Genesis Block itself. Nowhere did Satoshi Nakamoto mention the right to “trustlessly inscribe cartoons”, but he definitely mentioned that Bitcoiners would want to keep the network slim, efficient, and focused. I truly hope that this goal is not lost on others, miners and core devs included.

Most people know that to truly understand Bitcoin itself, you need to study cryptography, economics, programming, etc. This specific issue definitely needs some study in history and even language (defining things like “Bitcoin” itself, “standard Tx”, “dust”, etc. To throw all this out because it makes miners happy in the short-term is… well, short-sighted to say the least, while a large portion of Bitcoiners would say it’s sacrilegious. To take something as sacred as freedom money, a tool to exit the fiat system, and then boast about fiat gains, is completely losing sight of the mission.

Bitcoin works on economic incentives, not altruism. This is a core principle that needs to be internalized.

And fees are exactly how bitcoin’s security model is designed, fees and price of bitcoin. But price of bitcoin can’t be controlled, and can be impacted by events out of our control, like macroeconomic climate and other global situations. Only fees are under our control, in terms of generating use cases that pay significant fees to offset the exponentially-declining subsidy paid by Bitcoin’s inflation. The integrity of the network longterm revolves around tx fees. And fees matter because miners get paid by fees, longterm, to secure the network, as the subsidy becomes too nominal to matter.

I’ve also stated several times in this thread (and surely others have too?), and it should be obvious if you think about it a little, that pricing out of lower-value normal txs is not a real concern, if using layer 2 networks like LN (and, in response to high fees, we recently got an easy to use wallet, Aqua, for sidechains like Liquid) to amortize cost of layer 1 tx fee. Actually if you send LN tx directly from LN-compatible exchange to a wallet, or Liquid bitcoin from exchange to wallet, like with Aqua, and then pay with only LN or Liquid, then you completely escape the layer 1 fee. – And to focus efforts on actually useful efforts like scaling bitcoin via improving efficiency of layer 2 networks like LN and ARK, via CTV or other covenant proposals.

This is getting so repetitive. It’s like people don’t care to actually read the prior discussion and understand it, before repeating the same old arguments over and over and over…

desi-bitcoiner commented at 6:59 am on January 5, 2024: none

This has now become a complete noise discussion.

This conversation seems noise only to those who don’t want to hear the arguments of the folks who want to put better spam filters in place.

For everyone else, there’s tons of reasoning to help understand the issue better and hopefully get the point across THAT UPDATING SPAM FILTERS IS NEED OF THE HOUR and core cannot run away from it.

dzyphr commented at 7:07 am on January 5, 2024: none

“Read my arguments more carefully? Nowhere did I deny out of band txs are already happening. I said they will only get worse”

If they are already happening it literally does not matter if they get any worse, your arguments are incredibly weak and you have shown that you do not understand the basic situation and or are maliciously ignorant.

dzyphr commented at 7:10 am on January 5, 2024: none

“Bitcoin works on economic incentives”

is not just some magical phrase you can throw around and make your assertions true. the incentives for full node runners are becoming smaller and smaller every single day. this demonstrably hurts decentralization of bitcoin. you people would care about that if you actually cared about the state of the mempool, but instead you are concern trolling that setting a filter to EVENLY DISTRIBUTE COST for all transactions will kill the mempool. Your fallacious arguments are tiring.

dzyphr commented at 7:14 am on January 5, 2024: none

I’ve also stated several times in this thread (and surely others have too?), and it should be obvious if you think about it a little, that pricing out of lower-value normal txs is not a real concern, if using layer 2 networks like LN (and, in response to high fees, we recently got an easy to use wallet, Aqua, for sidechains like Liquid) to amortize cost of layer 1 tx fee. Actually if you send LN tx directly from LN-compatible exchange to a wallet, or Liquid bitcoin from exchange to wallet, like with Aqua, and then pay with only LN or Liquid, then you completely escape the layer 1 fee. – And to focus efforts on actually useful efforts like scaling bitcoin via improving efficiency of layer 2 networks like LN and ARK, via CTV or other covenant proposals.

You can only control how you yourself use Bitcoin, NOT how others use Bitcoin.

It is funny how you say Bitcoin isn’t about you however you think you can tell me what I can and cannot find to be a concern. Your hypocrisy is plenty evident. You should try having consistent arguments next time you blatantly lie to people who are more informed about the topic than you are. Just a couple years ago people like P Wuille himself were saying he does not even know how lightning works at all, now we are saying its totally cool to thrust end users into it (we know it is not ready for that, far too many issues with routing to scale, current liquidity / volume is garbage compared to real financial systems). I have studied lightning myself, I have several channels, it is NOWHERE NEAR prepared to scale bitcoin if we do not deal with UTXO set spam and mempool fee over-payment spam / constant inorganic end user prohibitive fee spikes first. It proves ignorance of lightning and timelock based protocols IN GENERAL to misunderstand why prohibitive l1 fees coming from a publicly announced inorganic source that intends to attack the network is not positive.

eragmus commented at 7:38 am on January 5, 2024: none

“Bitcoin works on economic incentives”

is not just some magical phrase you can throw around and make your assertions true. the incentives for full node runners are becoming smaller and smaller every single day. this demonstrably hurts decentralization of bitcoin. you people would care about that if you actually cared about the state of the mempool, but instead you are concern trolling that setting a filter to EVENLY DISTRIBUTE COST for all transactions will kill the mempool. Your fallacious arguments are tiring.

It’s true, and it’s not my problem if you don’t understand how Bitcoin works, or refuse to accept it.

As for node runners, as usual, this was addressed already in this thread, if you bothered to read it and understand the prior discussion, instead of spamming the thread. Or you could think for yourself, and actually figure out the answer? – Which is that full node runners’ storage is not affected worse by this situation vs. what would happen if the blocks were full of “normal” txs. And consensus already agreed to the current block size limits during the segwit fork, so the growth limits were agreed to and is bounded, and it was understood that growth rates are not sufficiently problematic for full nodes (and this was the case in 2017 or when segwit was implemented, while now it’s 2024, 6 years later, with improved technology and even less concern).

It is funny how you say Bitcoin isn’t about you however you think you can tell me what I can and cannot find to be a concern.

What I said applies to the one changing Bitcoin. That would be you.

people like P Wuille himself were saying he does not even know how lightning works at all, now we are saying its totally cool to thrust end users into it (we know it is not ready for that, far too many issues with routing to scale, current liquidity / volume is garbage compared to real financial systems)

Plenty of people use it and have mostly no problems.

And it is only 1 option I gave. You can support efforts, as I already said, to improve LN functionality, like with CTV or other covenant proposals.

And you can use Liquid sidechain, via the Aqua wallet.

But you are not entitled, as bcashers also felt entitled, to use Bitcoin layer 1 for lower-value txs despite being unable to afford the layer 1 tx fee. Bitcoin doesn’t scale via layer 1, it scales via other layers. We established this during block size controversy, and if you don’t agree with this decision, consider using bcash instead?

source that intends to attack the network

Using bitcoin in a way you disagree with, and paying for the privilege with competitive tx fees, is not an “attack”. What’s an attack is feeling entitled to pay low fees on layer 1 to make txs on Bitcoin, and trying to bully developers to cater to your false understanding of Bitcoin.

“Read my arguments more carefully? Nowhere did I deny out of band txs are already happening. I said they will only get worse”

If they are already happening it literally does not matter if they get any worse, your arguments are incredibly weak and you have shown that you do not understand the basic situation and or are maliciously ignorant.

If that’s what you think about my arguments, and those of others here who basically make similar or same arguments, you have a few options (since Bitcoin is not a democracy & since Core obviously lacks rough consensus to be able to implement the proposed change):

Use Knots (which has your desired filter policies), OR fork Core (to adjust the policies yourself) and use the forked Core, thereby continuing to use Bitcoin.
Sell your bitcoin (if you own any?), and buy OR create a cryptocurrency that better aligns with what you want (something more centralized that you can take charge of, so you are able to make whichever changes are desired & whenever they are desired).

Good luck.

PerpetualWar commented at 7:41 am on January 5, 2024: none

It is highly troubling to see this discord between people involved in bitcoin.

As someone who recently joined the community, I find it unsettling.

My stance is that monetary proposition of bitcoin is the one and only thing that core team must be focused on, but now I see that goal is lost, intentionally or not.

Everyone like to spout ‘decentralization’, but how is pushing people to sidechains not centralization is beyond me.

I find argument that everything will be solved with L2/L3, especially coming from core devs,… Wrong for the lack of better word. Core team imho should be focusing on fixing existing issues with L1 and one of those problems is staring us in the face.

Sorry for being blunt.

eragmus commented at 7:55 am on January 5, 2024: none

It is highly troubling to see this discord between people involved in bitcoin.

As someone who recently joined the community, I find it unsettling.

Bitcoin is a decentralized system, so discord is natural. The guy I’ve been talking with is particularly nasty, but this is fortunately not the norm in the discussion thread, if you read the rest of it.

My stance is that monetary proposition of bitcoin is the one and only thing that core team must be focused on, but now I see that goal is lost, intentionally or not.

I know people think of it idealistically this way, as did I for a long time (actually until Jan of 2023, when I thought about it more deeply), but it is not realistic to force people to use their bitcoin in one narrow manner. Bitcoin is a permissionless network. People will inherently use it for whatever they personally find useful.

Some will hodl their bitcoin, and almost never make a tx.
Some will spend it, or not spend it based on bad tax policies and reporting requirements and price volatility and lack of consumer protection and lack of ease of use and so on.
Some will gamble with it, in 100 different ways, either sending it back and forth between wallet and exchanges for trading and arbitrage, or with jpegs.

It is not a black/white situation either, where it’s either 100% monetary use or 0% monetary use. It will be based on competitive tx fee rates determining the proportion of uses. Basically, the market will decide the price of miners’ precious layer 1 block space (fee rate), and what proportion of use cases by the buyers.

Everyone like to spout ‘decentralization’, but how is pushing people to sidechains not centralization is beyond me. I find argument that everything will be solved with L2/L3, especially coming from core devs,… Wrong for the lack of better word.

Decentralization comes in degrees.

Layer 1 offers most decentralization, yet has the highest tx fee and 10 min average (yet variable) block time. = high economic value txs that can afford a high tx fee
Layer 2 like LN has a little less decentralization, yet has very low tx fee and instant reliable transaction speed. – low/medium economic value txs that can afford a low tx fee
Sidechain like Liquid is perhaps semi-decentralized (globally distributed federation model), but has low tx fee and 1 min block time and confidential transactions for privacy (etc.). – low/medium economic value txs that can afford a low tx fee

There are tradeoffs across different layers. This is how blockchain works to remain decentralized. Blockchain is not magic.

Core team imho should be focusing on fixing existing issues with L1 and one of those problems is staring us in the face.

Simple fact of the matter is it can’t be fixed (without some type of fork), and the reasons why have been explained ad nauseam in this thread.

And a fork would obviously be a very big deal; first, it would need to be figured out (one idea is implementing Confidential Transactions on Bitcoin, just as it is on the Liquid sidechain), and then it would need to gain rough consensus that pros sufficiently > cons.

desi-bitcoiner commented at 8:59 am on January 5, 2024: none

I hope the following information helps in adding clarity to the thought process of folks who advocate otherwise:

“Satoshi made only 1 mistake, which I believe is the root of the confusion among some Bitcoiners who defend spam.

He used the same name bitcoin - to define two different elements: the asset, and the network.

Although they are interdependent, they possess very distinct properties.

The network is decentralized, permission-less, and resistant to censorship - not the asset.

The asset is divisible, portable, scarce, and durable - not the network.

Crucially, to benefit from the asset’s properties, one must have access to the network, and vice versa.

For instance, imagine holding a certain amount of BTC in self-custody, but facing prohibitively high fees that prevent you from moving it, essentially blocking access to the network. In this scenario, the Bitcoin loses its portability and divisibility.

Conversely, consider running 100 nodes, but for some reason being unable to acquire the asset.

Those who justify spam under the pretext of “Bitcoin is for enemies” fail to grasp this crucial distinction between the asset and the network.

Bitcoin - the asset - is for adversaries.

However, Bitcoin the network must be safeguarded at all costs, or we risk losing all the properties that define Bitcoin.”

Credit for this information goes to @matteopelleg

My argument would be that Bitcoin - the network - needs to be protected from spam RIGHT NOW and if corporate sponsored devs at core with merge rights are incompetent in understanding the situation or to put the solution in place, they should step down and let other non corporate funded, community oriented, technically more skilled devs take control of the situation and make efforts to fix the spam issue.

Core does not belong to devs sponsored by one or two companies. It’s a shared code and we all need to take responsibility of fixing the issue of spam.

Thank you.

glozow commented at 12:12 pm on January 5, 2024: member

This is a summary of the arguments on the PRs, mailing list posts, and some tweets.

ACKs by reason

If you feel I have misrepresented something you said, feel free to let me know.

“Stop inscriptions, which are spam”

These types of transactions are used for ordinals, NFTs, data-carrying, or some use case that is not financial transactions. This is “spam” and undermines the utility of Bitcoin for payments due to high transaction traffic and fees.

“these spam transactions make the real usefulness of Bitcoin more and more difficult to use.” #28408 (comment)
“If Bitcoin is MONEY (it is!)… then non-monetary Txs should be reduced as much as possible” #28408 (comment) https://github.com/bitcoin/bips/pull/1408#issuecomment-1430240866
This is a “misuse of the network, which was meant for financial transactions (the whitepaper, name and code point to this)… data storage… was not an intended use case” https://github.com/bitcoin/bips/pull/1408#issuecomment-1430883728
This is causing “network congestion” and “higher fees or slower processing times” and this is a “DDoS attack” #28408 (comment)
“issue is not with the inscriptions but with the astronomical fees in general” #28408 (comment)
“Bitcoin - the network - needs to be protected from spam RIGHT NOW” #28408 (comment)

“Inscriptions and embedded data harm the network”

These types of transactions are costly for node operators and are harming the network in some way.

“The transactions targeted by this pull-req. are a very significant source of prohibitive cost for regular node operators” https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1735381194
“These transactions affect the decentralization of the network by increasing the cost of operating the nodes” https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1735111336
“disproportionate and excessive storage of large data directly on the blockchain” #28408 (comment)

“People want this”

Clearly there is user desire and a specific use case, so Bitcoin Core should offer this option. The alternative is that people write and run patches, which can be unsafe.

“Node runners need a builtin option to ignore all modern forms of datacarrying so they don’t have to resort to manually patching their nodes.” #28408 (comment)
“if developers do not help node runners defend themselves against this attack, they may have to resort to misappropriate means to strengthen their defense.” #28408 (comment)
“I want to be in charge of my mempool policy and I want to decide what is spam and what is not” #28408 (comment)
miners would want this “if they believed Bitcoin to be money and not just a permisionless, immutable blockchain, they would indeed filter the spam to make the MONETARY network usable” #28408 (comment)

“This just fixes datacarriersize to work as intended”

We limit data-carrying in OP_RETURNs. This should be applied to all types of data-carrying. This is the “intent” of -datacarriersize.

luke-jr considers it a bug that -datacarriersize was not updated with other types of data-carrying, when segwit and taproot were introduced, and filed this as a bug/vulnerability https://github.com/advisories/GHSA-9x7v-86jh-jjch
“Bitcoin Core already standardizes the insertion of arbitrary data above 83 bytes and inscriptions are a diverted way to bypass this limit so it is a bug fix.” #28408 (comment)
“Spam is already filtered at various levels in the code, and has been for over a decade. All this PR does is apply an existing limit on datacarriersize to data carrying of a different form of data carrying that is clearly an unintended exploit.” #28408 (comment)
“What is the purpose of the datacarrier limit if not to impose a limit on arbitrary data stored in transactions?” https://x.com/cguida6/status/1742723175543124294?s=20
PR #29173, “The purpose of this standardization rule is not to target only the data contained in the raw scriptPubKey, but all forms of arbitrary data.” #29173

NACKs by reason

Here is a summary of the arguments against this PR.

“This will not prevent inscriptions”

This will not stop inscriptions. It is unlikely (because it’s incentive-incompatible) that miners will adopt this.

“If only Ocean pool uses this and it remains a relatively small pool, it will have no effect. If it is widely deployed, it’s trivial to circumvent.” #28408 (comment)
“Beyond the immediate loss of inscription reveal transaction fee revenue, this
would appear to be long-term incentive-incompatible for miners.” #28408 (comment)
“It is very unlikely that minres will give up that source of revenue. Censoring those transactions would simply encourage the development of private mempools” https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1735079576
“The ordinals transactions will end up in the blockchain anyway, bypassing the mempool, so this PR does nothing to solve/mitigate the problem” #28408 (comment)
“To the extent that this is an attempt to not just not see certain transactions, but also to discourage their use, this will at best cause those transactions to be routed around nodes implementing this, or at worst result in a practice of transactions submitted directly to miners, which has serious risks for the centralization of mining.” #28408 (comment)

“We cannot write code to detect all data-carrying”

In general, we cannot stop data-carrying transactions. Inscriptions exist amongst numerous ways to embed data (which we cannot ever fully encompass).

“There’s no universal way to filter all present and future datacarrying styles. This invites an endless cat and mouse game inside very critical code paths.” #28408 (comment)
trying to stop all data-carrying “will cause this code to grow in complexity. And every time that happens there’ll be a lot of pressure on maintainers to push it through quickly ’to stop the spam’” #28408 (comment)
“as near as I can tell there is no sensible way to prevent people from storing arbitrary data in witnesses without incentivizing even worse behavior and/or breaking legitimate use cases.” https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021372.html

“This change is potentially harmful”

This PR, which changes the default mempool policy, is potentially harmful to the individual node operator and to the network.

Excluding transactions that will be mined is harmful to a node. “The point of participating in transaction relay and having a mempool is being able to make a prediction about what the next blocks will look like. Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability” #28408 (comment)
Changing default policy is generally dangerous. Making previously-standard transactions nonstandard means that some people may now find it much more difficult to access their funds. “By changing the default, instead of being opt in, it represents a potentially disruptive and unwelcome change in behavior for miners relying on Bitcoin Core to construct block templates… this would represent a mild form of confiscation, and should be avoided.” #28408 (comment)

Other points against the PR

Generally, using mempool policy to discourage usage is now ineffective, even though it has been used that way in the past.

“While non-standardness has historically been used to discourage burdensome practices, I believe this is (a) far less relevant these days where full blocks are the norm so it won’t reduce node operation costs anyway and (b) powerless to stop transactions for which an existing market already exists - one which pays dozens of BTC in fee per day.” #28408 (comment)

Review

Concept NACK. Trying to keep the points that have already been said short:

This will not prevent ordinals. Given the high fees, this policy is incentive-incompatible to adopt as a miner. Even if this relay policy is adopted, this has not stopped ordinals in the past (4MB tx in mempool.space, in ordiscan, as tweeted).
This change is likely harmful to the node by making its mempool exclude transactions that will be mined. This is a restriction to default policy, which can impact many users beyond an individual node operator, including making it difficult for people to access existing funds, and disrupting compact block relay.
This will not prevent data-carrying transactions. See above. It may be best to leave the methods that are most efficient wrt network resource costs.
People are calling this “spam” because they don’t like ordinals. While I also personally think Bitcoin is best used for financial transactions, I disagree with this framing of “spam.” In transaction validation and relay logic, we should define spam on the basis of network resources consumed and whether those costs are well bounded and/or paid for, not on the basis of use case. We have no way of detecting whether a bunch of bytes are real/legitimate/useful and, even if we could, it is not protocol development’s place to decide which use cases of Bitcoin are legitimate and which ones aren’t.

jangorecki commented at 12:53 pm on January 5, 2024: none

@glozow You missed the most important, censorship

murchandamus commented at 2:12 pm on January 5, 2024: contributor

Concept NACK

Purpose of `datacarriersize`

datacarriersize refers to the payload of OP_RETURN outputs, the output type that was introduced as a data carrier to provide an alternative for more harmful ways of embedding data. At that time, there was a worry that any blockspace production in excess of the demand from monetary transactions would be filled for cheap since demand for highly replicated perpetual storage is unbounded. Bounding standard transactions to a single data carrier output per transaction with a limited weight didn’t prevent users from using blockspace in this manner, but discouraged that use by increasing the overhead and cost.

Today, there is sufficient demand for blockspace from monetary transactions that blocks were full most of the week even before inscriptions got traction. As such, when the inscription hype brought additional demand to the network, a robust blockspace market emerged that required competitive bids for every vbyte of blockspace. We have been expecting a similar situation in a few years if adoption continued to increase just from additional demand of monetary transactions. The current blockspace market is a valuable preview for wallet developers, Bitcoin advocates, and users to scrutinize their design and narrative. There would be little need to introduce protective mempool policies such as datacarriersize today: when blocks are full, the price of blockspace already discourages low-value use on its own.

Underlying motivation of discouraging inscriptions

Clearly this PR is largely supported by those that would like to discourage inscriptions. While I agree that inscriptions and especially BRC20 tokens seem idiotic, their use of the witness section is far less harmful than many other ways of embedding data in the blockchain.
However, this patch would fail to prevent relay of inscriptions. Bitcoin users are spending hundreds of bitcoins in fees on inscription transactions per week. If Bitcoin Core were to release a version that filters inscriptions in the manner proposed here, the inscription enthusiasts could maintain relay of inscriptions on the network by ensuring that a small fraction of the nodes on the network does not filter inscriptions.—This patch would trivially fail to achieve its goal because the proponents of the discouraged behavior would not participate in enforcing it.—The inscription proponents would be inadvertently supported by the large count of nodes that run older versions.
Further, it is obvious that a block template built from a filtered mempool must result in a lower total block reward than one built from all unconfirmed transactions. This means that any miners filtering inscriptions reduce their own revenue to the benefit of non-filtering miners. This leads to a prisoner’s dilemma where the reward for dissent is greater as more miners filter. Therefore campaigning for miners to filter inscriptions seems self-defeating in a world where a significant portion of blockspace is purchased for inscription transactions.

In the end, users running this patch still process blocks including inscriptions. They only harm their own feerate estimation, slow down their block validation, and are less useful peers to other nodes. It seems to me that the proposed change here is more harmful than beneficial.

cliobitcoinbank commented at 2:18 pm on January 5, 2024: none

eragmus

You are quite literally word for word repeating talking points made by BSV users who intend to harm Bitcoin by spamming the UTXO set and creating an unreasonably high fee environment in which the average end user is incentivised not to participate or if so forced into a custodial solution from which their Bitcoin fails to actually be a bearer instrument.

https://www.youtube.com/watch?v=-RswZDQTqsI

All the connections were made by a random pleb in this video, don’t think that because you pretend not to notice or actually are dumb enough not to notice that we wont. We notice the connections.

How Sarcasm Works:

Maxi: “Did you eat another doughnut?” Ordinal User: “Yes, and I ate it just to spite you” Maxi: “Ordinals users only care about spreading pain, they are willing to eat not because they are hungry, but just to destroy good food and deny others the opportunity for nourishment.”

I dont think youll be able to reliably cling to a video of BSVers trolling you as evidence of the total illegitimacy of ordinals if irony sarcasm and spite exist, and I checked, they do exist. It makes sense after the reaction to ordinals that people might overstate themselves in the way designed to bother you as they have here. “We’re here to ruin bitcoin” is not a sincere statement, it’s meant to mock your reactions which seems beyond your understanding or maybe just your honesty.

cliobitcoinbank commented at 2:22 pm on January 5, 2024: none

“Bitcoin works on economic incentives”

is not just some magical phrase you can throw around and make your assertions true. the incentives for full node runners are becoming smaller and smaller every single day. this demonstrably hurts decentralization of bitcoin. you people would care about that if you actually cared about the state of the mempool, but instead you are concern trolling that setting a filter to EVENLY DISTRIBUTE COST for all transactions will kill the mempool. Your fallacious arguments are tiring.

Except that most new noderunners are ordinals indexers and inscribers. Ordinals are here to stay, fork off or accept it.

ajtowns commented at 3:14 pm on January 5, 2024: contributor

Seems pointless to argue the politics of the change when CI doesn’t even pass:

0tests.cpp:1570:35: error: use emplace_back instead of push_back [modernize-use-emplace,-warnings-as-errors]
1
2test/script_tests.cpp(1492): error: in "script_tests/script_DataCarrierBytes": check 13 == (CScript() << zeros(11) << OP_DROP).DatacarrierBytes() has failed [13 != 0]

There are two different aspects of mempool policy: what you can configure the software to enforce, and the defaults. From that view, this PR is flawed in two ways:

it couples the policy on OP_RETURN output size and the new limits on data embedded in redundant script code, so that it’s impossible to configure your node in a way that matches the default policy for 26.0 and earlier releases
it changes the default policy to reject transactions with data embedded in redundant script code in a way that would reject a significant amount of high feerate transactions, and thus would likely not match the policy adopted by the majority of hashrate

So that’s an Approach NACK for me.

I believe core’s strategy for PRs that add disabled-by-default mempool/relay rules is that it’s fine for add config options if people want to set their own rules for their own node, even if that will result in them diverging from the network at large, provided the code supporting the option is reasonably small/self-contained/maintainable, and there’s at least some demand for the option. On that basis I expect I’d be happy to invert that nack if the PR were modified to introduce an independent option for blocking txs with redundant script code that defaulted to off. (And also fixed the bugs that are resulting in CI failure, obviously)

(Note that Knots has also recently introduced (see 1 and 2) a default limit of 1650 bytes for scripts, which eg limits CHECKSIGADD-based multisig to about k/50; rather than up to about 1000/4000. I’m not sure there’s actually any demand for that change in additional to filtering inscriptions, but if there is, presumably it would also be acceptable as a default-off policy option in core)

I expect I’d remain a nack on changing the default unless there was clear evidence that a majority of hashrate was either supportive-of or indifferent-to the change, eg a majority of blocks were already excluding these transactions. (ie, I’d accept that as resolving most of the concerns expressed in sipa’s comment)

Personally I think changes here (whether adding an option or changing the default) is unlikely to have any effect outside of generating tweets/articles/podcast episodes, and that in the unlikely event that it did have any effect, that would only be for witness-embedded data to use a different pattern. (ie, basically, what Murch said)

ben-arnao commented at 3:25 pm on January 5, 2024: none

All these people really care about is being able to inscribe data in an immutable and decentralized manner, they don’t really care about it being done on BTC blockchain in particular. I feel like if someone came along and created a solution for this purpose purely run on fees (basically a blockchain without the concept of token ownership) this would probably solve the problem IMO. Obviously there would be the issue of needing to somehow pay miners, but that part not being centralized isn’t necessarily an issue. However there’s not really any profit incentive to do so.

Bitcoin is the best “immutable and decentralized” network in existence, so those who care about that part (& are willing to pay the fee to do so) have no incentive to use anything else. The ones who don’t care use a centralized shitcoin like Solana, or keep using Ethereum (out of inertia, or hope it’s a good enough medium option).

The incentive would be lower fees as they don’t need to compete with people wanting to make legitimate btc txs

ben-arnao commented at 3:26 pm on January 5, 2024: none

All these people really care about is being able to inscribe data in an immutable and decentralized manner, they don’t really care about it being done on BTC blockchain in particular. I feel like if someone came along and created a solution for this purpose purely run on fees (basically a blockchain without the concept of token ownership) this would probably solve the problem IMO. Obviously there would be the issue of needing to somehow pay miners, but that part not being centralized isn’t necessarily an issue. However there’s not really any profit incentive to do so.

It is a complete fallacy to start imagining reasoning for organic usage in an instance where the entities funding it have literally admitted they are doing so in an effort to harm the Bitcoin network. They care about bloating the UTXO set and making regular transaction costs prohibitive for the end users of Bitcoin, something that can clearly be seen by all users.

where is the evidence that the majority of inscription fees are being motivated by network harm as opposed to immutable record of information?

achow101 commented at 3:30 pm on January 5, 2024: member

It’s abundantly clear that this PR is controversial and, in its current state, has no hope of reaching a conclusion that is acceptable to everyone. At this point in time, I see no reason to leave this open and to continue to send notifications for the constant back-and-forth stalemate discussion.

achow101 closed this on Jan 5, 2024

bitcoin locked this on Jan 5, 2024

datacarriersize: Match more datacarrying #28408

Code Coverage

Reviews

Conflicts

ACKs by reason

“Stop inscriptions, which are spam”

“Inscriptions and embedded data harm the network”

“People want this”

“This just fixes datacarriersize to work as intended”

NACKs by reason

“This will not prevent inscriptions”

“We cannot write code to detect all data-carrying”

“This change is potentially harmful”

Other points against the PR

Review

Purpose of datacarriersize

Underlying motivation of discouraging inscriptions

Purpose of `datacarriersize`