Quote from: chodpaba on March 12, 2011, 01:04:26 AM

Quote from: rfugger on March 12, 2011, 12:46:15 AM

Normal "blocks" wouldn't generate coins anymore, since there is no target difficulty. You could still have coin-generating blocks, but they would only contain the generating transaction, and have to meet a target difficulty. Two generating transactions in parallel streams would conflict. See my post re: generating transactions.

It is a somewhat different system in that it shifts the burden of proof of work from a few block-computing machines, to anyone who wishes to record a transaction.

If I get you... In your proposed system generating normal blocks would not be computationally intensive, but generating transactions would be.

No, I believe it's the other way around.

I think the problem is you and rfugger have different definitions of "normal" :-)

I think this won't hurt scalability if the 'headers only' protocol gets implemented. I think this idea might be worth exploring a bit more - I've been thinking along the same lines myself.

The proposal, as I understand it, is to have a "trading block" and a "mining block." The mining block would be the equivalent of what we currently have: it requires proof of work to be accepted by other peers, and it generates new bitcoins out of nothing, and claims any transaction fees for transactions included in the block.

The trading block, on the other hand, would consist of nothing but transactions (most likely a single transaction from the originator). Since it does not generate any new bitcoins, there is no work involved, and therefore no proof of work is required. And, since no work is required, it is not eligible to claim any transaction fees.

Think of the new trading block as an interim, semi-official confirmation. Kind of like a temporary driver's license.

The miners would still generate mining blocks, as usual. The mining block still includes transactions, and it is the mining block that is considered the official confirmation of the transaction.

To generate a trading block, the software first checks to see if it has received any trading blocks from its peers. If so, and if the root of the trading block chain is your node's highest mining block, then it uses the trading block as its previous block, otherwise it uses the highest mining block. It then creates the trading block and broadcasts it to connected nodes.

Sooner or later - most likely well before the next mining block appears - another peer will generate a transaction, and append its trading block to the one your node just sent out. When you receive that trading block, you have a confirmation - your temporary driver's license.

Multiple branches off the same mining block will occur, but that's OK because they won't (shouldn't) last more than 20 or 30 minutes. But, we'd have to figure out a way to encourage peers to use existing trading chains, or combine multiple trading block chains of depth 1 into a single chain.

Now, if yet another peer happens to receive the second trading block before it receives yours, then it broadcasts a request for your trading block and/or transaction.

As today, miners put incoming transactions in their memory pool, gather them into a block, then start working on the block, giving preference to transactions in trading blocks, and claiming any transaction fees associated with the transactions.

When nodes receive a new mining block, then they discard trading blocks where the transaction is in the mining block.

The incentive to use this system is to get quicker confirmation of transactions.

There are still a lot of gaps, and I'm sure there are problems I'm overlooking, but as I say, I think this is worth thinking through.