Topic: Increase # transactions per block without raising block size? (Read 809 times)

The first time a new transaction sent is not important. Such payment can be lost, disappear or part of doublespend scam.

Bitcoin can operate correctly when only block travel on the network and everybody will not see a difference.
Users can send payment to his miner by any other method such as email, sms, website. It's not really a problem.

The serious business is actually sending blocks, not payments. For miner it is very important that everybody in the world can see the whole block including all payments because that allows other miners to immediately check if every rule is correct. The other miners must do this check because if there is problem like payment with bad signature(scam), they all lose reward funds (not just the first miner) and mining power got wasted.

Thanks for your response. The main point of the idea stated above is to increase the number of transactions in a block, without the need of raising the blocksize, to ensure propagation time similar to its current implementation.

Transactions need to be send and propagated anyway, but why do this twice? First the actual transaction is send, second, the transaction is send in the block body. Larger transactions, say 100kb, also require a larger fee, as in the current Bitcoin protocol, I would not consider that a concern. Also, nowadays large-size transactions can be created and send, too. Actually, that supports the question, why send a transaction twice?

To recap:
-transactions can be of any size, but larger transactions require larger fees
-transactions are propagated within 10 seconds to 90% of the network, and stored in the mempool
-all valid transactions received are hashed (SHA256 / /SHA128)
-a block is max 1 MB, containing a header, and a body. The block body contains  hashes of the transactions. The block header also contains the Merkle root of the transactions of which the hash is included in the block.
-a block is mined, 600 seconds on average, send, and propagates in the network.
-the hashes in the body of a valid block are matched against the hashes in the mempool.
-the block is added to the chain, containing both hashes and transactions.

*blocks send in the network are 1MB only. <-- main point: keep the blocksize similar but increase the number of transactions in the block.
*block stored on the blockchain are 8.8 MB <-- perhaps optimization will decrease the block size

Anyway, only from the hashes, the others cannot verify if the transaction is OK or BAD.

So they need to recieve the actual transactions anyway.

And the reason why complete 1MB blocks are circulated around the network is to ensure that

Even if some machine missed some transaction, it will see it again when the block is circulated.

Hello. I understand what are you trying to say, you want the cap only for the hashes.

This solution is equivalent to say maximum 31250 transactions per block (because hash is allways same sized).

Obvious problem

Somebody could try to make very big transaction. Like 100KB transaction, then 31250*100KB = 3.1 Gigabyte block. your 1MB of hashes rule is satisfied.

Obviously such large block would not be transmitted and the transactions checked for validity in less than 10minutes and whole network could collapse upon mining such block.  The slow internet nodes will be clogged first. WHY?  Before the nodes fully recieve the block , they can't even check if the block is truly valid. Imagine 3 Gb correct transactions, and last one spending funds that do not exist. But nodes discover this only after 3gb download - and during the time they don't know if they should mine on top of it, or on top of the previous block.

The satoshi's 1mb cap is a better solutions because actual size of transactions is measured. this allows smaller transactions to be cheaper and motivates users to create tiny transactions.

Need to clarify on that.

The size of the block created by a miner is 1 MB. The idea is that blocks of 1 MB are propagated faster then, say, 8 MB blocks, thus limiting the chance of a fork.
Once the block has been propagated, the block stored indeed is 8 MB. Though my guess is that this can be improved. The initial idea is increasing the number of transactions per block while keeping block propagation time stable.

I thought you said your idea would not raise the block size?


Doesn't this mean that the block in the blockchain would be 250 bytes per transaction plus 32 bytes per hash times 31,250 transactions?  So each block would be:
(250 +32) X 31,250 = 8.8 MB?

Since the current block size is 1 MB, and you are creating blocks that are 8 MB, it sure sounds to me like you are increasing the block size.

With the many scalability discussions and proposals out there, I was wondering if anyone ever considered the following.

Current situation.
Blocks take an average of 10 minutes (600 seconds) to mine. Each block has a size of 1 MB (1.000.000 bytes (8.000.000 bits)), and each transaction is on average 250 bytes. So, each block can contain approximately 4.000 transactions. With an average of 600 seconds per generated block, 4000/600 = 6,6 = 7 transactions per second (tps).
Valid transactions are stored in the mempool. Bitcoin transactions propagate in the network within, say, 10 seconds to 90% of the network (http://bitcoinstats.com/network/propagation/).

Idea
Now, what if all nodes create a hash (SHA256 (each hash is 256 bits)) of each valid transaction received. Each mempool stores 1. the transaction and 2. its hash. A miner creates a block, but instead of collecting actual transactions in the block body, the block body contains hashes of the transactions. On average, each ten minutes a block is propagated in the network, and all nodes receiving the block match the hashes in the block body with the hashes (and their corresponding transactions) in the mempool. The mempool is cleared of those transactions (assuming no fork occurs), and a block is added to the blockchain containing a body with both hashes and transactions.

By doing so, each block can contain (excluding the coinbase transaction) 1 MB = 8.000.000 bits / 256 bits = 31.250 transactions. The number of transactions in a block is 7 times larger (edit: 14x with SHA128, almost 100 tps without tree optimization), without having to increase the block size.

Feedback
My guess is that, similar to Gavin Andresen's IBLT proposal (https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2) a possible concern is that mempools are not synced. In the above example, I'm assuming that the transactions of which the hash is included in blocks, are stored in mempools considering the 10 second transaction propagation time versus the 600 second block mining time.

Any thoughts?