if we are doing a hardfork anyway would lightening transactions help alleviate some of the spam attacks by creating instant transactions through locktime/multisig? Thus those that are attacked because they cant get their tx through for days can use lightening tx?
LN would be opt- in I suppose, so if an attacker want to hit the block chain directly there's no way to block him, the Bitcoin network is open afterall. You could put in place mechanisms/incentives to dissuade those attacks, but they have to be at the protocol level I think (increase the dust fee threshold, remove tx priority based on coinbase age, ...).
It won't be necessary to rely on LN-type solutions to overcome spam. The correct solutions exist to handle it.
This major spam attack has been instructive, and some good things will come from it, most importantly Jeff's solution to clean up tx prioritization with a fee/KB basis and a 288 block mempool expiry, and dynamic dust threshold. If it takes this type of attack to make blue-hat thinking reach the codebase - then great.
The attack was much worse than it should have been, peaking around 90,000 tx, would have been about 16,000 tx if the dust threshold was not cut in a software change last year. Mike proposed this because btc had reached the $500 region, but it was a premature proposal and simply left a bigger window for spamming.
The biggest defense to spam is the coin dust threshold, secondly it is fees. In fact, spam can be defined as txout
Greg wants software improvements in adversity, well he is getting that with wallet software, which has been the great success of decentralization, since there must be a hundred wallet providers now, of all types. So there is a lot of inertia to change, and a lot of wallet developers were happy to let a simple default fee apply to their user's tx, this is no longer sufficient. Wallets need to be more intelligent about confirmation delays and act by raising and lowering fees acoordingly. This is happening.
It is amazing how resilient the network is with long periods of full blocks, but anyone who thinks that this is a green light for 1MB4EVR is misreading the situation. A lot of users are upset about delayed tx, but they could have applied a higher fee to beat the spam attack. This is fine when blocks are normally 40% of the of the limit. But this is not a solution when blocks are full of sensible, real-world, kosher tx. Users battling each other for block space with higher fees will be the point where the PR disaster begins.
