Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: spartacusrex on October 04, 2018, 01:09:50 PM



Title: How to prevent SPAM in a flood fill network ?
Post by: spartacusrex on October 04, 2018, 01:09:50 PM
Bitcoin uses fees as a way of preventing unlimited txns being sent by malicious parties to clog up the network.

Recently - quite a few coins out there are pushing a zero fee system. (IOTA, NANO, EOS etc..)

If a peer-2-peer crypto network doesn't require fees, say they have no miners - or have miners who are paid by other means, how is SPAM reduced ?

I am trying to list / break-down all the different methods..

1) HASHCASH - You ask the sender of transactions to do some POW work. So they have to spend some time and effort before sending the transaction, and invariably cannot proceed indefinitely.

2) Blacklist known malicious IPs.

3) Restrict the number of transactions any node will accept from any peer it is connected to - although how to distinguish the legit from the SPAM txns ? Does it matter ? maybe just restricting is enough.

4) Bit cheeky - But the sender could _burn_ some funds - the transaction outputs would be slightly less than the inputs. This is not strictly a fee as no user receives it, but is a cost that is passed on to the user. This would make spamming much more expensive.

5) Reputation systems.

6) ?

Any input - cheers! 


Title: Re: How to prevent SPAM in a flood fill network ?
Post by: andreibi on October 04, 2018, 01:21:48 PM
Implement fees and then higher fees to make spam uneconomical. That's universal protocol in most networks.


Title: Re: How to prevent SPAM in a flood fill network ?
Post by: HeRetiK on October 04, 2018, 02:02:30 PM
I think some real life examples of the methods mentioned by OP (and others) would be nice:

1) HASHCASH - You ask the sender of transactions to do some POW work. So they have to spend some time and effort before sending the transaction, and invariably cannot proceed indefinitely.

Applied by IOTA, for example. Not sure how it adjusts to future hardware though.


2) Blacklist known malicious IPs.

3) Restrict the number of transactions any node will accept from any peer it is connected to - although how to distinguish the legit from the SPAM txns ? Does it matter ? maybe just restricting is enough.

IIRC Bitcoin nodes (and presumably most other coins that are directly based on the Bitcoin Core codebase) do this automatically when suspiciously flooded with transactions.


1. Disallow or ask higher fees when spend recently received UTXO/balance, works well when combined with minimum sent amount to an address.

I think Bitcoin used to account for coin age, but if I'm not mistaken doesn't do so anymore?


2. Coin's interest or other form of reward for not spend coins after some time.

If I'm not mistaken some PoS variants take coin age into account when determining staking rewards.


Title: Re: How to prevent SPAM in a flood fill network ?
Post by: odolvlobo on October 04, 2018, 05:07:02 PM
I assume that by "spam", you mean a DOS attack.

#2 won't work well for several reasons.
#3 won't help if there is no way to distinguish between real transactions and spam. Otherwise, it would only make the problem worse.

DOS attacks only work if the cost of the attack is less than the benefit, so the obvious way to prevent them is to make transactions costly. But there could be other ways, such as being able to identify the source of a transaction.

DOS attacks also only work if they are big enough to disrupt the network. If a network is big enough or has enough capacity such that it can't be disrupted, then there is no issue. Consider the futility of a DOS attack against the entire internet.


Title: Re: How to prevent SPAM in a flood fill network ?
Post by: aliashraf on October 04, 2018, 05:34:00 PM
Interestingly, bitcoin PoW was adopted from Adam Beck's Hashcash idea (1995). This is absolutely the most effective and established method ever, I think it is even better than bitcoin's fee system.

In bitcoin we have 2 important class of messages arriving from peers: newly found blocks and new transactions. While blocks are protected by pow and will be dropped in very first stages of their life if they don't pass the hash requirement test, transactions are not. Compared to computing sha2 hash of the header, which is the case for received blocks the tests required for validating a transaction are more computation intensive because full nodes should both check their inputs with UTXO and run the respected scripts which typically encompasses a signature validation.

Even after passing first tests and being put in mempool, transactions should pass double-spend test by finding their way to blockchain and as in the case with transaction malleability, spammers are able to pass preliminary tests and for few satoshis fill mempool with tons of slightly different versions of basically the same transaction.

So, in bitcoin fee is not charged until the transaction is confirmed while spam is going on from the first stage, It is obviously a problem and a base for spamming attacks.

Implementing a hashcash like strategy in bitcoin is not that easy tho. Fees act as an incentive mechanism for miners that is supposed to cover for block reward reduction due to halvings, eventually, they should be preserved. Hence a hypothetical hashcash requirement for transactions has to be something fixed in terms of difficulty, it would raise a series of new problems, most importantly diversity of devices and the impact of new technologies.

Combining bitcoin block based and hashcash transaction based PoW is hell of a job but not impossible. Actually I have an strategy for this and would share  it if it was not off-topic.


Title: Re: How to prevent SPAM in a flood fill network ?
Post by: spartacusrex on October 04, 2018, 06:24:55 PM
Interestingly, bitcoin PoW was adopted from Adam Beck's Hashcash idea (1995). This is absolutely the most effective and established method ever, I think it is even better than bitcoin's fee system.

What about Bot-Nets that would find the HashCash requirements easy to fulfil ? With Bitcoin's fee system even those are neutralised.


Title: Re: How to prevent SPAM in a flood fill network ?
Post by: aliashraf on October 04, 2018, 08:14:46 PM
Interestingly, bitcoin PoW was adopted from Adam Beck's Hashcash idea (1995). This is absolutely the most effective and established method ever, I think it is even better than bitcoin's fee system.

What about Bot-Nets that would find the HashCash requirements easy to fulfil ? With Bitcoin's fee system even those are neutralised.

What about a combination of both PoW and fee (interchangeable)?
I have to repeat my argument above: fees have nothing to do with spams, nothing enough at least. Once spammers managed to pass UTXO & Input script checks they would be able to flood the whole network by double-spending the same output with absolutely no cost other than generating a transaction.

As of botnets, they are always a disaster but AFAIK the only known mitigation to DDoS attacks is making it like millions of times  harder for every single message to be produced  compared to what is needed for it to be verified primarily and allowed in: definitively hashcash.


Title: Re: How to prevent SPAM in a flood fill network ?
Post by: spartacusrex on October 05, 2018, 10:07:50 AM
I have to repeat my argument above: fees have nothing to do with spams, nothing enough at least. Once spammers managed to pass UTXO & Input script checks they would be able to flood the whole network by double-spending the same output with absolutely no cost other than generating a transaction.

Hmmm.  actually I'm not sure that's how it works.

It's clearly possible for a node to tell whether it has been sent a transaction trying to double spend a previous one, whether in the mempool or in the chain, and then NOT to forward it to the rest of the network. Yes - you could make many roughly the same transactions, different txid but same inputs, and send it out on your botnet, but it wouldn't get propagated across the whole network. No-where near. The nodes would just stop forwarding them. So each node would really only see 1 of these transactions as valid, and forward it. The the next would be a double spend, and it would be stopped. ( Whether this is what Bitcoin does I'm not sure - but algorithmically it's obviously possible)

That's why the fee mechanism is so powerful.

I love hashcash - don't get me wrong - but IOTA clearly shows that it is being SPAM-med to a cheap-blob-of-blended-hams even though you need to do the POW work to send a transaction. So HashCash alone has currently failed to be a deterrent for SPAM.


Title: Re: How to prevent SPAM in a flood fill network ?
Post by: aliashraf on October 05, 2018, 02:35:21 PM
I have to repeat my argument above: fees have nothing to do with spams, nothing enough at least. Once spammers managed to pass UTXO & Input script checks they would be able to flood the whole network by double-spending the same output with absolutely no cost other than generating a transaction.
Hmmm.  actually I'm not sure that's how it works.
It's clearly possible for a node to tell whether it has been sent a transaction trying to double spend a previous one, whether in the mempool or in the chain, and then NOT to forward it to the rest of the network ...  ( Whether this is what Bitcoin does I'm not sure - but algorithmically it's obviously possible) ... That's why the fee mechanism is so powerful.
I understand it is possible to treat mempool like a temporary ledger and reject double-spends and many clients follow this routine already but I afraid things are not that simple. Spammers could take advantage of combinations of replace-by-fee (double-spend with higher fee) and long-chain transactions (spending unconfirmed transaction outputs) features in rather sophisticated manners to convince nodes for refreshing their mempools and relaying spam transactions.

By the way I don't get it how does it help considering fee mechanism to be powerful. Full nodes don't care about fees when they decide about a transaction to be included in mempool/relayed unless it is about competing transactions(double-spends) which is another attack vector as described above.

Quote
I love hashcash - don't get me wrong - but IOTA clearly shows that it is being SPAM-med to a cheap-blob-of-blended-hams even though you need to do the POW work to send a transaction. So HashCash alone has currently failed to be a deterrent for SPAM.
IOTA is not literally 'spammed'. It enjoys a tangle based PoW algorithm and more 'spams' means more work accumulated because every transaction appends itself to that tail of a branch of the tangle and 'weighs' on it by the amount of work it carries. There is a foundation that rewards IOTA spammers for helping the network confirmation speed-up by accumulating more work on top of chains.

I don't like IOTA because I think it is too extremist, I'm thinking of a hybrid approach by giving space to wallets for participating in consensus without eliminating block miners. So many radical changes would be necessary for this to happen, on top of them getting rid of blockchain bloat and spv wallets,  interchangeability of fee and work, defining total work of a block in a more general way, ....


Title: Re: How to prevent SPAM in a flood fill network ?
Post by: gmaxwell on October 06, 2018, 12:25:47 AM
1) HASHCASH - You ask the sender of transactions to do some POW work. So they have to spend some time and effort before sending the transaction, and invariably cannot proceed indefinitely.

Money can exchanged for goods and services (https://www.youtube.com/watch?v=dgct3Jn8pFA).  Requiring hashcash is just a fee in disguise.   Lets say you don't have money for fees but have cpu time, you could mine something (or do some other useful computation) get paid for it, and use that income to pay a fee.  Using hashcash instead of a fee -- now that we have systems that make paying a fee totally natural-- is just obfuscation and overhead.

The original proposal of hashcash for email spam made some sense because we _didn't_ have a viable way to make payments that worked everywhere.  It doesn't make so much sense in the context of a system that provides a way to do exactly that.

Quote
2) Blacklist known malicious IPs.
Again, money can be exchange for good and services.  ... and IP limiting doesn't really provide for strong security in any useful sense for a decentralized system.

Quote
3) Restrict the number of transactions any node will accept from any peer it is connected to - although how to distinguish the legit from the SPAM txns ? Does it matter ? maybe just restricting is enough.
Same as above. Now I just spread my spam out to many peers, ... not a functional limit.

Quote
4) Bit cheeky - But the sender could _burn_ some funds - the transaction outputs would be slightly less than the inputs. This is not strictly a fee as no user receives it, but is a cost that is passed on to the user. This would make spamming much more expensive.
I don't think anyone complaining about 'fees' cares where the fee goes.


Title: Re: How to prevent SPAM in a flood fill network ?
Post by: aliashraf on October 06, 2018, 07:17:22 AM
1) HASHCASH - You ask the sender of transactions to do some POW work. So they have to spend some time and effort before sending the transaction, and invariably cannot proceed indefinitely.

Money can exchanged for goods and services (https://www.youtube.com/watch?v=dgct3Jn8pFA).  Requiring hashcash is just a fee in disguise.   Lets say you don't have money for fees but have cpu time, you could mine something (or do some other useful computation) get paid for it, and use that income to pay a fee.  Using hashcash instead of a fee -- now that we have systems that make paying a fee totally natural-- is just obfuscation and overhead.
Wow! Triggering a debate. You are the life of the party Greg, and I like it.  ;)

It is 100% acceptable to note the identity between bitcoin fee system and hashcash PoW regarding their economical interchangeability, but you are overlooking a huge difference which happens to be the most relevant one in the context of this discussion: Hashcash is paid in advance but fee is just like a tip, never paid if transaction is not confirmed. This is why hashcash is natural candidate for resisting spams and fee system is not.

There is also another important difference between the two which is not exactly relevant here but worth mentioning:  
In bitcoin, fees are neutral, there is no way to use fees as a security measure, both adversaries and loyal miners could benefit by including transactions in their blocks and seizing fees. This radically isolates wallets from PoW process, i.e. eliminating average user from consensus protocol and restricting it to rather profesional miners. Taking into account the situation with pools, it is speaking for itself.

As I have mentioned earlier, I'm not a fan of IOTA and tangle idea but it shows the interesting features and potentials of hashcash for making network more spam resistant and significantly helping decentralization. I'm seriously considering it as an important part of my proposal for eliminating pools by introducing a collaborative version of PoW. Wallets could collaborate in securing the network and be rewarded for their work by exempting transaction fee.



Title: Re: How to prevent SPAM in a flood fill network ?
Post by: lazer1064 on October 07, 2018, 09:42:08 PM
I assume that by "spam", you mean a DOS attack.

#2 won't work well for several reasons.
#3 won't help if there is no way to distinguish between real transactions and spam. Otherwise, it would only make the problem worse.

DOS attacks only work if the cost of the attack is less than the benefit, so the obvious way to prevent them is to make transactions costly. But there could be other ways, such as being able to identify the source of a transaction.

DOS attacks also only work if they are big enough to disrupt the network. If a network is big enough or has enough capacity such that it can't be disrupted, then there is no issue. Consider the futility of a DOS attack against the entire internet.

How do you like that idea:  https://bitcointalk.org/index.php?topic=5042068.msg46414511#msg46414511 ?