But what do you think about it? Does it make sense? Would it be feasible?
I'm willing to evaluate the feasibility of proposed schemes if they are specified in sufficient detail. Your proposal is substantially different from bitcoin and the information you provide is not sufficient to provide a clear understanding of how it would work.
ByteCoin
I'm sorry, I tried to explain it clearly.
I'll try it again. Please ask whatever you want if a fail explaining myself again.
1) Differences from bitcoin:
-There's no conflicting transactions.
-The transactions have an expiry block number field. They can only be included in the block chain (they're only valid) if that block number has not been created yet.
-There's no mining. No currency is issued in block creation.
-Less time for block generation would be desirable.
2) Why would anyone include other people's transactions in their own block?
When someone wants his transaction to be included in the block chain, he preforms some proof of work to add it to his block mini-block and sends it to the network. He decides the difficulty target (there would be a minimum).
Another one can include this mini-block to his own and the work of the included block is added to the work of his mini-block.
The more work you put in your transaction, the more incentive other people have to include your transaction.
When a mini-block contains enough combined difficulty to become a proper block, well, it becomes a block and is added to the block chain.
3) The possibility of eliminating the time target (eliminate the difference between a mini-block and a proper block) by enabling chain merges.
When a chain branch becomes orphan in bitcoin, the following adverse effects take place:
-All the bitcoins generated in that branch are lost.
-All the fees charged in that branch are lost.
+All the transactions can be included later in the main block chain (this is not adverse).
When a chain branch becomes orphan in this ripple implementation, the following adverse take place:
-All transactions that have expired are lost.
-Some of the not expired transactions can be included later in the main chain, but they have to be included before they expire.
In this system we could have merges and avoid the lost of transactions, but there's a possible attack.
The payer want his transaction to be included in the block chain even if they've expired. It's not the payer who decides the expiration block number but the promisors (I don't think that more detail in this is necessary).
If merges are allowed, the payer can try to cheat the timestamping by creating an artificial branch that continues a block previous to the expiration block and then wait for that branch to be merged.
The first solution that comes to mind is to require a minimum length (in work) for the branches to be merged. But then the payer just need more time/computer power to cheat.
Merging must have more restrictions. A maximum difference (in work) between the main (the longest) chain and the branch to be merged is needed.
This maximum difference has to be proportional to the length of the chains since the fork. For example, the branch can be at most 10% shorter than the main chain to be merged.
What incentives nodes to merge chains?
The combined work of both branches will count as the length of the chain after the merge. So if one commits his transactions on top of a merge is likely that the transaction stays in the longest chain.
Maybe I missed something. Please, feel free to ask whatever you want.
