TBH, I don't believe in trend lines anyway. I just think that log charts suit better for bitcoin because they show more information while linear charts only show us the last rally.

Ok I believe you now. I thought there is already an IP blacklist based DOS protection that is effective for 24 hours.

About your solution, it doesn't protect against precompiled TX spam from once-before-seen addresses to never-before-seen addresses.

I still propose to investigate the possibilities of attaching a PoW to TXs, since this approach is used in BitMessage and it works. ASIC fear is rather similar to quantum computing fear because both are hypothetical. Even if someone decides to build an ASIC just for TX spamming it will take several years for them to finish it. By that time we might come up with an even better solution to fight against spam TXs. It will win us a lot of time. TX mining can be done without a hard fork. For example, one would add a nonce behind the OP_RETURN until the TX hash begins with enough zeroes to satisfy the TX PoW difficulity requirement. Nodes would then prefer TXs that have more zeroes in the beginning of their hash.

Another option to fight TX spam is to implement TX fee auction. The latter is needed anyway because there can only be a limited number of TXs included in a block so the miners will prefer to include the most profitable TXs. When there are more unconfirmed TXs than could possible fit in a block the nodes must have a technical possibility to replace their earlier TXs with a modified version that includes a higher TX fee. I believe this also can be done without a hard fork because nodes must just recognize the replacement TXs and discard the old version of that TX if the new version has a higher TX fee. Since the mempool must also have an upper limit of say 64 MiB, individual nodes should keep a priority list of TXs. When the mempool is full and a new TX comes in, the node will see if the new TX's priority is higher than the priority of the least important TX in the mempool. If it is so, the node will drop the least important TX and add the new TX to its mempool.

If the above is implemented, the attacker must constant win the TX fee auction against all the other users of the bitcoin network. It will quickly become very costly to keep up the attack. As a honest node, I would only see my TX rejected by neighbouring nodes due to not having a high enough TX fee. I would then modify the TX to add a slightly bigger fee and broadcast it again until it is no longer rejected.

The attacker could also have a quantum computer or majority of the mining power or whatever fictional contra argument you can fantasize about.

Since TX PoW is not used for mining and is solely used to reduce spam, the algorithm can be changed with super consensus. Only spammers would be against such protocol changes. Their ASICs would become worthless. You start to seem more and more like a bitcoin traitor, unable and unwilling to come up with solutions and only trying to bash ideas for improvements with rather lame counter arguments.

WTF again you with your log chart racism. Do you understand that log chart is the right thing to look at and instead the linear chart is where you cannot draw any lines because bitcoin doesn't grow linearly.

2 options. Either the difficulty should be pre set to a reasonable level similarly to how a maximum block size is a constant.
Or, TX PoW difficulty should be dynamic so that at times of attack the difficulty rises temporarily. The latter is much better alternative to what we currently have because then the mempool won't get flooded but instead TXs would get longer to compile.


So let the spammer setup a ton of nodes. That will be a limited resource which will eventually get depleted. Also, if you read my answer above you will understand that as the attack is carried out the TX PoW difficulty goes dynamically up rendering the attacker's precalculated PoWs useless.

That combined with a block size limit of 8 MiB and minimum TX fees would be enough to stop such attacks. In addition, the protocol can be adjusted to respond to a sudden increase in the number of unconfirmed TXs so that minimum TXs fees would be risen programmatically.

knightdk, you simply did not understand what I was suggesting about TX PoW. All your replies were ill formed and overly pessimistic without understanding my idea. If you are a troll, then I would like to have you vaporized.

TX "mining" can be done without impact on devices that have less computing power.

Distinguishing between nodes can be done without linking them to the IP. For example, you can do it based on the signing public key.

That makes your whole long reply invalid.

I start to suspect that the devs have become corrupt. They are all part from their own precious altcoin scams and seeing bitcoin crash and burn will make them only happy. They deliberately do nothing.

Ignore that guy, he's full of shit and bad advice.

It is OK to do absolutely nothing for 10 years and to play it safe while waiting for the right time to GO ALL IN. Now is the time to GO ALL IN. Bitcoin has never happened before. It is the shift in financial paradigm. Taking high risks all the time will make you a loser. Taking low risks all the time will make you a loser. Taking the high risk at the right time will make you a billionaire.

Another proof why cryptos are way better than their centralized share exchanges. You cannot suspend crypto trading!

We could start identifying TXs by the nodes where the TX initiated. That way, a honest node would only have to calculate the PoW once during its existence. The calculation should be difficult. When other nodes detect TX flood from a single node they would revoke the PoW and not relay those TXs any more until a new PoW is attached.

It is easy to revoke a PoW from a malicious node and it is very difficult to calculate a new PoW. The malicious user would have to constantly calculate new PoWs while the honest nodes with their existing PoW can keep sending TXs normally. At times of high number of unconfirmed TXs the TX PoW difficulty should be risen in correlation to the number of those TXs.

When a honest node receives a TX they would check the internal database for a PoW that was somehow attached to the TX. If such a PoW exists and is not flooding the network, the node relays the TX. If the PoW exists but is flooding the network with spam TXs, the PoW will be revoked locally and the TXs with that PoW are no longer relayed. If the PoW does not exist locally the node checks the current number of unconfirmed TXs, calculates the difficulty and checks whether the PoW meets the criteria. If the criteria is met, the PoW is added to the local database. Otherwise, TXs with that PoW are not relayed.

It's foreplay. I thought you girls liked that. Same thing happened in 2013. After 8 green weeks (according to the weekly chart) the parabolic rise should start becoming visible. We are currently 5 weeks in green. Give it some time, about 3 weeks.

I think bitcoin-core should start discarding unconfirmed TXs if they start to consume too much memory. TXs with the lowest priority should be discarded first. Also, individual TXs should contain a proof of work in addition to the fee. The proof of work should be optional and should increase the priority of the TX so that it would not be discarded so easily.

For example, let's say the network is under attack. The nodes would not be able to distinguish between malicious TXs and honest TXs. However, a honest node would attach a proof of work to the TX so that honest TXs would be favoured by the network since their proof of work has more zeroes in front of the hash than the malicious TXs. When the attacker chooses to attach their own PoW the priority of the malicious TXs rises naturally to the point that it could push out the honest TXs. However, because the client can freely choose the difficulty of the PoW, it will notice that their TX is not accepted by other nodes so the client increases the difficulty, calculates a new PoW and resends the honest TX. That way, the bitcoin network would become super resilient to the given attacks.

Nice plan but you will probably be too late.

I just wanted to say that I believe that now is the time when a beautiful and very bullish Bitcoin storm is forming.

STFU, this is not trolling in any way. If we discard the last bubble because it was rather exceptional due to the willy bot action, we see that the last time we were in green for 5 weeks in a row was exactly before the Cyprus bubble. What we have been experiencing for the past 5 weeks hasn't happened for more than 2 years. This current situation is very hot and we are on the verge of a beautiful and very bullish storm.

I noticed my CPU was at 100%. I started to investigate and verified that my block chain monitor process was running at 100%, consuming 100 MiB of RAM and totally frozen. After restarting I was amazed to witness such logs:


How on Earth can there be 28 000 unconfirmed TXs. That's probably one of the reasons my process froze. Is the bitcoin network under attack or being stress tested by someone? What's happening?

edit:
for the record, I upgraded my bitcoin-core to version v0.10.2 (64-bit) yesterday.

edit2:
if the raw mempool is getting SOOO freaking huge then we need API commands to get data from the raw mempool in pages rather than as a one giant json object.

You can be sure it will make more people unhappy than happy. All those banksters, warren buffer's cock suckers and duck fuckers will be soooo butthurt.

So would you rather coin a new term for a currency having a short rise between two giant falls?

Even if the dead cat bounce is conceptually a wrong term used in this context, at least people will quickly understand about what threat I am talking about.

The shitty thing is that my work contract is for euros. Since the beginning of 2015 EUR has fallen ~10% against USD. It's a significant fall in the salary. I might need to demand a raise soon just to protect myself from being ripped off and laughed at behind my back.

FTFY