A faster alternative for blockchain consensus

[SapphireSpire]

Work is applied to a block hash so that it's highly unlikely to produce a valid hash if it's modified. But this forces work to be done after the block is created, resulting in painfully long delays. The goal is to do the work before a block is created, without leaving the block subject to modification.

Miners create tickets for the opportunity to create a block. A ticket contains the miner's pubkey, a pubkey hash, a nonce, and a payment address. Tickets are added to a ticket pool as they are published. Miners work to improve the difficulty of their pubkey hashes until they meet the minimum difficulty. Every block must have a unique pubkey, so pubkeys can't be reused.

Every block header contains a top ten list of tickets containing the most difficult hashes, and the following block may only be validated by one of these tickets. All of the owners of these tickets are encouraged to create a block for the next position, in case the owners of all the better tickets fail to do so. The one with the best hash counts.

A block's list validates the pubkey of the following block, and everything in the header is included in the signature, which only the miner can produce. Would this not secure the block as well as a block hash with POW?

[garlonicon]

Something similar is already available on testnet4. Try to move those CPU-mineable coins: https://mempool.space/testnet4/address/tb1qk3endeq6x0xj4pjt4zwag8wf3a629rzqr8jxd7jnmlac902wa5ysqxm9wt

They have to scan over a range of private keys until they find one that produces a public key that contains at least one leading zero.

It is easier to just measure the size of the signature with OP_SIZE, and making sure, that it contains less than N bytes. And half of the secp256k1 generator can be nicely used, to reveal the private key at the same time. Also, in the future, public key grinding would be possible, but only when people will get public keys, which would be below 168 bits (which is quite hard thing to get, and just computing small SHA-256 values is far easier, than grinding x-values in public keys).

and create a coinbase output with each mediator's payment address

It is easier to just make a regular transaction, and instead of referencing "no previous coin" (as you can do in the coinbase transaction), just reference the challenge. For example:

Code:

95d89a3e03361e9b1f8412928656dac03c92979469dbfc0bcabdeaedcdc45fc8:1   0.00222599 tBTC
b92eb2d8abf81a25197bacde9845eea3d711bd6edf25e1e8975d731271dd83eb:0   0.01018062 tBTC

Instead of using any kind of "block headers", you can just use the input script, to put a regular signature, taking less than N bytes, and then, you can decide with sighashes, which inputs and outputs are signed. And any commitment can be just hidden inside the key, which will be publicly revealed, when the signature will be broadcasted publicly (but then, knowing the private key will give no advantage, because to change anything, the attacker would need to re-mine it, so it wouldn't be worth it, if locked amounts and signature sizes will be aligned properly).

and are sorted by difficulty in ascending order

Coins can fly independently in that kind of system, because if you have a "blockless" model, then you don't have to enforce any particular order. You have just address tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d with difficulty 1, and address tb1qk3endeq6x0xj4pjt4zwag8wf3a629rzqr8jxd7jnmlac902wa5ysqxm9wt with difficulty 256, and they can be handled in a completely separate way. And if someone wants some kind of "Merged Mining", then it is possible to join coins in a single transaction, put some challenge on a joined output, and then mine it by both groups of miners, since then. So, joining and splitting is as elastic, as it is in regular transactions, the main difference is just expressed in a fact, that signatures contain implicit Proof of Work, expressed by their size.

The owner must sign each input independent of the others

As long as you consider existing sighashes, no Proof of Work can be reused, because the current input is always unique, and is always used, to form a hashed message, to be signed. So, as long, as we don't have tricks like SIGHASH_ANYPREVOUT, the current system can guarantee, that this property is preserved (and future sighashes like that, would likely appear inside Taproot, where there are no DER signatures, so you can safely accept any existing sighashes in pre-Taproot outputs).

To minimize network traffic, inputs are signed in the order of their index values.

You need just a single signature, to make things tick, as shown in f1572558fed009ab9d247da85be221e3d8f98c80b66ce9c2ada3a25cba0d797a (but of course, you can just make the whole Script more complex than "OP_SIZE <difficulty> OP_LESSTHAN OP_VERIFY <networkState> OP_CHECKSIG", but there is no reason to do so; any kind of needed complexity, you can hide just inside your public key, committed to any network state you want).

The effort required to upgrade a pubkey increases exponentially with it's difficulty, so the coinbase reward should scale exponentially as the zero count increases linearly.

The coinbase reward should come from already existing coins. You have some BTCs, and you want to get some ALTs? Just send them to the proper address, and commit to the next "network state". Then, miners will confirm it, and take your BTCs as a reward, by confirming your ALTs, and publishing needed Proof of Work. And also, in the same way, you can peg coins out, by moving your ALTs inside such network, and commiting to the next network state (then, you can create a partially signed transaction, with negative fee, equal to your pegged-out-amount, and anyone can add more signed-and-mined inputs, to claim it).

After an output is spent, all unused pubkeys can be presented in new tickets for other unspent outputs, so the work isn't wasted.

If any miner would use half of the generator, then everyone will know the private key, behind a new network state. Also, if future miners would start generating public keys below 168 bits, then re-using them would lead to leaking those keys, and sharing a key for faster computation, with everyone else. So, grinding SHA-256 will be the easiest way, for quite long time, before flying low-x-value public keys will appear.

If they sign more than one input for the same output, their ticket is destroyed because it can never happen by accident.

First of all, nonce reuse in a signature, leaks all keys, so then, everyone else can grind it, and move those coins anywhere else. Which gives everyone an incentive, to keep "network state public key" only inside a given sidechain, and not share it outside, until someone will find a matching grinded signature.

If a mediator fails to sign their input within a reasonable time, a few seconds perhaps, the owner can simply replace the ticket for that input.

It works only if the transaction is unconfirmed on the main layer. Which means, that if BTC miner will confirm it, then it will be confirmed.

If an attacker uses different tickets in each double-spend transaction, the pubkey with the lowest difficulty is discarded.

Full-RBF means, that the replacement with the highest fees will win, so any incentives should be expressed in that way. But Proof of Work inside signatures should limit the spamming ability, because making a different version will require re-grinding the signature (by changing SHA-256 value of the hashed to-be-signed-transaction, long before grinding low-x-value-pubkeys will be more profitable than that).

The question is whether a signature is as secure as a block hash.

If you check s-value of the grinded signature, then you can notice, that it can be used just as a block hash for your network.

A signature takes milliseconds, and only delays a single transaction, while a block hash can take hours, and delays everything.

It doesn't matter that much, as long as grinding z-value, by picking a different transaction data, leads to much faster signature grinding, than changing x-value of your public key. And of course, the usage of secp256k1 means, that half of the generator has only 166 bits, so it will take some time, to get enough mining power, to get just a single public key, below that value.

Edit: Nice to read, how to put all of that into practice: https://github.com/adambor/btc-pow-locked-outputs/

I didn't expect discovering "Pay to Proof of Work addresses" will lead to a new mailing list topic: https://groups.google.com/g/bitcoindev/c/r0DaTwBek5Q

[SapphireSpire]

I have greatly altered the original idea.

[gmaxwell]

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?

[SapphireSpire]

I have finally addressed the glaringly obvious oversight of my previous scheme.

[ranochigo]

I'm quite lost as to the whole point of the scheme. Blockchain consensus doesn't need to be faster and there isn't any issue with it right now.

Work is applied to a block hash so that it's highly unlikely to produce a valid hash if it's modified. But this forces work to be done after the block is created, resulting in painfully long delays. The goal is to do the work before a block is created, without leaving the block subject to modification.

The "delay" that you're saying presumably refers to the block interval. That is by design and natural variance will alter the interval slightly and on average blocks are still generated with a 10 minute interval. If you want faster blocks, modify the difficulty mechanism to produce a shorter block interval.

A block's list validates the pubkey of the following block, and everything in the header is included in the signature, which only the miner can produce. Would this not secure the block as well as a block hash with POW?

The whole idea of POW is that miners are hashing everything in the block and are in essence exchanging the work done to mine a specific set of transactions. This ensures that the whole game theoric approach still functions and including transactions after the block hash is already found will violate this logic. This makes block reorganization trivial from an adversary perspective, having the keys also means that you can replace the transactions with zero difficulty as and when you'd like. Building an alternative chain requires no work since you're not hashing the transactions, but finding the hash of the public key.