The current maximum size of a block is 1 MB. Current block sizes are about half that, so the absolute worse case scenario is that the block chain grows in size twice as fast as it does now. That's not particularly scary.
It's easy to create more than 1 MB of transactions every 10 minutes. If anyone does that, some transactions can't be included in blocks. ...
You should use full nodes on both sending and receiving end
Use the -connect option to broadcast your tx through selected neighbours. Use https://bitnodes.21.co/ to find neighbours. Use the wallet commands in bitcoind and send a transaction to address in your own wallet
Use -walletnotify option in bitcoind to get notifcation of ...
It is not too difficult to check the low-fee transactions in large blocks with block-explorer. Follow the link
and press Load more... link several times.
There are a lot of one-input-to-one-output dust transactions like https://blockchair.com/bitcoin-cash/transaction/...
But what if you really needed to pay someone a fraction of a transaction fee? Bitcoin is indiscriminatory in that regard.
Moreover, most transactions have two outputs, one crediting whoever you send your transaction to, and one crediting you back. It is quite easy to send the same small amount transactions to someone while still appearing to be sending a ...
Hashcash is one of the many anti-spam techniques used today, which is essentially a proof-of-work system designed to limit not only email spam but also denial-of-service attacks. A similar proof-of-work methodology is being used in bitcoin for block generation.
With an average of 150 billion e-mails sent out on a daily basis I cannot see how this could be ...
The transactions will likely never be included in a block, as they do not meet the defacto bitcoin transactions rules for transactions sent without a fee, detailed here:
A transaction may be safely sent without fees if these conditions are
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large ...
There are three types of spam problem in the Lightning Network. Let's
call them "local","fast" and "slow".
Local spam is someone sending or requesting too much data: that's a simple batter of code with rate limiting etc.
Fast spam is sending many failed payments. You can't tell what will succeed and you can't blame the sending ...
What exactly is the high fee that Bitcoin Core is talking about? Does this client have exactly fixed number?
Bitcoin Core has a hard limit for what it considers to be an absurdly high fee, which is 0.1. Other node software may not impose this limit, or may have a different value for it.
Note that this is not part of the standard tx rules. It is simply a ...
There already is a limit of 5460 satoshi. It's unlikely any transaction smaller than this will be ever relayed or included in a block without colluding with a miner.
This has two problems:
The network still needs to remember those transactions, so this doesn't save storage space.
If someone does a double-spend attack, two nodes could believe two different things about the state of the network, depending on which transaction they heard about first. Over time, their views of the network would diverge more and more.
why not do include such dust, so that spammers are harmed economically
and stop doing it?
I'm still not sure that would be enough to prevent this kind of spam activity. Even if these transactions were committed to the blockchain, 100,000,000 such broadcasts could be made from 1 BTC, that's a lot of reach for $700.
It's not really.
Of course there are transaction fees, but in the situation you describe, where blocks are not already full, the supply of available block space must be lower than the demand, and so you should be able to create many transactions at low fees, and miners will put them in their blocks because low fees are better than none at all.
Or, if you ...
In the current environment, I doubt that you can. Blocks are full these days, and the block space needed to spend your UTXO, whether as its own transaction or as one input of many similar transactions, could be used instead for a transaction with a much more lucrative fee than 1 satoshi.
I think your "aggregated" strategy would only work if one of the ...
looking at this particular example, there is many, many multisig tx, one after another. These multisigs require more signatures, and extend the space. Now one can try to be speculative, and say it is spam - as we don't know the real use case. The advantage would be, that you fill the block of "low level fee tx" (see here: https://core.jochen-hoenicke.de/...
From my understanding, an unconfirmed transaction can be accepted into the mempool provided that it has a fee that is generally at least 5460 satoshi, which is set as default in the current version of Bitcoin Core (assuming input=148B, output=34B, and relay node hasn't changed default settings).
That's not correct. Given the number 5460 you're citing, I ...
yes, but then the "spammer" hasn't really accomplished anything.
essentially with spamming its either
1) you paid to get a "spam" transaction included in a block
2) you paid nothing to get it in the mempool
not really spam either way at this point
Bit unclear, but sounds like nonsense. Put your address into a bitcoin explorer (like blocktrail.com) and have a look at all the transacions (hopefully 1 or none). Make sure there are a few confirmations before assuming it's your money. If you're being scammed they might be sending you something with a too low fee, which might never confirm.
The transaction fees are optional, the sender can choose to include the fees and the miner can choose the include the transaction. Each transaction that is included increases the size of the block which affects how quickly it can propagate and the size of the entire block chain.
So one explanation of why not to include them is because it doesn't profit ...