3

Having run Bitcoin Core with Luke's patch and with permitbaremultisig=0 and datacarrier=0 in bitcoin.conf for a couple of weeks I finally decided to make a switch to Bitcoin Knots. The following options seem to be relevant to the matter of limiting spam (inscriptions not applicable to finance, BRC-20, ordinals and the like).


# Relay and mine non-OP_RETURN datacarrier injection (default: 0)
#acceptnonstddatacarrier=1

Relay and mine "non-standard" transactions (default: 0)


#acceptnonstdtxn=1


Equivalent bytes per sigop in transactions for relay and mining


(default: 20)


#bytespersigop=1


Minimum bytes per sigop in transactions we relay and mine (default: 20)


#bytespersigopstrict=1


Relay and mine data carrier transactions (default: 1)


#datacarrier=1


Treat extra data in transactions as at least N vbytes per actual byte


(default: 1)


#datacarriercost=1


Maximum size of data in data carrier transactions we relay and mine


(default: 42)


#datacarriersize=1


Maximum size of scripts we relay and mine (default: 1650)


#maxscriptsize=1


Relay non-P2SH multisig (default: 0)


#permitbaremultisig=1


Relay legacy pubkey outputs (default: 0)


#permitbarepubkey=1

How might I set up the above parameters in order to stop or limit spam?

I noticed that datacarrier is set to 1 by default. Why is that so? Is it because of other, more effective settings such as acceptnonstdtxn and acceptnonstddatacarrier being set to 0 by default?

If I want to lower the maximum size of data in datacarrier transaction to less than 42 bytes, lets say to 35 bytes, should I apply datacarriersize=35? What are the pros and cons of lowering this parameter below the current default of 42 bytes?

Vojtěch Strnad
  • 8,292
  • 2
  • 12
  • 40
John Smith
  • 826
  • 3
  • 12

1 Answers1

4

Bitcoin Knots aims to default to reasonable node policies. The reason datacarrier is enabled by default, is that it's impractical to prevent 32-byte spam from abusing p2*h outputs which is much more harmful. So to that end, turning a blind eye to small spam isn't terrible.

The reason it was originally 42 bytes is because there was a possibility back in 2014 that it could be useful for committing to external data, and that data might need a tag of some sort. Since that time, there have been developments to make such usage unnecessary (eg, paytocontract and Taproot). But there hasn't been much rationale to change it either.

Reducing the size to 35 should be perfectly fine.

P.S. Since you specifically mention low-value transactions, you may be interested in testing out the new dustdynamic option: https://github.com/bitcoinknots/bitcoin/issues/74

Luke Dashjr
  • 1,269
  • 6
  • 10
  • Thank you for your answer. I am definitely interested in testing the new dustdynamic option. I've set it to dustdynamic=target:1008 while doubling the default dustrelayfee to 0.00006. – John Smith Mar 30 '24 at 19:27