Topic: Using "blockpool" instead of mempool (Read 181 times)

Of course all of them, as it is today (up to mempool limit around 300 MB, as it is today). If the transaction is totally new, it will just begin with very easy proof of work. And when some node will see the same transaction with higher proof of work, it will be replaced. And if there will be two blocks having the same transaction, the block with lower hash will win.

Of course, they can pick any transaction, even if it is non-standard or has no fee, if they really want. The users are not mining their transactions, so they can only observe what miners are telling them, they cannot change it without having significant computing power or enormous amount of luck.

Yes, and it have to be changed anyway, because in other case there is no progress in mining. It does not matter if the order of transactions is changed, some transactions are replaced with other transactions, or if the coinbase is changed. There have to be some change, but it does not really matter what will be changed as long as produced block is valid and has lower difficulty than the block being replaced.

But they are and they will put more and more trust in 0-conf transactions. For example, the whole lightning network is based on 0-conf transactions.

Yes, the final block will always have the last word on what is valid and what is not. But as long as something is unconfirmed, it just may be convenient for user to have some feedback instead of just knowing that some transaction is still unconfirmed.

Reducing the block intervals will reduce difficulty, assuming the same network power. There is no difference between 30 confirmations on chain with 20 seconds block time and 1 confirmation on chain with 10 minutes block time, assuming everything else remains the same. Doing this at mempool level is what can be achieved by soft-fork, but to reduce block intervals you will need some hard-fork.

As usual, the idea of Bitcoin being decentralised has a huge impact on this.

The first problem being a lack of consensus. Given that each node would see different transactions, it would be impossible to reach a consensus on which transactions are to be included in the "block pool". Miners should have the say in which transaction they want to include since they're the ones collecting the fees, not the users.

Coinbase transactions has to be included in the merkle root of a block. Changing the coinbase transaction would change the entire merkle root.
Users shouldn't trust any transactions until they are put into the blockchain. Even if you can use a huge amount of hashrate to back your own transaction, the final say lies within whatever is put into the blockchain.

There is really a lot of considerations put into this. If you want faster confirmation, the best method is to reduce the block intervals.

There is no problem, since coinbase can contain more than one output. Also, in this way it is possible to create decentralized pools, when such "half-baked blocks" will be treated as shares.

Something has to be changed anyway, because the block is not ready. Changing coinbase will not make any calculations harder or easier. Also, if many people are working on the same tree and only coinbase keep changing, it is quite high chance that someone will find a block containing these transactions.

It is not really useful for miners, but it is for users. They usually cannot mine blocks, so having some low hash can be enough to convince someone that some transaction is mined by someone.

Also, using this method can be useful in case when a lot of miners will left the network. Then, blocks will appear very rarely before difficulty adjustment and instead of just accepting 0-conf transactions not backed by anything, it may be possible to accept only transactions backed by some computing power.

A problem with this approach is that the block will contain a coinbase tx which includes a recipient address. Everybody wants to be the recipient of the block reward which will entail changing the recipient address, which will change the hash.

Also, as achow101 pointed out, you can not "aim at" a particular hash. The amount of currently done work on a block could give miners a clue as to what other miners are mining, but I don't thing they would find this information particularly useful.

The PoW is stateless and progress-less. Finding a hash with some number of leading zeroes does not make you any closer to finding a valid hash. Having any sorting based on that is not useful.

Being "backed by some computing power" is not useful if it has no effect on whether a transaction will be confirmed. And since mining is stateless, that computing power is not making it more or less likely that a particular transaction will be confirmed

Now each node has its own mempool, which contain all transactions accepted by given node. But maybe instead we can go further and replace it with "blockpool"? I mean: instead of only collecting transactions, each node will prepare blocks containing these transactions. Then, it will be possible to share not-yet-mined-blocks between nodes in the network.

The main advantage is that 0-conf transactions will not be "just unconfirmed", but they will be backed by some computing power, that is not yet enough to make it into a block, but can still give some feedback about possible confirmation time for each transaction. Now all of this computing power is wasted, but instead nodes and miners could give an information that for example they found a hash having first 64 bits set to zeroes. There is more and more unconfirmed transactions waiting in mempools, so maybe it is a good idea to sort it by the proof of work done on them.

To make this an unique set of transactions, for each transaction there will be a "proof-of-currently-done-work" in a form of hashes in the merkle tree of the block with the lowest hash that contain this transaction. In this way, any node can determine in a SPV-based way if the total work done on any transaction is the highest one and reject duplicated transactions. Also, if only a part of the tree changes, it will not be necessary to send the whole block over and over again.

Because getting the same block hashes is almost impossible on SHA-256, always some block will undoubtedly win this competition, just by having the lowest block hash. If some block is full, the next block will be created in blockpool with previous block hash set at the latest block, forming a list of unconfirmed blocks, having hashes from the lowest to the highest. Unconfirmed blocks should not be chained, because it is possible that currently losing block with the highest hash will suddenly be mined first, so we should not set the previous block hash to some value of not-yet-mined-block.