datacarrier and permitbaremultisig

[snerd]

I have a node connected to mine that has instructions in the User Agent field...............

"stop the spam on your own node, set datacarrier equals 0 and permitbaremultisig equals 0"

Are these valid commands? Are they safe? Do I want to enter them? What exactly do they do? What is the exact command to enter them if I do?

Thanks!
snerd

[snerd]

I have a node connected to mine that has instructions in the User Agent field...............

"stop the spam on your own node, set datacarrier equals 0 and permitbaremultisig equals 0"

Are these valid commands? Are they safe? Do I want to enter them? What exactly do they do? What is the exact command to enter them if I do?

Thanks!
snerd

These instructions are suggestions to configure your Bitcoin node in order to amplify its security
Yes they are valid and safe

If you are going to enter the command with Bitcoin core


1. Open `bitcoin.conf` file (usually in `~/.bitcoin/` directory)
2. Add these two lines:


```
datacarrier=0
permitbaremultisig=0
```

Then
Save and restart your Bitcoin Core node.

Let me know if this doesn't work

Ah yes, the config file. I should have known that! I've been running my node on a Win11 machine, with the data directory on a separate drive, so the .conf I wanted was in E:\Bitcoin. Yes, it works as you stated, thanks!

[ABCbits]

Bitcoin Core source code provide short explanation about those configuration.

Code:

# Relay and mine data carrier transactions (default: 1)
#datacarrier=1

# Relay transactions creating non-P2SH multisig outputs (default: 1)
#permitbaremultisig=1

AFAIK it means,
1. datacarrier=1 allows you broadcast transaction with OP_RETURN.
2. permitbaremultisig=1 allows you to broadcast multi-signature transaction which use P2MS (Pay to Multi Signature).

Those are default behavior of Bitcoin Core, so i don't understand why other node would determine it as a spam.

[snerd]

Bitcoin Core source code provide short explanation about those configuration.

Code:

# Relay and mine data carrier transactions (default: 1)
#datacarrier=1

# Relay transactions creating non-P2SH multisig outputs (default: 1)
#permitbaremultisig=1

AFAIK it means,
1. datacarrier=1 allows you broadcast transaction with OP_RETURN.
2. permitbaremultisig=1 allows you to broadcast multi-signature transaction which use P2MS (Pay to Multi Signature).

Those are default behavior of Bitcoin Core, so i don't understand why other node would determine it as a spam.

Good question, and I’m watching for any answers.

[vjudeu]

Those are default behavior of Bitcoin Core, so i don't understand why other node would determine it as a spam.

Ordinals are also allowed by "default behavior of Bitcoin Core", but they are filtered by some mining pools anyway.

data carrier: https://github.com/bitcoin/bitcoin/issues/27043
bare multisig: https://github.com/bitcoin/bitcoin/pull/28217

In general, if you make for example 1-of-20 multisig, then guess what: you need a single valid key, and the rest 19 keys can be used, just to push some data.

And in case of OP_RETURN, the 80-byte limit is no longer a problem, because there are pools accepting more than that. So, obviously, it is used as a faster way of spamming, because then, you can put your spam inside some output, instead of input (which is needed to put more spam, if you want to send a lot of short messages, because then, it may be cheaper than Taproot, if your data is between zero and a few hundred bytes).

Also, bare multisig can be used to slow down verification, and to increase the number of sigops in a given block. And both issues can be used, to get some advantage over another mining pool, which may be unaware of that, and include those transactions, and losing some time or fees by doing that.

[snerd]

Those are default behavior of Bitcoin Core, so i don't understand why other node would determine it as a spam.

Ordinals are also allowed by "default behavior of Bitcoin Core", but they are filtered by some mining pools anyway.

data carrier: https://github.com/bitcoin/bitcoin/issues/27043
bare multisig: https://github.com/bitcoin/bitcoin/pull/28217

In general, if you make for example 1-of-20 multisig, then guess what: you need a single valid key, and the rest 19 keys can be used, just to push some data.

And in case of OP_RETURN, the 80-byte limit is no longer a problem, because there are pools accepting more than that. So, obviously, it is used as a faster way of spamming, because then, you can put your spam inside some output, instead of input (which is needed to put more spam, if you want to send a lot of short messages, because then, it may be cheaper than Taproot, if your data is between zero and a few hundred bytes).

Also, bare multisig can be used to slow down verification, and to increase the number of sigops in a given block. And both issues can be used, to get some advantage over another mining pool, which may be unaware of that, and include those transactions, and losing some time or fees by doing that.

This sounds like one for the Pro column. Will wait for any for the Con column, thanks!

[ABCbits]

Those are default behavior of Bitcoin Core, so i don't understand why other node would determine it as a spam.

Ordinals are also allowed by "default behavior of Bitcoin Core", but they are filtered by some mining pools anyway.

data carrier: https://github.com/bitcoin/bitcoin/issues/27043
bare multisig: https://github.com/bitcoin/bitcoin/pull/28217

In general, if you make for example 1-of-20 multisig, then guess what: you need a single valid key, and the rest 19 keys can be used, just to push some data.

And in case of OP_RETURN, the 80-byte limit is no longer a problem, because there are pools accepting more than that. So, obviously, it is used as a faster way of spamming, because then, you can put your spam inside some output, instead of input (which is needed to put more spam, if you want to send a lot of short messages, because then, it may be cheaper than Taproot, if your data is between zero and a few hundred bytes).

Also, bare multisig can be used to slow down verification, and to increase the number of sigops in a given block. And both issues can be used, to get some advantage over another mining pool, which may be unaware of that, and include those transactions, and losing some time or fees by doing that.

Good point. I'm aware Bitcoin Knots (full node software) and Ocean (mining pool) have option to exclude Ordinals. Although they're in minority who actually put effort to partially deny Ordinal. GitHub Links you included mentioned token protocol which use P2MS, but that protocol plan to move from P2MS and token hype on Bitcoin blockchain have reduced. So IMO there's no strong reason to refuse TX with bare multisig now.

--snip--

This sounds like one for the Pro column. Will wait for any for the Con column, thanks!

The obvious cons are,
1. You don't have complete mempool / unconfirmed transactions. It mainly hurts those who run blockchain analysis or block explorer though.
2. For miner/pool, you could earn slightly less Bitcoin.

[garlonicon]

For miner/pool, you could earn slightly less Bitcoin.

It depends. If you have a lot of multisigs, then you have to do a lot more hashing than usual (because you have to compute a different z-value for each signature in each input). And then, it may be more profitable to include more cheaper transactions, because you validate them faster.

Also, if your block is hard-to-validate, then there is a higher chance of getting a stale block, because other miners will have to validate it, too. And some competing mining pool may mine a block at the same height, which could be validated faster, and then miners will faster start mining on top of it.

[achow101]

This sounds like one for the Pro column. Will wait for any for the Con column, thanks!

Configuring your node with a mempool policy that rejects transactions that the vast majority of other nodes on the network are accepting will result in increased bandwidth usage and a longer block propagation time.

Blocks are usually relayed using compact blocks, which works by assuming that transactions that were in the mempool of one node were likely in the mempool of another node, so the relayed block does not actually need to send the entire transaction. The receiving node receives enough information to identify which transactions were in the block so it can reconstruct it on its own using the compact block data and the transactions in its mempool. However, if the mempool policies differ, then the receiving node has to ask the sending node for the transactions it does not have. This introduces extra round trips of communication, which increases the time it takes for the receiving node to have the block ready for validation. Therefore, block propagation is delayed. This can lead to an increase in the stale block rate.

Additionally, in order for these alternate mempool policies to work, your node has to receive the transaction in the first place in order to be able to determine whether it should reject it. It will receive the transaction, find it does not meet the configured policies, and then forget about the transaction. If that transaction is included in a block, then it's going to have to receive that transaction again. The result is that the transaction must be received multiple times and consuming extra bandwidth to do.

[amaclin1]

Configuring your node with a mempool policy that rejects transactions that the vast majority of other nodes on the network are accepting will result in increased bandwidth usage and a longer block propagation time.

Seems to me that this advice is not about bandwidth usage but is a poor attempt to decrease the count of useless transactions in blocks.

[Kruw]

Seems to me that this advice is not about bandwidth usage but is a poor attempt to decrease the count of useless transactions in blocks.

The transactions aren't useless, they pay fees to miners.