user18666: I've written a proposal for an extremely extremely high-speed transaction verification algorithm: 
http://kenthagerman.blogspot.ca/2014/08/weavecoin-high-speed-crypto-currency.html
Is this possible? Is there anything in the standard Bitcoin algorithms which would be broken by these changes?
Let me know if the document is difficult to understand in any way, and I'll revise it.

user11253: Two things jump to mind:

This does not appear to adequately address the double-spend problem. How long must one wait to be certain that the transaction that was just "confirmed" will not be superseded by a different transaction, rendering the first one invalid?
Have you calculated how a 1-second block generation interval will affect the blockchain storage profile over time?


user120: 
1 second is not enough to propagate a block to a majority of nodes in the network. In todays network even a single transaction takes 1 second, so how can a larger structure be faster.
Runner ups are not well defined
Block rewards are assigned by including a reward transaction into the block, which becomes valid if the block becomes part of the blockchain. If we also make the transactions in merged blocks valid, then more than one reward is awarded. Notice that you cannot fix this problem by simply dividing the reward by the number of chains that you are merging since any two chains may conflict and you don't know how many chains will be merged.
You allow people to go back in time, create a sidechain (if the merge limit is not filled) and then merge it in a higher up block, effectively backdating a transaction to the merge's time. You'll need to address the problem of such a transaction invalidating a transaction included higher up in the blockchain.
I believe that it will be a rare occasion that, disregarding the reward transaction which conflicts by default, you'll ever get two blocks at the same height that do not conflict (they contain the same transaction).


18666: <p>I've written a proposal for an extremely extremely high-speed transaction verification algorithm: 
<a href="http://kenthagerman.blogspot.ca/2014/08/weavecoin-high-speed-crypto-currency.html" rel="nofollow">http://kenthagerman.blogspot.ca/2014/08/weavecoin-high-speed-crypto-currency.html</a></p>

<p>Is this possible? Is there anything in the standard Bitcoin algorithms which would be broken by these changes?</p>

<p>Let me know if the document is difficult to understand in any way, and I'll revise it.</p>
 11253: <p>Two things jump to mind:</p>

<ul>
<li><p>This does not appear to adequately address the double-spend problem. How long must one wait to be certain that the transaction that was just "confirmed" will not be superseded by a different transaction, rendering the first one invalid?</p></li>
<li><p>Have you calculated how a 1-second block generation interval will affect the blockchain storage profile over time?</p></li>
</ul>
 120: <ul>
<li>1 second is not enough to propagate a block to a majority of nodes in the network. In todays network even a <a href="http://bitcoinstats.com/network/propagation/" rel="nofollow">single transaction takes 1 second</a>, so how can a larger structure be faster.</li>
<li>Runner ups are not well defined</li>
<li>Block rewards are assigned by including a reward transaction into the block, which becomes valid if the block becomes part of the blockchain. If we also make the transactions in merged blocks valid, then more than one reward is awarded. Notice that you cannot fix this problem by simply dividing the reward by the number of chains that you are merging since any two chains may conflict and you don't know how many chains will be merged.</li>
<li>You allow people to go back in time, create a sidechain (if the merge limit is not filled) and then merge it in a higher up block, effectively backdating a transaction to the merge's time. You'll need to address the problem of such a transaction invalidating a transaction included higher up in the blockchain.</li>
<li>I believe that it will be a rare occasion that, disregarding the reward transaction which conflicts by default, you'll ever get two blocks at the same height that do not conflict (they contain the same transaction).</li>
</ul>
