Quote from: SapphireSpire on November 04, 2024, 06:00:00 PM

Miners publish tickets for the right to create the next block, and all tickets go into a ticket pool. A ticket contains the miner's pubkey and a payment address and hash derived from it. They constantly work until they have the most difficult hash. Then the miner creates a new block, includes their pubkey and hash in the header, and signs the header. The signature validates the pubkey, which validates the hash, which contains the proof of work. Since the work is done in advance, it doesn't delay transaction confirmation.

This undermines part of the economic security theory of Bitcoin. When you mine a block you're expending costly energy in the hopes of creating a block that is part of the persistent history, if its content is invalid you have wasted your money, and you can't create alternatives-- the work is good for just one block.

Under your alternative scheme, after mining some blocks someone who has obtained some ticket private keys can construct an alternative chain which replaces the block they actually produced with an alternative one.. so now the miner can mine malicious blocks that won't end up part of the longest chain without wasting their energy since they can also produce a good block that will. I anticipate a response where you suggest some kind of rule against multiple signatures, but the malicious signature could come years later or only be given to specific isolated targets.

It's also not clear to me why you think what you propose is faster. The work in proof of work isn't cumulative, it's a lottery not a race. So miners can and do update the transaction set as they continue attempting to find a block, and could do so as fast as they want so there isn't any latency particular to the process.

Maybe you mean that it would allow the block times to become more predictable if you imagine that use of 'tickets' is in a completely arbitrary order, essentially completely decoupling the process. In that case, I believe there are other weird system breaking effects, but it's harder to say without a more precise description of the ticket management. But I guess the first question there would be why wouldn't every ticket be used as soon it was available, resulting in tying the timing of block production directly to ticket creation?