Aha, so we just need to have a consensus to have consensus, got it.

You're begging the question. The whole point of this exercise is to make sure that transaction history cannot be rewritten. If you just assume that it cannot be rewritten, then you don't need all this Ti mumbo-jumbo.

Inclusion of Ti does not make it any harder to rewrite the history, as attacker has access to all Ti and thus he will be able to create a seemingly valid chain which references all Ti blocks but is completely different.

I think you've got things wrong, to improve security you need to reference alt-coin blocks from Bitcoin blocks, not the other way around. This is known as anchoring, it's already used in several projects (for example, Factom) and it can make alt-coin consensus as strong as Bitcoin. (See here: https://bitcointalk.org/index.php?topic=313347.0)

Thank you for providing the above link.
My question was if it's possible to create somehow a paper wallet for every altcoin by myself
e.g. to generate the public and private address somehow without using paper generators.

There are altcoins without paper wallets so I want to store my coins on paper.

What is a strong definition of "fully validating node"? (without referring to Satoshi client)
What would you do in case of reorganizing the mainchain from the block #289999? from the block #200000? from the block #1?

Up to you. Bitcoin is voluntary system.
You have a right not to check signatures at all.

Generally the "says" is that you can signal it. Not that the bitcoin protocol is always a paragon of perfect design, but it should generally not be possible to signal something that shouldn't work-- when thats possible it reliably leads to bugs. so it shouldn't be done without good reason. Being able to control sighash per signature is pretty useful.

But fair enough; I just wanted to make sure you weren't confused in more profound ways, but I follow your thinking now.

There isn't-- though Bitcoin Core can already do this. It can run a full node, with transaction and block relaying (but not serving historical blocks) with less than 2GB of space; this isn't a default behavior yet because we have not yet implemented mechanisms for nodes to retain and locate random chunks of the history so that nodes can collectively support other nodes bootstrapping.

What seems incompressible can generally be compressed more if one shifts the order of characters around a file. For example: https://en.wikipedia.org/wiki/Burrows%E2%80%93Wheeler_transform (that's what bzip does btw). In theory a compression system could use multiple such "tables" and try various configurations to find new redundancies, folding and re-folding the data again and again, but obviously I'm not going to ask you to invent such a system

In any case, whatever degree of compression is achieved => is good. If a compressed block, for example, can be reduced from 1mb to 600kb, it's a huge improvement for someone with a slow connection.

Bandwidth limited = I/O and cpu limited then?

We had a similar discussion in another thread, but anyway I want to write it more concisely here: I really believe scaling can be achieved through tradeoffs of what a user has and what he hasn't. Every machine will hit a bottleneck somewhere, the issue from that point onward is how to juggle the tradeoffs to bypass your bottleneck.

Examples:

-A user has a slow internet connection but plenty of CPU => He should have the option of downloading (and uploading - if he is running a node) very compressed blocks with other cooperating nodes that are willing to use compressed blocks.
-If the same user has slow CPU as well => He should be able to tap into GPU resources for parallel compression/decompression (it's feasible - I've seen pdf's with research on the subject of parallel compression on GPU).
-If a user has slow I/O but fast CPU => Compress the blockchain for more local throughput
-If a user has low RAM but fast CPU => Compress the RAM (for things like compressed cache)
-If a user has slow I/O or low RAM but will bottleneck on CPU if he goes to a compressed scheme => tap into GPU
-If a user wants to increase cache size to increase performance, but lacks ram => Use compressed RAM, tap into more CPU, to reduce I/O.

Essentially you try to trade what you have with what you want to achieve. One size fits all solutions won't work particularly well because one user has 1gbps connection, another has 4mbps. One is running on a xeon, the other is running on a laptop. One has 16gb memory, another has 2. One can tap into a GPU for parallel processes, another can't because he doesn't have one.

IMO the best scaling solutions will be adjustable so that bottlenecks can be identified in a particular system and make the necessary tradeoffs to compensate for deficiencies. Compression is definitely one of the tools that can balance these needs, whether one lacks RAM, disk space on their SSD, bandwidth on their network etc. And GPUs can definitely help in the processing task - whether the load is directly related to btc operations or compression/decompression.

For reference, there is a protocol rule which prohibits generated BTC (coinbase tx) from being spent until it has 100 confirmations. Older Satoshi client had an additional safety margin: it won't let you spend generated BTC until it has 120 confirmations. Discussion surrounding locking coins for sidechains was in the 144-288 blocks depth range.

That is a concerning misunderstanding. I'm not sure how you'd think that-- the sighash in use is part of the ecdsa signature (input to checksig).

unconfirmed bitcoins are worthless.
I'd never take them as a payment, no matter the sequence number.

people who think they can build a profitable business with unconfirmed bitcoin transactions are lunatics.
unless they are to profit from stealing the money, by fooling others into accepting zero-conf transactions.

If you are doing it as part of a protocol, you would insist that the output scripts all match the expected template.

Either use CHECKSIGVERIFY or make sure CHECKSIG is the last operation to execute.

Well, I would be 90% sure that the sighash applies on a per signature basis, but when in doubt, it is worth testing.

I think so, but it is probably worth checking a few transactions with mixes of signatures on testnet.

I would suggest you all convert your BTC to nanosecond block time cryptocoins.

Oh wait...

Supposedly, changing the block time is a more complex and bigger change than changing the block size.

I still think it's worth it to have faster block time. 10 minutes is a cruel joke, just read about the many complaints that are happening in the real world:
https://www.reddit.com/r/Bitcoin/comments/48m9xq/average_confirmation_times/

RBF suddenly starts making sense, doesn't it?
funny how many people were resisting the deployment of this feature, while now they are going to be the first ones to use it

Signatures are pass/fail, they don't have meaning other than that.  SIGHASH_SINGLE means that you just sign the output that you are interested in.  You are saying "This signature is valid for any transaction which pays to this output".

Assume you had 2 inputs and 2 outputs and you are checking input zero.

The first signature is sighash_single & anyone_can_pay.  That means that you only include output zero.  The anyone can pay means that you also delete all the inputs, except the one you are signing (input zero).  Those inputs and outputs are the only ones that are involved in the signature.

The person who signed that signature signed any transaction with that input and that output.

That means you can add inputs and outputs and the transaction will remain valid (as long as that input and that output are in the same position).

The second signature is sighash_all.  That person signed the entire transaction.  If you change anything about the transaction, then it becomes invalid.

In theory, the first person could create a one input and one output transaction and sign it with (sighash_single | anyone_can_pay) and then sign it.  The second person can then take the transaction and modify it (adding the 2nd input and 2nd output) and then sign with sighash_all.  That 2nd signature is also valid, but only if there are no more changes.

Ok, verify ( signature, digest, pubkey ) method returns either 1 or 0
Note, that this method doesn't depend on any other variables. it does not know anything about satoshi sighash types.
The msig script m-of-n is valid if there are at least m hits of positive verifies

It is not a problem.
let me give you some pseudocode:

byte[] pubkey = getPubkey ( );
byte[] param = getSignaturePlusHashtype ( ); // signature concatenated with hash type
byte[] signature, int hashtype = param.split ( );   // get bare asn1 signature and 1-byte hashtype
byte[] digest;
switch ( hashtype )  
{
  case SIGHASH_ALL : digest = tx.createDigest ( all ); break;
  case SIGHASH_NONE: digest = tx.createDigest ( none ); break;  
}
verify ( signature, digest, pubkey )

You compute the transaction for each signature separately.  You can't just work out the hash once, you have to do it for each of the signers (if they use different sighashes)