Simple Improvement Proposal

The Funding Trilemma.

1. Development occurs with no market input beforehand and no recognition of good improvements that are being utilized daily afterwards. Our code base is littered with rubbish that nobody uses while aggregating technical debt (e.g RBF, segwit)

2. Miners are largely misunderstood as being able to dictate development. The simple division of labour should be: coders write the rules, noders run the rules, miners judge whether the rules have been adhered to and record the results into public history that is the blockchain. This misunderstanding of rules have lead the community to time and time again involving miners in the blame game whenever they are called upon to help, and we very soon reach a fork inducing stalemate. Instead, we should be using their strength that was apparent from miner signalling days: Miner's are reliable at judging on the outcome of a certain proposal.

3. Potential donors who have the money have heard of or have had bad experiences with giving money to developers who overpromise and under deliver while lacking transparency as to what happened to the funding.

The most recent IFP (infrastructure funding proposal) has been one of many attempts to resolve the above Trilemma, following which everybody and their mom has put forward a proposal. I hereby decide to join the fray, and put forward my own. It involves my favourite past-time as a miner: writing into the coinbase.

The Coinbase Proposal

Quick primer: What is a coinbase? It's surprising how very little people know that coinbase isn't some exchange and I cringe at every time that I have to explain it. But here I go again: The coinbase transaction is the birth of bitcoin. The base of that coin. The first transaction of its infinite future. Only a miner can mine it, and as a reward, they get the block subsidy. At the same time, upon mining a block successfully, they have the option to write a message into the that specific transaction. Pools use this space to advertise that they won the block and flex their total hashrate. Solo miners largely leave it empty. Colourful miners litter the coinbase transaction with love letters and such. In the past, we have also used it as a form of miner signalling, when developers wanted unhackable proof of support for their future proposals.

With this primer in mind, the following is my 5 step plan:

Step 1: Create an equal amount of SLP tokens (nameholder: SIP) to the remaining block subsidy (roughly 3 million)

Step 2: Recognise BCH miner coinbase information that registers a Simple Improvement Proposal (regardless if whether they came from BIP, EIP, BUIP), by providing SIP name and BCH address

Step 3: Distribute SIP tokens according to future coinbases that stipulate said SIP in the same manner as miner signalling. Timing of the ability to move such tokens should be in sync with the subsidy (i.e. 144 blocks later)

Step 4: Use sideshift or similar automated service to have donors commit to buy back and burn X amount of SIP at Y price (e.g. Ken can send 100,000 USDT to buy SIP at a fixed 1:1 rate)

Step 5: When SIP denominated commitments exceed the remaining block subsidy amount, send the lowest rated batch of USDT to be distributed at the same time as the highest denominated batch (e.g. Michael sends 500,000 USDT to buy SIP at fixed 5:1 rate, which is the highest ongoing rate and the amount puts Ken's donation above the remaining 3 million SIP. The next redemption will occur by 5:1 + 1:1 totalling 6:1 USDT per SIP redeemed.)

What's supposed to happen?

Instead of a miner tax, we now have a miner credit. It's a tangible, monetizeable asset. We do still have problems of certain counterparty risks (which we can utilize the blockchain to decentralize to a degree), but already it is far more transparent and trustless consensus based than any other proposal out there. The following is what I would expect to happen:

1. Hashing equilibrium will not adjust significantly away from the DAA.

2. Altruistic miners will mine more on BCH, providing a healthier buffer against pure profit seeking volatility.

3. Miners will reach out to previous BIP/EIP/BUIP authors, and register their addresses for them out of respect (e.g. multisig BIP 11)

4. Previous authors who believe their work should also be recognised will reach out to miners, allowing Step 2 to be a vetting process.

5. Pools who are more technically proficient will start by voting for the SIP they see fit, but eventually allowing the mining owners to influence their decision making.

6. The pools or solo operators will not all signal the same SIP, but instead, separate their coinbase percentages over several proposals (e.g. 20% BIP 9, 20% BIP 11, and 60% BIP 35)

7. Development teams will start to write Simple Improvement Proposals as well, clarifying clearly timelines, budgets and deliverables, so as to compete with the SIP tokens going to existing SIPs. The downside is that they are competing against existing well recognised contributions. The upside is that they can accurately predict based on historic voting behaviour, what miners are looking for in a SIP.

8. Donors will benefit from the extra visibility of a SIP, and the positive market/miner reaction to a SIP he prefers, will give them justification to donate directly to that SIP team.

9. Onlookers will enjoy and appreciate a well written well thought out idea that will be apparent based on the merits of the proposal, allowing us to re-live the good old days of reading the whitepaper for the first time...

How about the cheaters?

Given the extra monetary value, that miners cannot directly enjoy, we will expect some attempts to cheat the system. I believe the transparency of the movement of these coins, and the ability of miners to differentiate bullshit shenanigans from the truth, will eventually erode such attempts to cheat. Regardless, I shall point out the obvious ones, and welcome anybody else to point out any other ways the system will break.

1. Coordinating with an old BIP owner to get kickback.

2. Sybil a bunch of useless SIPs with addresses to bloat the register.

3. Credit stealing between authors of the original BIP.

4. Attempts to hijack the system by presenting themselves as a good SIP with good governance, but exits high profile as a scam so as to discredit the system.

5. Attempts to create discourse by creating multiple SIPs on unclaimed improvements, where the original author or the team who made the change is unclear, such as the proposal to remove RBF (not suggesting it was unclear, but I for one will definitely use my coinbase to celebrate RBF removal)