Quote from: nc50lc on April 17, 2024, 05:17:35 AM

Quote from: vjudeu on April 16, 2024, 06:04:45 PM

Quote

but that also comes with the issue of trusting the miner whether they wouldn't take the puzzle reward themselves or not

Well, it is also possible to share some data, which is needed to mine a block (like transaction ID, transaction Segwit ID, etc.), without sharing transaction data. Then, it would be sufficient to mine a block, but the pool wouldn't know, if it is valid or not.

Fair enough, the miner can start to "mine" the block header without the actual transaction.

In the event that they produced a hash lower than the target, they wouldn't be able to broadcast the block without the actual raw transaction. (or would they? Please CMIIAW)
And in mining, every millisecond counts so if the transmission of raw transaction isn't coordinated well and quick, other pools/solo miners could broadcast a block in their place.
This would need a specialized software in both miner's and user's side to be automated for low latency.

Quote from: vjudeu on April 16, 2024, 06:04:45 PM

And also, if you want to prove, that you know the public key, but you don't want to reveal it, then you can share for example SHA-256 of that key, and then everyone can validate, that RIPEMD-160 of it is equal to the address, used in the puzzle.

Good idea, but I'd like to know how can this be applied exactly to existing P2PKH outputs like what OP is pertaining to?
If not possible, the creator of the puzzle may have to consider spending those weak ranges into your proposed output.

Original "Puzzle" Transaction: 08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15
Supplementary Transaction: 12f34b58b04dfb0233ce889f674781c0e0c7ba95482cca469125af41a78d13b3
- Puzzle 66 address: blockstream.info/address/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
- Puzzle 67 address: blockstream.info/address/1BY8GQbnueYofwSuFAT3USAhGjPrkxDdW9

puzzless addresses has RBF transactions...