There are also those with physical bitcoins or other irreversible/impractical long-term-cold-storage means of managing private keys who would be disadvantaged by timed cut-offs.  Obviously sooner or later if a coin that turns out to surpass bitcoin and/or even supplant it then those holographic stickers will need to be peeled off the Casascius coins but if it came to that it would be accompanied by great relief on my part that it was launched as a spin-off rather than as an alt that I missed out on completely!

Apologies D & T.  I had not read your point on this when I responded (I had forgotten I had more pages to read of this thread!) - hence deleting it after I'd read it.  I acknowledge it is very different in that the cutoff point will be known in advance and all claiming/trading will be done with this in mind - as opposed, as you say, to reclaiming 'inactive addresses' which is ex post facto.  

I still believe whatever the merits or otherwise of using the distribution of bitcoin as the means of distributing the new coin it is lessened when introducing a tool that has such a radical re-distributing outcome.

Peter,

In doing some research on merge mining an idea occurred to me that could potentially make claims easier by creating an OP_RETURN output on the Bitcoin network.  The spinoff could operate in a manner that would be best described as a SPV node when it comes to validating claims and thus would not need to know anything about Bitcoin scripting language.  Like a SPV node the "proof" that a claim is valid would be that it is sufficiently deep in the bitcoin primary chain.  This really would make the most sense for coins which are planning to adopt merge mining and intend to implement a claim window.  If you prefer we can discuss it by PM or in a new thread.

Of course, the claim window works however the guy doing it wants it to work.  If he excludes bitcoin addresses that haven't been used in the last year from his 'spinoff' that's still completely fair, because it's still changing nothing ex post facto; that's just the way that particular spinoff coin works.

Here is a very rough draft (more like putting an idea on a napkin at this stage)

Note: As the current time the draft limits itself to an alternate verification method for claims.  In the future if Peter sees continued merit, this entire draft would likely be a subsection of a general spinoff whitepaper.

Some useful references:
Original spinoff proposal by Peter R
Bitcoin whitepaper by Satoshi Nakamoto (see section 8 on SPV clients and section 10 on attack chain calculations)
Analysis of hashrate-based double-spending by Meni Rosenfeld

Proposal for a Simplified Claim Verification (SCV) Model

Introduction
The SCV (Simplified Claim Verification) is an alternate method of verifying spinoff claims which uses the parent chain to perform signature validation.  The original claim verification method outlined by Peter R could in comparison be described as a full claim verification.  The differences between these two models has some similarities to the differences between how full nodes and SPV (Simplified Payment Verification) clients validate transactions on the Bitcoin network.  The full claim verification requires spinoff clients to implement cross chain validation, the clients are larger and heavier but they have no outside dependency.  The SCV model is tradeoff by removing the validation of parent chain signatures from the spinoff in exchange for a dependency on the parent blockchain.   This dependency can be temporary through the use of claim window.

The full verification model involves the claimant signing a claim message using a parent network client or tool and then submitting the digitally signed claim to the spinoff network.   The spinoff network matches the claim against a ledger created from the unspent outputs of the parent network.  Some outputs are relatively simple.  The "normal" Bitcoin transaction is a Pay2PubKeyHash.  The output contains a PubKeyHash and a tx spending that input (or message assigning a claim) needs to be signed by the private key of the corresponding PubKey which hashes to the PubKeyHash in the output.  Bitcoin (and other potential parent chains) have more complex scripts and this complexity is increased by the fact that the output mut ay define multiple signatures or other conditions.  In some cases the output does not contain the script but instead a hash of the script (P2SH).  This means even a full parsing of the blockchain can not identify all possible script templates.  To be handle the redemption requirements of all claimants the spinoff would need to reproduce most or all of the transaction validation engine of the parent chain inside the spinoff client.   If the parent chain is Bitcoin, and the spinoff is very Bitcoin like this may not be a significant overhead but that is also the scenario that is the least interesting.  A spinoff which is radically different would end up maintaining a large amount of code which is only used for claim processing.

The SCV model like SPV model is a simplified verification process, that relies on assumptions that can be made when a transaction is deep in the best chain of a the blockchain.  A spinoff using the SCV model can without any direct knowledge of how the parent validates txs rely on the fact that an invalid tx deep inside the longest chain of the parent blockchain is not possible unless a majority of the computing power on the parent chain is either malicious or non-compliant (protocol flaw).

As transaction validation on a single network is an easier concept, lets look first at how SPV clients on the Bitcoin network use tx depth as a proxy for direct validation.  In the Bitcoin network the input of a transaction contains a reference to the unspent output of a prior transaction.  SPV clients do not maintain a full copy of the blockchain so while an SPV client can verify the referenced output is valid it can't determine is they are spent or unspent.  The SPV security model relies on the the fact that building an alternate blockchain is an expensive task and compliant nodes will not extend a chain with an invalid block.  If a tx is invalid (i.e. the inputs reference an otherwise valid but already spent output) then the block containing it is invalid as well.  Full nodes that block and build off the best valid chain.  So a tx which is hundreds of blocks deep in the best chain of a blockchain can be assumed to be valid unless an attacker has a majority of the computing power (51% attack) and even in that case the cost of the attack and the fact that it would only fool SPV clients makes it an attack vector of limited value.  

In the SCV model, the claimant creates a tx which contains an output with claim instructions for the spinoff.  The parent network is unaware of the spinoff but it will validate the tx like any other tx on the parent network.   The spinoff client may not know how to validate the the parent tx but it can rely on the fact that the tx is in best chain of the parent blockchain as an indirect validation which like the SPV model is valid as long as the attacker doesn't have a majority of the computing power (51% attack) and the tx is sufficiently deep that it would be infeasible to out build the majority of the network for a chain that long.   The spinoff client only needs to be able to extract the identity of the signer from the inputs and compare them to the claim identities recorded in the bootstrap.bin.


Definitions (some new concepts are introduced so I found it useful to define some new terms to avoid lengthy in-line explanations)

* TODO: Bad naming convention?  Looking for a name to clearly indicate the parent tx which encapsulates the claim payload.  It is needed to distinguish between the tx on the parent network and the tx created on the spinoff network.  Maybe some diagrams showing the relationship between the Claim Request, the Claim Payload, and the Claim Redemption.  Drop the "tx" from the definition?  Is it implicit?


Generating the Bootstrap.bin
As already proposed in this thread the bootstrap.bin will contain a ledger of "claims" against the spinoff based on the unspent outputs of the parent network at a designated blockheight (snapshot block).  No significant deviation from the proposed format of the ledger is required to support a spinoff using SCV clients.  

The spinoff will need to hardcode the blockheader (80 bytes) of the snapshot block of the parent chain.  It would be beneficial for the blockheader of the snapshot block to be part of the output for open source bootstrap creation and validation tools.  The block header is not needed for spinoffs using full validation but the small size is negligible compared to the benefits of a single automated open source tool.  The snapshot block header is the root of the subset of the parent chain required by the spinoff.  The blocks prior to the snapshot are not required because the bootstrap ledger contains the value of the unspent outputs as of the snapshot block.  From the context of the spinoff chain, the snapshot block becomes the genesis block for the (reduced) parent chain.

TODO: Determine the output distribution by unspent value instead of nominal number of outputs.
TODO: Determine if handling non-P2SH non-standard outputs warrants the complexity (distribution of the long tail).
TODO: Show optional method for reducing the size of native m of n outputs in the bootstrap.bin.
TODO: Show optional method for reducing the size of entire ledger by trading computing power for space.


Creating Claim Request Tx on Parent Network
The claimant begins the process by creating a Claim Request Tx on the parent network.   The tx consists of one or more inputs signed by the same identity as an unredeemed claim in the bootstrap ledger.  The tx can have one or more non-claim (standard) outputs.  This is necessary to "spend" the value of the unspent output(s) referenced in the input(s).    So far this is a "normal" transaction on the parent network however an additional OP_RETURN output with a zero value will be added.  OP_RETURN outputs are not spendable on the parent network but allow an arbitrary payload limited to 40 bytes.   OP_RETURN is prefered over other ad-hoc solutions as the OP_RETURN output is marked by the parent network as unspendable.  It doesn't bloat the UXTO and can be optionally pruned by nodes on the parent network.  If it important that the OP_RETURN output have a zero value and the sum of the values for the other outputs equal the sum of the values of the inputs (minus any tx fee) to avoid losing funds on the parent network.  

The 40 bytes recorded in the OP_RETURN output is the Claim Payload; it embeds spinoff specific instructions inside an otherwise normal tx on the parent network.  The Claim Payload should contain a "magic bytes" header to allow rapid identification of Claim Requests by the spinoff network, spinoff specific identifier indicating the identity/account/address that is encumbering the claimed coins, and optionally a fee paid to spinoff miners.  It is important to note the Claim Payload has no significance to the parent network.  It is just a blob of data outside the scope of the parent network (and one which may be pruned in the future).  The parent network is validating the larger Claim Request Tx.  The limit of its validation of the OP_RETURN output is to ensure it meets the limits specified by the parent protocol (for example in the Bitcoin network the embedded data in an OP_RETURN output is limited to 40 bytes, and a transaction is limited to a single OP_RETURN output).  The parent network can not validate the Claim Payload, that is a task for the spinoff network.


Validating the Claim Request By Proxy (simplified)
Before moving forward lets assume a simplified scenario where all nodes on the spinoff network have a complete continually updated copy of the parent blockchain.  This would be an excessive requirement and one that can by removed but it allows for a simplified explanation of how the Claim Requests can be validated without directly verifying the signature. Once a node on the spinoff network validates that the Claim Request Tx is sufficiently deep in the longest chain of the parent network it can conclude that the tx was properly signed even without verifying the actual signature (and all the complexity and overhead that entails).   What allows that assumption?  

If the tx was improperly signed, then the tx would be invalid.  An invalid tx included in a block makes the block invalid.   Any block built on top of an invalid block is likewise invalid.  Compliant nodes would reject the invalid block and build off the last valid block.

So lets look at three different scenarios:
a) The tx is improperly signed (a forgery) and the forger has no hashrate on the parent network.  The tx is dropped by all full nodes and if it reaches a miner, no compliant miner includes the tx in a block as it would make the block invalid.    Once the tx is included in any valid block on the parent network the spinoff can conclude this is not the case.

b) The tx is improperly signed and the forger has a minority of the hashrate on the parent network.  The forger could include the invalid tx in a block but other compliant miners would see that block as invalid and not extend that chain.  The attacker by luck could temporarily produce the longest chain but the deeper the tx is in the longest chain the lower the probability that an attacker with a minority of the hashrate could extend a chain longer than the compliant miners.  Even if an attacker has 40% of the hashrate on the parent chain, the probability that the attacker will have the longest chain after 89 locks is 0.1%.

c) The tx is improperly signed and the forger has a minority of the hashrate on the parent network.  Given enough time the probability the attacker will have the longest chain approaches 1. This would be a variant of the 51% attack however the cost can be made prohibitively expensive.  In a conventional double spend attempt the attacker is replacing one valid tx with another valid tx.  If the attacker is successful he double spends the victim and since his chain is the longest he claims the block rewards as well.  The value of the block rewards offsets the cost of the double spend attempt.   However in a SCV claim forgery the tx has an invalid signature.  The blocks created by the attacker will always be invalid on the parent network.   The attacker can only use that chain to spoof the SCV validation.   Even in a successful claim forgery the attack will lose the value of the block rewards on the parent network.  The cost of the attack is unavoidable.   Since a claim request only occurs once, that cost can be made prohibitively high for an attacker by requiring an increased number of confirmations (depth in the parent blockchain) before the Claim Request is considered valid.  As an example if using the Bitcoin as the parent network, the approximate value of the block rewards paid to miners is currently $2.3M per block day (144 blocks).  By requiring a Claim require 3 block days (432 confirmations) to mature even a successful forgery would cost the attacker more than almost $7M in lost rewards on the parent chain.

In this simplified model we assume that all nodes on the spinoff network have the full blockchain of the parent network.  We have shown that if the Claim Request Tx is not orphaned and sufficiently deep in the parent blockchain then the Claim Request Tx can be assumed to be properly signed unless the forger has a majority of the parent hashrate (51% attack) and a willingness to accept an extremely high irrecoverable cost in lieu of easier and more profitable attacks on the parent network  (i.e. double spends against crypto currency exchanges).  The cost and complexity of building a long flawed chain is used as a proxy instead of full validation a the transaction.   This is very similar to how SPV clients operate although the specific elements of what is verified by proxy are different.  The SCV model would not be very useful if all nodes had to maintain a full copy of the parent blockchain however this simplified model is easier to explain. The next section shows how the tx can be verified by any node on the spinoff network without access to the parent chain.

Validating the Claim Request By Proxy (actual)
In order for the spinoff network to validate the claim redemption tx it must confirm the following
1) The the claim_tx (contained in the OP_RETURN output) in the parent chain is properly formatted and otherwise valid.
2) That at least one of the input(s) of the parent chain chain has the proper signer and is not a double claim
 a) for Pay2PubKey tx = extract the PubKey, hash it, and compare to bootstrap.bin
 b) for Pay2PubKeyHash tx = extract the PubKey, hash it, and compare to bootstrap.bin
 c) for Pay2ScriptHash tx = extract the redeemScript, hash it, and compare to bootstrap.bin
 d) for native multisig tx = extract the PubKeys, arrange in canonical order, hash it, and compare to bootstrap.bin
3) That the tx is located in a valid Bitcoin block (blockheader, merkle branch, and txid can be used to prove this)
4) That the block can be linked to the "bootstrap snapshot block in the bootstrap.bin

All of these should be pretty self explanatory except #4.  The spinoff will need to be able to perform SPV level block verification (header only).  A copy of the block headers for the parent chain from the spinoff block to the closing of the claim window will need to be available to nodes on the spinoff network.  

For this reason this method of bootstrapping makes the most sense when the spinoff is being merged mined and has a claim window however it could be used on any network but at a minimum some miners would need to have dual network access (parent and spinoff).  The simplest method to record the bitcoin blockheaders into the spinoff chain would be to have an optional field in the spinoff blockheader for recording the bitcoin/parent blocks which are "mature" since the last spinoff block.  Other nodes do not need bitcoin/parent network access.  They are only validating that the blockheaders are valid not that they actually occur on the bitcoin network.  Some block validation rules will need to be developed, namely to reduce the orphan chains which are recorded in the spinoff only "mature blocks" are recorded.  This can be verified by requiring bitcoin blocks to be a certain number of seconds older than the timestamp in the spinoff block.  Since timestamps can be loosely verified (network median time) this ensures that only "old" (and thus very unlikely to reorg) parent blocks are recorded.   As an example if the network intends to consider bitcoin blocks more than 288 blocks (2 block days) deep in the chain as "mature" then the spinoff could require the timestamp of the bitcoin block be more than 288*600 = 172,800 seconds earlier than the timestamp of the spinoff block.

Bridging the parent and spinoff network

The claimee creates a Claim Request Tx on the parent network.  The Claim Request Tx exists only on parent network.  The information in that tx (inputs and the Claim payload) combined with parent blockheaders recorded in the spinoff blocks allow the construction of the Claim Redemption Tx (existing only on spinoff network).   One important factor is that construction the Claim Redemption Tx requires Dual Network Access however validating a Claim Redemption Tx only requires access to the spinoff network.  That is the key to the security model.  By ensuring that single network nodes can still validate all txs (including Claim Redemption Txs) the peer to peer nature is preserved and there is no reliance on trusted "super peers".  

The SCV model does require one or more entities need to have Dual Network Access to act as a bridge between networks.   Without these bridge nodes the spinoff network will never become aware of the Claim Requests (as they exist on the parent network).  The bridge nodes can not alter or forge redemption txs.  A bridge node is limited to refusing to relay information from the parent network and this withholding attack would only be effective if all bridge nodes engaged in withholding.  There is no special cost in running a bridge node beyond the resource requirements of each network so the attack would not be very effective.  Miners are a logical choice to act as a bridge node but as a fallback non-mining nodes can also act as a bridge.

Dual Network Mining Nodes: Spinoff miners who have dual network access can construct the Claim Redemption Tx (part of spinoff network) by identifying Claim Request Tx (part of the parent network).  The Claim Tx can be constructed in a deterministic and trustless manner by any party with Dual Network Access.  The instructions in the claim payload of the claim request made by the claimee on the parent network ensure that a miner can't modify a request as the tx would be invalid.  The claimee doesn't need to do or submit anything on the spinoff network (the Claim Reward Tx doesn't need to be signed as it is similar to a Bitcoin coinbase tx except the output is constrained by the instructions in the Claim Payload.  Miners with dual network access will need to parse the blocks of the parent blockchain, located Claim Request Txs, construct the Claim Redemption Txs, and record them in blocks on the spinoff network.  There should be sufficient incentive (in the form of tx fees possibly subsidized as a tx reward similar to block reward in the Bitcoin network) for some miners to maintain dual network access.  Miners opting to run dual networks would not be required to broadcast these Claim Redemption Txs before including them in a block and thus it would be in their best interest to include them in the next block as a source of additional fees.

Non Mining Bridge Nodes & Single Network Miners: If the Dual Network miners fail to include Claim Redemption Txs in spinoff blocks in a timely manner non-mining "bridge nodes" (possible setup as a fallback by the developer for the public good) could parse the parent blockchain, construct the Claim Redemption Tx and broadcast the txs to peers who would validate and relay them like any other txs, and the tx would eventually be included in a block by Single Network miners.  It is probably unlikely this would be needed, but it illustrates that the miners who have Dual Network Access can't do anything malicious with that access.  At best they may learn of Claim Requests before other nodes and can include them in a block for additional fees but the value of that knowledge rapidly declines.   To encourage dual network mining, the bridges could operate on a delayed fashion waiting a few blocks beyond when a Claim Request is mature.   This would give dual network miners, "first chance" at those fees, creating a built in incentive while preventing any type of cartel behavior as the information only has "value" if acted upon immediately (before all nodes learn of the new txs and their fees).

Recording the Claim Redemption Tx in the spinoff blockchain
It is important to keep in mind that the Claim Redemption Tx will exist only on the spinoff network and the spinoff network may be radically different than the parent network.  It is thus beyond the scope of the spinoff concept to define the exact claim redemption format (for example txs on a network using ring signatures or zero knowledge proofs would look radically different than "Bitcoin txs".   Whatever the format used there are data elements required to ensure that the Claim Redemption Tx can be validated by single network nodes.  The raw Claim Request Tx (pulled from parent network), the block hash of the block containing the Claim Request Tx (on the parent network), and a merkle branch are required.  How these elements are used to validate the Claim Redemption is described below.

Example Claim Redemption Tx (actual redemption tx will vary based on the constraints and design of the spinoff network)

* Recording inputs is not required (similar to how there is no requirement for coinbase tx to show the "input value") the "inputs" are extracted from the inputs in the claim_request and validated against the unredeemed claims in the bootstrap.bin.  Explicitly recording these inputs may be useful for optimizing the "unredeemed claim set" (similar to the UXTO in Bitcoin network).  

** The exactly output structure will depend on the requirements and constraints of the spinoff network.  The format and required elements of the claim payload will work in conjunction with the output to ensure the value is secured by the claimee.  For a c


Pseudocode for validating the Claim Redemption Tx

Required:
Spinoff nodes is well connected to peers.
Node has a full copy of the spinoff blockchain according to peers.
Node has constructed a "unredeemed claim set" which is a subset of the bootstrap.bin excluding all claims which have already been redeemed.
Node has constructed a header only subset of the parent_blockchain by extending from the snapshot block using parent_blockheaders located in spinoff blocks.

Perform the following:
1) parent_block_hash = H(parent_block_header) per parent tx rules
2) parent_txid = H(parent_tx) per parent tx rules
3) Parse input(s) based on known templates, identify the signers, and match against the set of unredeemed claims.  The inputs[] = set of unredeemed claims matching input signers.
4) Extract claim_payload from parent_tx.
5) Compute c_merkle_root using the tx_id and merkle_branch.

Claim Redemption is valid only if all the following are true:
1) The parent_block_hash is located in the parent_blockchain constructed from parent_blockheaders in spinoff blocks.
2) The parent_block_hash is not part of the best chain or is not sufficiently deep in the best chain.
3) The c_merkle_root is the same as the merkle_root recorded in the parent_block.
4) The inputs[] is not null and the value of the output is equal to sum to the value of the claim inputs.
5) The claim payload is valid per the spinoff protocol and the resulting tx properly encumbers the output based to the limitations set in the Claim Payload.

Advantages & Disadvantages of SCV Model
PRO: The parent tx validation complexity is removed.  The spinoff doesn't perform a validation on the Claim Request Tx containing the claim payload (this is done by the parent).  The spinoff does needs to be able to identify the Claimee and match it against the authorized claims in the bootstrap.bin by extracting the unique identifying criteria from the input(s) of the Claim Request Tx.  The scope of this problem is significantly smaller than understanding the full validation rules in all possible permutations of the parent chain.

PRO: More than 99.9% of outputs can be categorized into less than 30 variations of 5 basic templates which reduces the code overhead imposed by the parent on the spinoff.  It is possible that 100.00% of potential claims could be validated with a significantly smaller bootstrap.bin and less code overhead than what would be required for a "full validation" claim redemption model.  **
PRO: Spinoff network doesn't need to interpret the redeem script (P2SH) which makes compatibility easier to assure because P2SH scripts are unknown until spent
PRO: Miners can handle the seamless transfer of claims from parent network to spinoff

CON: This requires the spinoff to record all blockheaders of parent chain from the snapshot block forward until all claims have been redeemed.  This is unlikely to ever occur unless a claim window is designated.
CON: Security model is different but comparable to SPV clients not full nodes.  The risk is moderated by using a parent network with very high mining difficulty/cost and requiring long maturity of parent blocks to make forgeries prohibitively expensive.
CON: Requires at least some but not all nodes to have dual network access (to transfer blocks and claim tx from parent network to spinoff network.  the effect is reduced if the network is already merge mined)

** TODO: Replace with distribution by unspent output when available.

I'm just wondering whether using CIYAM might be an appropriate means of allocating and managing bounties for this project?  I'm uncertain exactly how it works and am not affiliated.  I'll post a link to this thread to Ian of the CIYAM project to see if he would like to explain and maybe offer to get involved.

It is still rough but I believe the core idea is sound.  There probably are issues I haven't anticipated but I don't believe any of them would break the solution.  As rough as it is, it was good to get it down on paper at least as a starting point.  The rough concept has been rattling around in my head for a long time (probably more than a year).  The more I got interested in your spinoff idea the more I realized this could be adapted to it.


Agreed.  You probably already realize this but I will just restate it in case it is not obvious to anyone else following the thread.   The system will work even if there is only a single spinoff miner with dual network access.  The parent chain recording will be "clunky" (i.e. 10 blocks with no parent block headers and then the one dual network access miner publishes a block with a flood of parent chain headers).  Obviously it is optimal if a large number of miners have dual network access.  I see a number of ways this can be incentivized

a) Parent block header is required in spinoff block (or there must be at least one parent header in the past x blocks inclusively).  Obviously you get 100% of miners to be dual network capable.  I don't particularly like this solution as it may make some users decide to not mine at all (and healthy mining support is critical for the bootstrap phase) but it is an option and may make sense for a chain which supports merged mining with the parent.

b) Parent block header is optional and there is an increased block reward for the inclusion.  This is as you suggested and something I considered but I must be a paranoid person because anytime I have an idea the first thing I think of is how could this be abused not how it is helpful.   Still it has helped me to not lose a single satoshi (personal, company, or customer funds).   In my earlier concept I wondered about a malicious entity bloating the spinoff by including inferior chains.  I believe that keeping the spinoff's link to the parent network behind (deep in the parent blockchain) this issue isn't much of a viable attack although I wouldn't mind other people considering how they could break or abuse it.  Although the attacker isn't compensated for this bloat in the other scenarios I cover it in general below because "Some Men Just Want To Watch The World Burn".

c) parent block headers are optional but there is no increased block reward.  Miners can not collect claim fees until the parent block chain has been extended so they have an indirect incentive already.  This can optionally be strengthened by a fee subsidy on claim txs.  The subsidy fee would simply be additionally "minted" coins just applied per tx not per block.

I can see any of these options (and possibly others) working.

Security Note:
The entire parent block header system should be carefully analyzed.  I tried brainstorming but couldn't come up with any attack vectors which are particularly viable although this isn't a guarantee that I haven't missed some obvious (or not so obvious) attack vector.  The foundation of the claim security model rests of the the fact that the spinoff can learn of the "best chain" on the parent network and building a forgery chain (one which has invalid claim txs but is otherwise valid) that is better is infeasible.

This breaks down to 4 assumptions:
a) It is infeasible for one to build a chain that continues to remain longer than the best parent chain unless the attacker has a majority of the computing power.
b) If the attacker has a majority of the computing power on the parent network, the cost to use that to attack the spinoff would be prohibitively expensive.
c) If the attacker has a minority of the computing power, the length of the chain needed to forge a claim tx makes the probability that an attacker can "fool" the spinoff long enough to complete the attack.
d) There is nothing which can prevent the spinoff chain from learning of the best chain on the parent network and thus reducing the strength of the other security assumptions.

I believe these assumptions are valid and I can not find any attack vector which wouldn't be prohibitively expensive and of dubious value, although I welcome some critical analysis of possible attack vectors to the spinoffs reliance on getting "good blocks" from the parent network as it is the foundation.  The rest of the security model for the SCV (simplified claim verification analogous to SPV) relies on that foundation. 


Good points and ideas but I ran out of time. I will respond to them in a future post. 

after reading thru the comments, i still believe sticking to the original idea of no time limits to claiming spin off coins is most appropriate.

1.  as others have pointed out, there are a lot of physical bitcoins out there that ppl will be unwilling to crack open to sign for spin off coins.  if this happens, it is a statement that, on balance, those ppl do not believe enough in the spin off to go to the trouble of claiming their spin off coins which will decrease its legitimacy and chances for success.  let's face it; spin offs should ideally only be applied to alt schemes that actually do have a chance for success.  and if a dev goes to the trouble of creating the spin off, everyone involved including the Bitcoin holders who will be receiving distributed coins, will want the spin off to blossom as it will increase their wealth.  thus, anyone not claiming spin off coins are in essence saying no.  if they do bother to crack their physical bitcoins open (i won't be), this exposes them to theft, their location, and deanonymization, which is also not good.  some ppl have their paper wallets or physical bitcoins scattered in places all over the world.  quite an inconvenience for them if they want to claim their spin offs.
2.  no matter how much advertising you do, there will inevitably be ppl who don't hear about the time limit and may come back years later crying foul after having come out of a coma or some such excuse.
3.  i'm also worried about the effects on Satoshi himself.  you are in effect forcing him to make a choice; stay anonymous or become public.  as i said above, if he stays anonymous and fails to claim his spin off coins, that could be a big statement in his not believing in the spin off which could have unpredictable effects on its value (one can't assume greater value just b/c he fails to claim his spin offs).  or, he might be dead.  or he might not have heard of it.  as of today, we don't know what has happened to him and the market has priced this in and accepted it.  if he does claim his spin offs, immediately everyone will know he is alive and well and might infer he is greedy.  what blow back effects will that have on Bitcoin itself?  if he is deemed greedy, then ppl might conclude that he may well in fact dump his bitcoins in the near future, as well as the spin off coin.  otoh, maybe it will signal his belief in a particular spin off and its merit.  most importantly, if he does claim his portion of the spin off, i believe his physical security might be put in danger as he might inadvertantly reveal his location or identity.  
4.  as smooth said, all these redistributive proposals have to be recognized for what they are.
5.  you can claim that as long as you make everyone aware of a time limit at the beginning it is fair and that would be true.  but that misses the point that all present day uncertainty and perceived unfairness in Bitcoin is currently built into the blockchain.

the point is we don't know what type of market effects these different scenarios will have; which is why wanted to neutralize them by assuming all uncertainty is encoded into the initial distribution of the blockchain and that they would be seamlessly transferred to a promising spin off.

Yes.  This ties into the idea of coming up with "best practices" which go beyond technical implementation.   If today a hypothetical spinoff developer decides without explanation to use a snapshot of block 187,209 that would probably be a red flag.  Technically any block could be used to build the bootstrap.bin but barring some justification using a block that far in the past is dubious.  Why such an old block? Why 187,209 and not 187,208 or 187,210?  Using a recent block preferably one announced in advance is more transparent (i.e. announcing today that the bootstrap.bin for xyzCoin will be built using a snapshot of block 320,000).

This could wreak havoc with demand for coins residing with trusted parties, until they make plans to claim the coins for you, and even then it could show them up if they have altcoin flow issues or short unclaimed coins, I'm so looking forward to this. Evan an anticipated spin off-with the right hype could impact the Bitcoin price.