Significant Bitcoin Improvement Proposal (BIP) with a $100 Reward (7 Days)

Check out this link for the details on a fresh Bitcoin Improvement Proposal (BIP) that has the potential to get the green light from the Bitcoin Core devs. The aim is to present a clear and compelling case that could lead to the acceptance of this proposal. If you put in the effort and your input really helps make a positive impact, there’s a $100 bounty up for grabs. Also, I might toss in some extra tips for the best contributors. This isn’t just about who wins; it’s about working together and sharing ideas in a meaningful way. Be sure to engage in discussions here, and also connect with the Bitcoin Core developers in the "Development & Technical Discussion" section of this forum. Let’s keep it technical and respect everyone’s time.

Impossible, because you propose a hard-fork, where things like that are possible in a soft-fork or no-fork way. Also, there are some existing (but centralized) systems, to make it decentralized, the only missing thing is for example moving them into Lightning Network. Then, the lottery creator could collect all coins locked in 2-of-2 multisig addresses, where any participant can withdraw coins by closing the channel, so there would be no need to trust the lottery creator. Then, all funds could be paid to the winner inside Lightning Network and that winner would have the option to collect it on-chain by closing the channel or could simply spend that coins by sending them to other LN participants. No burning needed, no way to stop that system without shutting down LN, any amounts allowed, everything denominated in millisatoshis, fees covered by channel creators (or no fees if both nodes agree and if channels were created before).

Thanks garlonicon, for pointing out that no one would agree with a fork for something that can be done without it. One thing I think a lot is if it wouldn't be wise to have a hardwired burning address that was so supervised that even in a dystopian quantum computing breaking of bitcoin public-key cryptography, would make it utterly unlikely that an attacker would be able to spend coins of such a hardwired burning address. By hardwired burning address, I mean an address that, by definition, the bitcoin protocol would never allow having its funds being spent, unless there was a further update to the protocol. The first thing I propose in the mentioned post is that we unite to have such a hardwired, well-supervised, burning address.

Your idea is weird and it doesn't go with the Bitcoin principles (a payment system not a gambling platform) so they will never be implemented. I say weird because I don't see the point of burning coins and giving them to miners then giving the winner their reward. It is like you are intentionally complicating a simple thing. A lottery is when people put their money in a pot each receiving some number of "tickets" based on how much they put in and a random person is selected in the end to receive the whole pot. A simple side-chain could be created that does this. It could possibly be done with 3 new OP codes. Since this is a side-chain it has nothing to do with bitcoin protocol and there is no need for a BIP. - One to get and use block headers of a couple of blocks (like the next 3 after the block containing the received tx) then use the existing hash OP codes to hash them. - Another OP code to count the number of inputs (max participant) and convert the previous final hash to an integer between 0 and that number - And finally an OP code that allows the input at index I (computed in previous step) to spend the balance of that output (ie. receive its reward). This ^ way there is no burning coins, no miner involved, no change (hard fork) to the protocol, and most importantly the bitcoin blockchain is not spammed since it [almost] all happens on the side chain.

We have OP_HASH256 just for that. This is not generic enough, it could be better defined as "3 OP_GETBLOCKS", where for example 3 is standard and anything else is non-standard. But I think it should be something like 100. Also, if that blocks would come from the sidechain, then there is a risk that chain will have much less computing power, so sidechain miners could grab their coins just by mining three blocks that will grant them all rewards. To build a sidechain, you need support from miners, because they protect sending coins to and from the sidechain. If you don't have their support, then building in on top of LN is easier. Edit: the more I think about OP_GetBlocks3, the more strange it seems to be. All block headers contain previous block hash, so what is the point in grabbing last three block headers? If everything is based just on some hash of block headers, then the latest block hash is more than enough, so "123456 OP_GETBLOCKHASH" could just return the hash of block 123456 (and be automatically timelocked if that block number is from the future).

That was a mistake, I didn't mean to hash the top stack element twice. It should have been something like this with a new OP code: That's a better idea and the number (eg. 3) could be part of the locking script instead to make it "already agreed upon". OP_GETBLOCKS could also be defined in a way that we don't need what I explained above. It just takes n blocks computes hash of the block-header-hash and combines them (eg. SHA256(headerHash1) XOR SHA256(headerHash2)) That's the beauty of a side-chain, you would be creating an altcoin that has its own network, blockchain and consensus rules. It can even have its own miners mining standalone new blocks with a different algorithm. On the other hand wanting to do it on LN you will face the same problem needing new OP codes that don't exist in LN.

I guess all headers should be hashed in the same way, so OP_HASH256 should be everywhere, if you mean block hashes with leading zeros (or rather trailing, because of endianness). In case of disagreement, things are similar in LN and in sidechains. In LN you have punishment transactions, in sidechains you have miners enforcing the "good" chain (and you need support from on-chain miners, because in other case you need additional protection from "validators" and their signatures). Everything is enforced outside of the chain and then miners (in sidechains) or users (in LN) enforce things on-chain by broadcasting final transactions.

Regardless of my opinion on the subject, the bounty is uncollectable because any such proposal would never be accepted. Note that it was pointed out several years ago in your previous thread that a lottery can already be implemented:

Maybe a fork of litecoin for this would make perfect sense.