An idea about reducing transaction confirmation time

[shine0108]

I think if I want to buy a cup of coffee with Monero, the waiting time of 120s is too long.

Is it possible to reduce the confirmation time of transactions by separating the acquisition of bookkeeping rights and the recording transactions process?

Here is my idea: Miners need obtain the bookkeeping right through POW, and there is a separate bookkeeping right blockchain. That is, it is confirmed in advance which miners will record transactions in the next few minutes, and these miners take turns to record transactions, then each block's confirm time can be reduced to several seconds.

This is just a very rough idea, and I want to discuss with everyone whether this idea can work?

[UkoeHB]

There is already the concept of 0-confirmation, where you just check if a tx is in the 'waiting to be mined' tx pool. You mention 120 seconds to wait, but that is just the wait until 1-confirmation. Using a 'bookkeeping right' blockchain would not really change this dynamic, except maybe reduce the time until 1-confirmation. Generally, though, recipients of transactions have three 'tolerance zones'. Low-risk transaction can be accepted at 0-conf (e.g. in-person tx), medium-risk transactions can be accepted at around 10-conf (e.g. online transactions), and high-risk is around 60-conf (2hrs, for high-value transactions).

[shine0108]

Maybe I did not express my thoughts clearly. For small payments, several confirmations should be safe enough, but payee may not accept 0-confirmation. The confirmation time of each transaction needs at least 120s, mainly because the POW process is very time-consuming, that is to find out which miner should record transactions. But we can use the 'bookkeeping right' blockchain to know in advance which miners have the right to record transactions in the next hours. Reduce the block confirmation time of 'transaction blockchain' to several seconds, and these blocks will be generated by miners confirmed in the 'bookkeeping right' blockchain. For example, 'bookkeeping right' confirms that, in the next hour the block of the 'transaction blockchain' will be produced by 30 miners, and these 30 miners will take turns to record transactions and produce a block every 3 seconds. If one of the miners is dishonest , the block he produced will not be confirmed by the next miner, and the miner will be skipped. In order to prevent the miners from being dishonest, mortgage mining can be used. In this way, we can reduce the time of 1-confirmation to 3 seconds. 2~3 confirmations should be safe enough for low-risk transactions. If you are worried about the risks that this may bring, you can record the merkle tree root of the 'transaction blockchain' block in the 'bookkeeping right' blockchain every hour. By this way, we will not increase the risk of large transactions.

[UkoeHB]

If one of the miners is dishonest , the block he produced will not be confirmed by the next miner, and the miner will be skipped.

Doesn't this imply any of the miners could easily rewrite chain history? Since they are given the right to arbitrate if previous miners are dishonest, they can just decide arbitrarily if their blocks are legitimate or not.

[shine0108]

If one of the miners is dishonest , the block he produced will not be confirmed by the next miner, and the miner will be skipped.

Doesn't this imply any of the miners could easily rewrite chain history? Since they are given the right to arbitrate if previous miners are dishonest, they can just decide arbitrarily if their blocks are legitimate or not.

Of course not, miners need to provide evidence to determine that the previous miner is dishonest, and this evidence needs to be accepted by subsequent miners. The evidence may be that the previous miner provided two blocks with different content, and these two blocks having the same blockid and both have the miner's legal signature. Or, the illegal transactions recorded in the block will also be used as evidence to determine the miner's dishonesty. In BTC, if a block is illegal, it will be directly abandoned. In this scheme, miners need to sign the block they produced. Once the block is found to be illegal, not only will it be abandoned, but the collateral will also be fined.

[shine0108]

If one of the miners is dishonest , the block he produced will not be confirmed by the next miner, and the miner will be skipped.

Doesn't this imply any of the miners could easily rewrite chain history? Since they are given the right to arbitrate if previous miners are dishonest, they can just decide arbitrarily if their blocks are legitimate or not.

Of course not, miners need to provide evidence to determine that the previous miner is dishonest, and this evidence needs to be accepted by subsequent miners. The evidence may be that the previous miner provided two blocks with different content, and these two blocks having the same blockid and both have the miner's legal signature. Or, the illegal transactions recorded in the block will also be used as evidence to determine the miner's dishonesty. In BTC, if a block is illegal, it will be directly abandoned. In this scheme, miners need to sign the block they produced. Once the block is found to be illegal, not only will it be abandoned, but the collateral will also be fined.

More precisely, miners have no right to judge whether a block is legal, but can only discover and publish the dishonest behavior of upstream miners. And the rules for determining whether a block is legal are part of the blockchain protocol.

[b-g-goodell]

Isn't this just a version 2-hop proof-of-work/proof-of-stake hybrid? The work block decides the validators, and then a sequence of one or more stake blocks can go by where usual pos validators do the signing. It's possible the stake blocks have a fast block time while the pow blocks have a slower one.

However, I don't think it's a good idea to use this approach to boost confirmation times. Why? Because security for 2-hop style chains has been analyzed in the situation where the number of work blocks decides confirmation time. Thus total conf time isn't improved.

For those who are curious, why should a coin want to use 2-hop? To split mining incentives up to partly go toward stake validation, with the intention of bootstrapping an eventual stake chain to replace proof of work.

I am unsure about how the community feels about that sort of longer term transition and, besides, it wasn't the problem-solution pair OP was trying to get at (which had to do with confirmation times).

On Mon, Oct 12, 2020, 6:03 AM shine0108 notifications@github.com wrote:

If one of the miners is dishonest , the block he produced will not be confirmed by the next miner, and the miner will be skipped.

Doesn't this imply any of the miners could easily rewrite chain history? Since they are given the right to arbitrate if previous miners are dishonest, they can just decide arbitrarily if their blocks are legitimate or not.

Of course not, miners need to provide evidence to determine that the previous miner is dishonest, and this evidence needs to be accepted by subsequent miners. The evidence may be that the previous miner provided two blocks with different content, and these two blocks having the same blockid and both have the miner's legal signature. Or, the illegal transactions recorded in the block will also be used as evidence to determine the miner's dishonesty. In BTC, if a block is illegal, it will be directly abandoned. In this scheme, miners need to sign the block they produced. Once the block is found to be illegal, not only will it be abandoned, but the collateral will also be fined.

More precisely, miners have no right to judge whether a block is legal, but can only discover and publish the dishonest behavior of upstream miners. And the rules for determining whether a block is legal are part of the blockchain protocol.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/monero-project/research-lab/issues/76#issuecomment-707077904, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD2ZD7WVGVVJ2GKGTFMOAC3SKLV7ZANCNFSM4SJSSTGQ .

[shine0108]

Isn't this just a version 2-hop proof-of-work/proof-of-stake hybrid? The work block decides the validators, and then a sequence of one or more stake blocks can go by where usual pos validators do the signing. It's possible the stake blocks have a fast block time while the pow blocks have a slower one. However, I don't think it's a good idea to use this approach to boost confirmation times. Why? Because security for 2-hop style chains has been analyzed in the situation where the number of work blocks decides confirmation time. Thus total conf time isn't improved. For those who are curious, why should a coin want to use 2-hop? To split mining incentives up to partly go toward stake validation, with the intention of bootstrapping an eventual stake chain to replace proof of work. I am unsure about how the community feels about that sort of longer term transition and, besides, it wasn't the problem-solution pair OP was trying to get at (which had to do with confirmation times). … On Mon, Oct 12, 2020, 6:03 AM shine0108 @.***> wrote: If one of the miners is dishonest , the block he produced will not be confirmed by the next miner, and the miner will be skipped. Doesn't this imply any of the miners could easily rewrite chain history? Since they are given the right to arbitrate if previous miners are dishonest, they can just decide arbitrarily if their blocks are legitimate or not. Of course not, miners need to provide evidence to determine that the previous miner is dishonest, and this evidence needs to be accepted by subsequent miners. The evidence may be that the previous miner provided two blocks with different content, and these two blocks having the same blockid and both have the miner's legal signature. Or, the illegal transactions recorded in the block will also be used as evidence to determine the miner's dishonesty. In BTC, if a block is illegal, it will be directly abandoned. In this scheme, miners need to sign the block they produced. Once the block is found to be illegal, not only will it be abandoned, but the collateral will also be fined. More precisely, miners have no right to judge whether a block is legal, but can only discover and publish the dishonest behavior of upstream miners. And the rules for determining whether a block is legal are part of the blockchain protocol. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD2ZD7WVGVVJ2GKGTFMOAC3SKLV7ZANCNFSM4SJSSTGQ .

There are indeed similarities with POS, and it does cause complexity, and it does not look as perfect as a pure POW solution. However, if digital currency will replace fiat currency in the future and become a universal currency. The current high latency cannot meet the demand. Because of the high latency, digital currency can only be used as a base currency, or as an international settlement tool, and large-value transactions, such as scenarios that are not sensitive to latency. For small high-frequency transactions, you will have to rely on bank accounts or centralized payment tools like paypal. If we can't find a better solution, maybe this idea will be better than these centralized organizations.

[iamamyth]

Because of the high latency, digital currency can only be used as a base currency, or as an international settlement tool, and large-value transactions, such as scenarios that are not sensitive to latency. For small high-frequency transactions, you will have to rely on bank accounts or centralized payment tools like paypal. If we can't find a better solution, maybe this idea will be better than these centralized organizations.

This seems to miss the forest for the trees. Small, high-frequency transactions present a problem in bandwidth, verification, and storage. The network just can't accommodate credit card style volumes right now, so eliminating one bottleneck, waiting for confirmation, fixes nothing. I will also note that if credit cards are your comparison point, a zero-conf transaction is faster than a credit card payment, and the mean transaction wait time, 60s, is slightly less than the maximum expected credit card processing time.

[shine0108]

Because of the high latency, digital currency can only be used as a base currency, or as an international settlement tool, and large-value transactions, such as scenarios that are not sensitive to latency. For small high-frequency transactions, you will have to rely on bank accounts or centralized payment tools like paypal. If we can't find a better solution, maybe this idea will be better than these centralized organizations.

This seems to miss the forest for the trees. Small, high-frequency transactions present a problem in bandwidth, verification, and storage. The network just can't accommodate credit card style volumes right now, so eliminating one bottleneck, waiting for confirmation, fixes nothing. I will also note that if credit cards are your comparison point, a zero-conf transaction is faster than a credit card payment, and the mean transaction wait time, 60s, is slightly less than the maximum expected credit card processing time.

Bandwidth, verification, and storage are indeed bottlenecks. But if you consider the difference in electricity costs and the scale advantages of large-scale mining sites, you will find that even without ASIC mining machines, centralized mining may still be inevitable. If centralized mining is inevitable, bandwidth, verification, and storage will no longer be a bottleneck for miners, but they are still bottleneck for a full node. And rollup can solve the size problem of light wallets. If you only verify the transactions you care about, even if the overall TPS is high, it will not bring a high load to the light wallet. So, bandwidth, verification, and storage are not problem for light wallet. At this time, the key to the problem is whether low-cost full nodes are necessary. Since the mining process cannot avoid centralization, if the cost of full nodes is too high, it will inevitably greatly weaken the decentralization of the blockchain. But I still think that a weakened decentralization is better than a completely centralized solution. I mean that even if there are only a few companies, mining pools can mine, and only a few super nodes can verify whether the transactions recorded by miners are legal, such a blockchain is still better than a completely centralized solution, and better than a consortium blockchain.

In addition, it is very important that even if the overall TPS cannot be improved, just reducing the delay is still valuable. 0 confirmation cannot replace 1 confirmation, even if this confirmation is based on POS.

Although this idea is more complicated and does not look perfect as a pure POW. But if you are willing to wait for the same time, it is actually not less secure than a pure POW. It just provides a lower delay, more insecure option, which is useful for small transactions.

[iamamyth]

All of your comments about mining, wallets, and full node operating costs seem irrelevant, as full nodes don't change with the scheme you've proposed. My point about bandwidth, verification, and storage is simply that it's entirely unreasonable to try to make the network support small-value, high-frequency, credit card type purchases by merely improving latency, as, even with zero latency, the network cannot accommodate that traffic (blocks couldn't be verified and relayed fast enough). Your original proposal stated its motivation as reducing transaction confirmation times, but that begs the question of what kind of transactions require low latency but cannot use 0-conf. The examples you've provided end up running afoul of basic network limits, hence my criticism. Introducing this two-tier scheme seems to support few, if any, plausible use cases, at the cost of great complexity and potential attack surface. While it would be nice if every transaction in the world could occur on the Monero network, that's simply not realistic at the moment, and improvement proposals must acknowledge gating issues which prevent their realization. In my view, it's better to focus on improving the core of the network than adding complexity which ultimately interferes with that end.