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.

closed as primarily opinion-based by Nate Eldredge, Dennis Kriechel, Jan Moritz, dchapes, David Schwartz Aug 8 '14 at 0:24

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    "Please comment on my essay" type posts are not a good fit for the Stack Exchange Q&A format. It's more appropriate for a blog. – Nate Eldredge Aug 7 '14 at 3:48
  • I didn't want to copy the entire post here to ask a relatively simple question. – Kent Aug 7 '14 at 4:13

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?

  • 1 - The double-spend problem is dealt with in the same way as it is with the current bitcoin network: The longer (computationally difficult) the block chain gets, the more secure previous transactions become. 2 - Short-interval blocks will not be good for blockchain storage, and it's even worse due to multi-pathing. However, less transactions per block will leads to significantly smaller blocks. Finally, most miners/users can drop old information (and only keep a couple months of data recorded). Same as with standard Bitcoin, it would scale with use. It will definitely be a manageable size. – Kent Aug 7 '14 at 4:11
  • @Builder_K Since you still need to wait for sufficient proof of work before you can consider a transaction to be confirmed, what's the benefit? All you've done is generate blocks really fast. Why is that good? – David Schwartz Aug 8 '14 at 0:26
  • The whole point, is that if a transaction is in two blocks, which are then merged into a third block, the computational difficulty of forcing a double spend is the added sum of all parts, in this case, the added sum of all three blocks' difficulties. In order to force a double spend, an attacker would need to outpace all of these blocks. In this way, an attacker is forced to work against to processing power of the entire weave, instead of only outpacing a singly-linked block chain. – Kent Aug 8 '14 at 0:45
  • Also, since the weave can split & merge as needed, distant nodes do not need to be immediately aware of each other's activities, allowing for a much faster block generation rate (Without the network constantly dropping invalid side chains). The whole purpose here is to combine the processing of the network against attackers, rather than allowing the winner's block to make choices for the entire network. This more quickly locks out the possibility of attackers catching up to the network, allowing for extremely fast and secure transactions. – Kent Aug 8 '14 at 0:48
  • 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).
  • 1 second is not enough -> See note 3 towards the end. Runner ups are not well defined -> The runner-ups don't need to be well defined, each node chooses the highest-cost blocks that if knows about, and merges them into the new block. Block rewards are assigned by... -> As time passes, and the chains are merged back together, it can be determined which path took the most work to generate, only the highest-cost path generates coins. Going back in time, create sidechain -> the sidechain would have a lower creation cost than the master, so it could never force an invalid transaction. – Kent Aug 7 '14 at 21:29
  • Never getting two blocks that do not conflict -> Transactions are the only thing that can conflict, and (as described in the document) these conflicting transactions are dealt with as the blocks are merged together, by simply choosing the most-verified (i.e. highest computation-cost-to-verify) version. If a transaction is in both blocks, there is no conflict. – Kent Aug 7 '14 at 21:35
  • Any modification, i.e., removing conflicting transactions, invalidates the proof-of-work that made the runner up a block, hence making a purged block indistinguishable from something that does not meet the proof-of-work requirements. – cdecker Aug 8 '14 at 10:11
  • No, the invalid transaction is not removed from the block. it is simply noted in the new block which of the two competing transactions is the real one. This was, only a single side of a single competing transaction pair is invalidated, not the entire block. – Kent Aug 8 '14 at 22:23

Not the answer you're looking for? Browse other questions tagged or ask your own question.