Timeline for Can we construct a UTXO which is spendable only via proof of work?
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 13, 2023 at 15:41 | comment | added | St3p | 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. | |
| Feb 9, 2023 at 18:44 | comment | added | Poseidon | 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. | |
| Feb 9, 2023 at 18:38 | comment | added | Poseidon |
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
|
|
| Feb 9, 2023 at 18:36 | comment | added | Poseidon | 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) | |
| Feb 9, 2023 at 18:34 | comment | added | Poseidon | 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. | |
| Feb 9, 2023 at 16:15 | comment | added | St3p | @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. | |
| Jan 20, 2023 at 23:07 | comment | added | Poseidon | 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. | |
| Jan 20, 2023 at 23:05 | comment | added | Poseidon | 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. | |
| Oct 19, 2020 at 23:38 | comment | added | philbw4 | 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. | |
| Oct 7, 2020 at 8:26 | comment | added | St3p | 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? | |
| Oct 6, 2020 at 2:52 | comment | added | philbw4 | 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! | |
| Oct 2, 2020 at 14:59 | comment | added | St3p | 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. | |
| Sep 23, 2020 at 22:04 | comment | added | philbw4 | 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. | |
| Sep 22, 2020 at 18:01 | comment | added | St3p | 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. | |
| Sep 19, 2020 at 2:48 | comment | added | philbw4 | 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. | |
| Sep 2, 2020 at 9:52 | review | Late answers | |||
| Sep 2, 2020 at 10:46 | |||||
| Sep 2, 2020 at 9:43 | review | First posts | |||
| Sep 2, 2020 at 10:57 | |||||
| Sep 2, 2020 at 9:32 | history | answered | St3p | CC BY-SA 4.0 |