I’ve got a node that’s hooked up to mine, and I noticed some instructions in the User Agent field...
"to stop the spam on your own node, set datacarrier to 0 and permitbaremultisig to 0"
Are those commands legit? Are they safe to use? Should I go ahead and type them in? What do they actually do? And how do I properly enter those commands if I choose to?
Thanks!
snerd
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!
Bitcoin Core source code provide short explanation about those configuration.
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.
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.
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.
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.
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.
Does anybody know of a way to broadcast a transaction (outside of Core or Electrum) that has permitbaremultisig=1? I don't have Core, and I'm hoping there's a broadcasting service out there that will let me send these kinds of transactions.
You should help me because I could clean up hundreds of 1-of-3 multisig outputs, thereby helping Bitcoin.
edit:
Oh great, I didn't see you were still active (semi-recently). Well you owe me $6. That's accounting for the adjusted price of BTC.
MARA Slipstream (https://sandbox.mara.com/) (https://slipstream.mara.com/) is probably the only realistic option, since they include most non-standard TX on block they mine themselves. But you need to create TX with fee rate they want and get it's raw TX (in hex format). Currently it's 2 sat/vB, but it could be higher or lower depending on mempool condition.
Yeah I saw that but you need to apply for a "client code" to use their broadcast service now.
I wrote a python script (OK the AI wrote it) to help me spend some of my odd multisig outputs, but several of them are no longer carried by most utxo sets, even though they really exist.
I think the problem is the broadcast services follow default Core rules, which is permitbaremultisig=0.
Isn't the default still permitbaremultisig=1? https://github.com/bitcoin/bitcoin/pull/28217 is PR to make it false/disabled by default, but it never approved/merged. Someone also mention P2MS is still created on daily basis, according to https://mainnet.observer/charts/inputs-and-outputs-p2ms/.
Oh... you're right, turns out I was mistaken. I can spend some outputs but not others, even though they are structurally identical transactions.
This is the error I'm getting when attempting to broadcast the transaction:
bad-txns-inputs-missingorspent
Apparently most broadcast service nodes don't carry these weird 1-of-3 or 1-of-4 multisig outputs and that's the problem.
I have no good idea why those service reject some 1-of-3 P2MS. But BIP 11 state the only N up to 3 consider as standard, so 1-of-4 isn't considered as standard.
Perhaps some of those P2MS UTXO in your wallet don't actually exist in the blockchain.
Since some of those are non-standard, those must have failed to reach a miner's node when you broadcast those, but it's locally saved in the client that you're using.
Reason is: even if a 1-of-4 P2MS isn't standard, it's still consensus valid up to 20.
So if a miner included it in their block (if it actually exist), the owner can still spend it since that n=3 limit is enforced on transaction's output during broadcast, not when you redeem them as inputs.
Those nodes that would've rejected it in their mempool will still count it in their UTXO set if it's actually in the blockchain.
Checking every blockexplorer if those transactions with the weird outputs exist should be enough to tell which of those are available.
As a bonus, the inputs may still be available once you drop them from your client if those aren't already spent by your other transactions.
Problem is, you wont be able to access those if you're not the sender.
Maybe those are included as another output of a transaction that contains non-standard output.
E.g.: A transaction sending with two outputs: (0) 1-of-3 P2MS and (1) 1-of-4 P2MS, the transaction will be rejected by nodes that enforce the standard.
They do. I can see them as little green arrows next to the input / output amount on mempool.space. I can also see where they come from, but the default Core tx set cannot. So even though I can see them on mempool.space, I can't spend them using their broadcast service, because they use default Core settings for that.
The outputs are all
- bare multisig
- 1-of-2, -3, or -4
- from 2014 or 2015
For whatever reason, some of these are included in default Core settings, and I did manage to sweep those. But some are not. And the only way I can think to get them is to run my own version of Core with no pruning and txindex=1.
But the error "bad-txns-inputs-missingorspent" isn't directly related to P2MS standards.
It's literal, the transaction that's broadcasted has an input that they do not know or already spent.
Those setting (specifically permitbaremultisig) only affects their mempool, not the UTXO contained in the blocks or their UTXO set so it can't be their node's policy.
You're also spending P2MS UTXO, not creating new P2MS outputs so permitbaremultisig policy shouldn't be involved on its broadcast.
Lastly, the error message should be different otherwise.
Try to double-check each of your transaction's input.
E.g.: When decoded, take note of those "txid:vout" under inputs, search the txid then look for the referenced vout in the output(s) if it's not spent yet.
If all are actually available, then there must be something in those scripts.
If it's not possible to share them here, try to minimize the number of inputs per transaction (sweep) to isolate the ones that causes the error.