Important Bitcoin Improvement Proposal (BIP) with a $100 USD bounty (7 Days)

[remotemass]

https://gist.github.com/cubicpostcode/a6e7348a1506ae5c6b981ccd622b8057

Your task is to create a document in English explaining the salient innovations discussed at:
https://bitcointalk.org/index.php?topic=790883.0

You should make it a Bitcoin Improvement Proposal (BIP) that has the likelihood of being accepted by the Bitcoin Core development community.

You will be awarded if you show you did contribute to a good outcome in a crucial, promoting collaboration and sharing of your insights at all times, discussing and highlighting important matters in a critical way and if your final proposed BIP document (saved as a pdf and available on GitHub with a permanent link for sharing it) is well written, clear and shows academic proficiency in English and in the layout of your terse and concise essay.

Good luck. I may tip the best collaborators, extra. Be open and collaborative.
This is an important endeavor in of itself, independently of who wins.
Feel free to say who do you think should be awarded the bounty.

Discuss in the comments here, extensively with other peers and with the bitcoin core developers at the "Development & Technical Discussion" of Bitcointalk discussion forum.

This is a technical discussion. Please be considerate of everyone's time.

[garlonicon]

You should make it a Bitcoin Improvement Proposal (BIP) that has the likelihood of being accepted by the Bitcoin Core development community.

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).

[remotemass]

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.

[pooya87]

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).

Code:

OP_GetBlocks3 OP_SHA256 OP_SHA256 OP_FindWinner OP_CheckWinnerSig

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.

[garlonicon]

Code:

OP_SHA256 OP_SHA256

We have OP_HASH256 just for that.

Code:

OP_GetBlocks3

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.

A simple side-chain could be created that does this.

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).

[pooya87]

We have OP_HASH256 just for that.

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:

Code:

OP_HASH256 OP_SWAP OP_SHA256 OP_ROT OP_SHA256 OP_COMBINE3

               [blk1][blk2][blk3]
OP_HASH256  -> [blk1][blk2][h3]
OP_SWAP     -> [blk1][h3][blk2]
OP_SHA256   -> [blk1][h3][h2]
OP_ROT      -> [h3][h2][blk1]
OP_SHA256   -> [h3][h2][h1]
OP_COMBINE3 -> [int]

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.

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))

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.

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.

[garlonicon]

Code:

OP_HASH256 OP_SWAP OP_SHA256 OP_ROT OP_SHA256 OP_COMBINE3

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).

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.

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.

[odolvlobo]

You should make it a Bitcoin Improvement Proposal (BIP) that has the likelihood of being accepted by the Bitcoin Core development community.

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:

Something like what is discussed here:
https://en.bitcoin.it/wiki/Contracts#Example_8:_Multi-party_decentralised_lotteries
and
http://eprint.iacr.org/2013/784

e.g.

As an instantiation of this idea we construct protocols for secure multiparty lotteries using the Bitcoin currency, without relying on a trusted authority. By “lottery” we mean a protocol in which a group of parties initially invests some money, and at the end one of them, chosen randomly, gets all the invested money (called the pot). Our protocols can work in purely peer-to-peer environment, and can be executed between players that are anonymous and do not trust each other. Our constructions come with a very strong security guarantee: no matter how the dishonest parties behave, the honest parties will never get cheated. More precisely, each honest party can be sure that, once the game starts, it will always terminate and will be fair.

[remotemass]

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