10

Do the current Bitcoin opcodes and transaction size limit allow constructing a UTXO which is only spendable if a specified amount of work has been performed?

So the spender, would provide a nonce as input to the script. Then the script would essentially perform a highly simplified version of how bitcoin's block headers are verified (the nonce is combined with some other data, hashed, and the hash is compared with a "target.").

Without OP_CAT and with arithmetic limited to 4 byte inputs, do I understand correctly that the above would be impossible? Or is there some workaround?

Ugam Kamat
  • 7,398
  • 2
  • 15
  • 40
philbw4
  • 424
  • 2
  • 8
  • 4
    You could add an op return to your tx with the first 200 bits of the private key. A spender would have to grind the last 56 bits until they find the right private key to sign with. Combine with multisig or Schnorr tweak to target a single recipient! – pinhead Oct 18 '19 at 03:50
  • @pinhead thanks! That's a clever way to do it. Indeed it would require proof of work to uncover the key. However, in this case everyone would be guaranteed to ultimately end up with essentially the same "nonce" (which is just the full private key), so wouldn't a mainchain miner just be able to steal the reward?

    Or, put another way, can you clarify what you mean about using, for example, multisig so that it targets a single recipient? Namely whoever put in the work but also in a manner that the original UTXO didn't need to know who the set of potential workers is. Is this making sense?

     – philbw4 Oct 18 '19 at 04:03
  • 2
    Hm that's hard. Miners can steal anything that's not signed. My thought was you could send to a 2of2 multisig where one key is a known recipient and the other key must be brute forced (by that recipient) A miner wouldn't be able to steal that. – pinhead Oct 18 '19 at 04:07
  • Again, thank you very much for your answer. This is extremely helpful. So the challenge have with that construction (the 2of2 method you proposed) is that I would need to know the key of the recipient ahead of time which is not what I want. Is there a way we can sort of chain a series of these types of transactions together to accomplish that? – philbw4 Oct 18 '19 at 04:16
  • What is the application of this? I’m curious to know what you’re trying to accomplish – chytrik Oct 18 '19 at 22:12
  • hi @chytrik, thanks for your interest. There are a couple applications I can think of. The primary one I'm most interested in though is eluded to in my other question here https://bitcoin.stackexchange.com/questions/91069/are-there-any-slow-sidechains-what-are-the-tradeoffs Basically I want to determine if there is any way whatsoever that bitcoin as-is could verify even a single block header of a purely proof-of-work (as opposed to federated) sidechain. The question here then is just a reduced form of that question. – philbw4 Oct 18 '19 at 22:24

1 Answers1

1

The answer depends on what you are trying to accomplish with this construction. I have three guesses in this regard:

  • a set of determined recipients can spend if they perform the PoW: you can have a transaction that can be spent if someone provides: a value whose hash is less than a specified amount (that determines difficulty) AND a signature that describes the set of allowed entities (potentially any multisig).
  • anybody that performs the proof of work can spend (AND you can spend without PoW): this is trickier since a simple hash based PoW would not work, a miner can just change the destination address of the spending transaction to one under his control. You need to prove that you know a secret (the result of the PoW) without actually including it in the tx so that miners are not able to take the money without repeating the PoW: this is what digital signatures accomplish. As suggested in the comments you can contsruct a utxo that can be spent by signing with a certain private key known by you alone and that contains part of it under an op_return. So one has to try any private key in the set of the allowed ones until he can produce a valid signature. This does not leak the private key itself so the miner cannot sign the same tx with a different destination address.
  • anybody that performs the proof of work can spend (AND you can NOT spend without PoW): I thought about this a while and I can't find an easy construction for this, it might be hard even with stronger scripting capabilities than bitcoin's. My best guess is that you have a provably random public key (for instance using a VDF on the nonce of the last block) and everybody has to brute-force the private key to spend. I see two major issues: miners can have some advantage in selecting nonces to influence the randomness of the PK and it's hard to tune the difficulty, you need a custom signature scheme that has the security level you want and that's not trivial with bitcoin script.

This is NOT a complete list, it's just the first ideas that came to my mind. Especially the second case, which looks the most likely to me, can be constructed in several different ways: for instance you could also publish the hash of the private key in an op_return (so the private key doesn't have to be included in the transaction) and you would turn it into a hash-based PoW since hashing is a lot faster than signing.

St3p
  • 31
  • 2
  • thanks for your answer. For the first bullet point, you mention comparing if the hash is less than a certain value. However, the hash is a 256 bit number, yet the numerical comparison operations in bitcoin script are limited to 32 bits. So I am not sure that this option would work at all?

    Of your scenarios though, the third one is the one I am trying to do -- anybody performs the work AND I cannot spend without also performing work. So far I am stumped on it.

     – philbw4 Sep 19 '20 at 02:48
  • I had imagined the desirable case is the third one. Not an easy task at all.

    You get me unprepared as for the numerical comparison matter, but at the cost of writing an insanely convoluted script I guess you can workaround it. If you have enough of 32 security bits then you can just take the last 4 bytes of the hash and compare them to the target. Otherwise you can take the last two 4 bytes blocks and combine two checks.

     – St3p Sep 22 '20 at 18:01
  • This is an interesting approach (though, as you suggested, it sounds like the script may end up quite bloated/convoluted). However, I think the "take the last 4 bytes of the hash" is where it may break down. Pushing 32 bytes (the hash) on to the stack seems possible. However, pulling 4 bytes off at a time and comparing them seems not possible, unless I am mistaken? Again, thank you for your thoughts on it. – philbw4 Sep 23 '20 at 22:04
  • I'm definitely no bitcoin script expert, but from a quick look it actually seems not possible, I don't think I can help further. It might become easier with something like scriptless script, but I really know too little about it. – St3p Oct 02 '20 at 14:59
  • Yes, with the coming (eventual) upgrades, something like this may be possible it seems. Until then, I am not sure either. Thank you for your thoughts so far on it! – philbw4 Oct 06 '20 at 02:52
  • To build the proof of work in a way that is also secure to miners' attacks you can still do what was suggested in the first comment. You can add to a normal tx an output containing part of the private key. This way one has to bruteforce the remaining bits to be able to produce a valid signature and miners have no significant advantage. In this case the creator knows the private key for sure, no way around it. Why are you not considering this direction? – St3p Oct 07 '20 at 08:26
  • Sorry for my delay. The primary reason why that direction is less interesting to me is precisely because the creator would know the private key. So it would not be a 'fair competition' among those who are trying to complete the work. – philbw4 Oct 19 '20 at 23:38
  • If you put partial private keys under OP_RETURNs what prevents me from "trolling" everyone by submitting similar transactions with wrong partial private keys? "Hahaha, you guys did 2^56 work for nothing! Suckers!" – user253751 Aug 20 '21 at 08:45
  • Maybe there could be a pay to script hash in which the requirement to solve the difficulty required mining on the most recently produced block. You could have the competing miners hash the most recent block and need to come up with a nonce that creates the level of share difficulty needed to spend reward. That way there could only be one winner after each new block, difficulty can be adjusted per block, and no one could "fake" a proof of work that met these requirements. If someone provides a copy of the last block with an extra nonce attached that meets the competition difficulty return true. – Poseidon Jan 20 '23 at 23:05
  • To elaborate, using a whole btc block is not realistic (unless you hash a compressed version?), but a merkle proof of data from the block should be enough( which is basically a compressed checksum of sorts). Although the size of this data may add to the difficulty of solving a share which needs to be considered. – Poseidon Jan 20 '23 at 23:07
  • @Poseidon I don't think that mechanism can be used to lock funds though, as it would require something like "hash the previous block header with this nonce and count leading zeros" to be encoded into the bitcoin script locking funds. Actually, the hash of blocks is already computed on the blockheader, which has some metadata plus the merkle root of transactions. This way we can build compact (O(log n)) proofs of inclusion of a transaction in a block without sharing the whole block. – St3p Feb 09 '23 at 16:15
  • I'm not fully following why proof of work cannot be used to lock funds. Lets use the bitcoin proof of work as an example. when someone solves a proof the network receives their block and compares it against blocks with proofs from other miners. the one with the largest chain wins meaning the one with more transactions and more work. This same principle can be applied to the spending of script locked coins, you create a challenge so that the proof meets the target set with bits and that it also includes a signature, add the pubkey of the signer to the proof and you have an unbreakable claim. – Poseidon Feb 09 '23 at 18:34
  • To manage competition you need rules so that the provers can maybe add more data to their message that they are hashing, or have the script logic pick the most golden nonce so the one with the highest amount of proceeding zeroes. because of the logic in proof of work as long as you get users to commit to signing new messages each block no one could reuse or use someone elses work. (unless people form pools at which point they are forfeiting their work) – Poseidon Feb 09 '23 at 18:36
  • To be specific the directions of hash the previous block header with this nonce and count leading zeros are not what happens in proof of work. only the message which in this instance is the block header would be shared amongst the parties participating in the challenge, the nonces are selected by each individual otherwise it would be completely insecure. My idea of using previous block header was just to get a chain of data relating to the underlying chain that would be persistent, deterministic, consensus based, and relatively compact. This chain can be used to set the message automatically – Poseidon Feb 09 '23 at 18:38
  • Effectively each block there is a competition to submit the transaction that claims the funds with the highest amount of difficulty and claims their work via their own signature. Its pretty much just how bitcoin proof of work works, consensus and competition. – Poseidon Feb 09 '23 at 18:44
  • Exactly. Bitcoin full nodes contain some consensus logic so that each block showing enough proof of work can contain an inputless (coinbase) transaction giving block reward to some addresses. I don't see any other place where proof of work can lock funds since all non-coinbase funds can only be locked by fulfilling a bitcoin script and I see no way to implement a proof-of-work verifier in bitcoin script. – St3p Mar 13 '23 at 15:41