Quote from: ETFbitcoin on November 10, 2018, 04:07:03 AM

I barely understand your paper, but my thoughts are :
1. As aliashraf mentioned, merkle tree already very efficient. Besides, how about transaction verification by SPV wallet? from what i understand, SPV wallet need to get whole block to verify the transaction.
1. I don't see much advantage points of adding Bounce since it's value can be generated/modified with no cost.
2. While this idea could reduce "wasted" electricity since PoW based on winner-takes-all, total electricity used for mining is still same.
3. In part 5, it mentions that "and when there is no transaction in transactions pool, the system code could generate a rescue transaction for a new block and miners could still compete". I see there's conflict possibility due to transaction propagation, few nodes might generate rescue transaction just before receive a transaction.

Hello ETFbitcoin, hope all is well.

1- I need to refer you to the insertion sort and merge sort comparison part of answer to Ali. And about Simplified Payment Verification (SPV) - as I know too - SPVs just keep the header of blocks and download partial content of blocks whenever they are needed. There is also a paragraph in document that describes SPV.

1 again- The whole idea behind adding Bounce values in transaction level is great and is what I really like it. Bounces in transaction level just work as nonce values in block header. So you still need to find a proper bounce value to meet an individual difficulty for a transaction. But first of all, bounce values are different from one transaction to the others so they are customizable. A user may order a difficulty target for her own transaction and pay for it. Nonce values are good for proof-of-work but bounce values are created for both proof-of-work and increasing the overall security of the network. This is how a bounce value works:

Imagine we have a hash (SHA256) value like this:

6D58A06DC487C30E5309FAEF7764C5C6D8E63EB50E437C4D473CA3E19601313F

With a custom difficulty level of 7 we need our miners find a bounce value that its output hash value begin with the first 7 characters of our input string:

6D58A06

And its bounce value should fit in a formula too. For example bounce values should be greater than the sum of digit parts of the input hash string too. Also, each zero may mean multiply the sum of digits in 10:

From 65806487305309776456863504374473319601313
Sum of (658648735397764568635437447331961313) =
180 x (10^5) = 18000000

So the output hash may be something like this:

6D58A069F1645B816F40DA4B91BBF9C401BAA3074D1D93C395EBBB4D102A09AB

With bounce value of 21734093 that is greater than 18000000.

Forcing bounce values to fit in a formula makes their output hash values higher resistant against collision attacks. There are reports like link bellow that shows a pattern in nonce values of classic crypto-currencies, so bounce is going to change the rules of the game:

https://bitcoin.stackexchange.com/questions/24650/looking-for-nonces-of-even-numbers

2- Let discuss power consumption with simple calculations. Imagine we have 1000 miners in a classic blockchain and the target difficulty of 10 zeros which carries 100 transactions in its content. When 1000 miners begin to compete we know that finally 999 of them will lose the reward and waste energy in fixed level of a high difficulty target e.g. 1500 KWH.

Now let remove the nonce value from block header and say to our miner army find their prize in 100 different transactions (note: this is not a transaction fee). If we dont want to make things complicated, we could see we have 900 of miners that lose, but in different range of difficulty target (e.g. proceeding for 4 to 10 zeros) so we have improvement in rewarded miners from 1 to 100 with less waste in power for both winners and losers. Now miners could define their strategy to compete in a race that may finally lose 10 KWH or 1500 KWH which could lead us to new segmentation model. What I really tried to design is about defining a group of pre-mined transactions as a block; so you as end user could rent a dedicated miner (CPU, GPU or ASIC) to pre-mine your transactions, which could put us in the most ideal power consumption situation and break down any kinds of gold rush in a crypto-currency network. This means end users will rule these kinds of networks, not those miners who own the most hash power.

However Shahin Go-Round has its own method in transaction segmentation, but you could find some other new ideas here in this paper too:

http://www.mixoftix.net/knowledge_base/blockchain/scaling_blockchain_to_human_commerce.pdf

3- True, however I could accept this as a price that we pay for benefit from the advantages of a decentralized system. And we have two options here: one, we could ignore to pay reward for a block that contains no transaction. No activity, No Profit this is fair. two, still follow the rule of longest chain is the valid one and accept unexpected rescue transaction as a natural event that sometimes happens in the network.

-- Shahin