Nope. Malleability isn't an issue for well confirmed transactions, which is all that any sidechains proposals work with-- often 100 blocks or more. But that hasn't stopped people you associate with from dishonestly claiming that segwit exists to enable sidechains. I doubt having this further confirmed will suddenly spur you on to calling out their incorrect claims, since you don't for anything else.

The blocks HAS to go through a rogue node which has modified rules. Imagine if there are only 1000 nodes, one can easily setup 200 nodes and use modified rules on them. The higher the number of rogue nodes, the higher chance an SPV client would connect to it and be disconnected from the actual network.

The higher the number of honest nodes, the harder it will be and the network will be more decentralised as a result.

Yes. Assuming that you are talking about 1000 SPV wallets, full nodes will be important. SPV wallets rely on full nodes to deliver accurate information and will have to trust them. This exposes them to sybil attack where a lot of nodes are created by a single entity and are modified to follow a different chain or different rules. The more nodes there is, the more expensive it will be.

It does. They are in charge of verifying and enforcing the consensus rules. They help both the network and the light wallets in a way.

Because to peg a sidechain to the mainchain, someone, centralised or in a decentralised manner, must verify that transaction met some conditions (e.g.,to lock the coins on mainchain and is certain levels deep). If the transaction is malleable, it is difficult to programatically achieve this since txid could change. I think depending on the design of the sidechain, this can be taken care of, BUT although the solution might be programmable, it would most probably be centralised.

Of course i understand running full nodes secures network as a whole.

However, lets imagine for a moment that ECDSA is broken in such a way that the time to crack a private key from a public key is reduced to 6 months.

If I always use a new address for every transaction, then all of my bitcoins are protected by SHA256 and RIPEMD160.

If you have an address that you've re-used, then you might have bitcoins sitting out there on the blockchain with their public key exposed.  An attacker can spend the next 6 months working out your private key and then steal your bitcoins.

If I send a transaction, the attacker has (on average) 10 minutes to figure out the private key, craft a replacement transaction that pays the bitcoins to him, and then convince a miner to mine his transaction instead of mine.

Which is safer?  Your bitcoins sitting on the blockchain with an exposed public key allowing the attacker to continuously try to craft a transaction that takes your bitcoins until you get around to sending them to a new address?  Or my bitcoins that have a window of 10 minutes on average to try to both crack the key AND convince a miner to accept a double-spend transaction in place of the existing one?

The increase in security from using a new address for every transaction is quite small, but it is still better than re-using addresses.

Using a new address for every transaction can also increase your privacy a bit.

Did you see the final paragraph in this post?

https://bitcointalk.org/index.php?topic=1895455.msg18832108#msg18832108

So here is the interesting attack:  You give me your pubkey, and then I create my pubkey for a 2-of-2 (or some other more elaborate contract), and then we pay to the resulting address.

Oops.  In the background I did ~2^80 work and found a colliding address which didn't have the same policy, and I use it to steal the funds.

2^80 is a lot of work, but it isn't enough to be considered secure by current standards.

This is very exciting, or seems so... i'm surprised there's not more discussion here.  Maybe people are studying your work.

It seems that this is key in decentralization and relevant to the scaling debate. 

I think it could be very beneficial if you had time to write more about
the security model of Bitcoin and how the various strengths of fraud proofs
can help ensure SPV clients are able to validate the network...and reduce
the need for most users to run full nodes.

And unmodified non-segwit miners will not initiate a split under any condition.

It's not semantics. When validating blocks the vast majority of the time the UTXO set is not used by bitcoin core; because the UTXOs are in the cache already (due to mempool) and nor are the result of the block's changes written out-- they're buffered until the node flushes-- and very often never get written at all because the newly created outputs are spent by a later block before the system flushes them.

OP suggests that the structure he proposes reduces the delay at the time a block is processed compared to Bitcoin Core's UTXO database, but it shouldn't-- at least not for that reason-- because the database is only used at block processing times in the exceptional case where a transaction shows up by surprise.

This is not how Bitcoin Core works. No access to the disk normally at all happens when a block is verified except for transactions that have not yet been seen, reading or writing.

So you basically extract all the transactions from the blocks and store them in a separate files (transactions1+transactions2), giving each transaction a unique sequencional "numeric index".

Then you have the index file (tx-index) where each different TXID points to the "numeric index" - that's actually your equivalent of UTXO-index, except that it includes also spent transactions.

And then you have the spend-index (addressed by the "numeric index") which basically tells you whether a specific output of a specific transaction has been spent.

Is that correct?

First of all, you did not get rid of UTXO-index.
You still have it.
You just extended it into TXO-index meaning that you index not only unspent transactions, but also the spent ones.

Now, how is it possible that your code performs better than the leveldb solution used by core..?

It has nothing to do with any "fast concurrent spend tree".
It has all to do with the (U)TXO index itself.
You use a hashmap as the index, which is much faster than the index used by core's leveldb engine.
But it also takes much more system memory.

I know, because I also use hashmap based UTXO index in my gocoin s/w.
So you don't have to tell me that it's much faster.
But it comes at the cost of the memory - you can't run this with e.g. 2GB of RAM.
From my personal experience I'd say you need at least 8GB.
And because you index both; spent and unspent transactions, you need even more memory than the UTXO-index solution, which you are trying to beat.

The bottom line is: no way this can perform better than a simple hashmap based UTXO-index.