BUIPxxx: Ensure everyone switches to BU

honeybadger

New Member
Dec 14, 2016
4
3
Problem:
P1. Miners may be reluctant to support BU, because in event of a failure of Core-incompatible fork they may lose significant amounts.
P2. Even if BU hashpower attains big majority, it's possible Core manages to prevail via social means; in particular, if most exchanges stay on the core chain, eventual BU fork may fail, with miners gradually returning to mining Core.
P3. Opposing early adopters may try to economically destroy BU fork by dumping big amounts and simultaneously buying CoreBTC for the proceeds, significantly decreasing price in the short-term and potentially causing miners to switch to the Core chain.
P4. It's likely there are many node owners and economic agents who don't care either way - they won't change their nodes unless they have to.
P5. Transaction replay attacks.

In short, the system has a powerful inertia that, in my opinion, requires extraordinary solutions to beat.

Solution:
As a temporary measure, once total BU hashpower grows beyond a reasonable threshold (eg. at least 12 BU blocks in the last 18 AND >=70% over last 1008), all these issues can be mitigated by merged mining - mining blocks that are compatible with Core nodes and miners, but economically useless for them.

S1. Include only two transactions in the Core block - coinbase, and a special transaction containing the hash of a true BU block.
S2. Non-BU blocks are to be orphaned by BU miners.
S3. BU and BU-compatible nodes receive full true BU block in addition to Core's legacy block, with normal transactions.

After some longer period, say, 4320 blocks (30 days) of merged mining, start mining normal BU-blocks only, ie. without empty Core block.

S1 fixes P1, because in the event that BU fork fails (ie. there's not enough hashpower to orphan core blocks), miners lose only transaction fees + few blocks at most, significantly decreasing cost of failure. This should make miners much more likely to support BU, in turn increasing probability of success.

S2 fixes other points - with no transactions for a month, CoreCoins turn out to be completely useless, which causes everyone to switch, fast. Because non-BU blocks are orphaned, there's only one chain available, so it's not possible to selectively dump coins on the BU chain, nor is a transaction replay attack possible.

P.S. Given how definitive this solution is, I would suggest a small blocksize increase from the start - perhaps 4MB. This would allow switching users to immediately notice the improvements, likely generating big amounts of enthusiasm and renewed hope, even in current supporters of small blocks. Without immediate benefit, negative feelings, especially resentment, are likely to gain traction among them, diving the community.
 
Last edited:

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,695
@honeybadger Welcome to the forum for Bitcoin Unlimited discussion and history.

You make a lot of good points, and clearly your focus is a safe and smooth transition beyond the 1MB. This has been subject to a lot of thought and one of the lessons already learned is maintaining flexibility. We saw that with BIP101 and BIP109: having a fixed target does as much harm as good.

So, BU's emergent consensus (EC) devolves this block limit decision-making to the miners with "oversight" by the economic majority of non-mining nodes who effectively provide a ceiling for block sizes.

The 1MB is a complete hassle because it is a super-strong Schelling Point and therefore needs an unusual amount of co-ordination to overcome, a level of co-ordination which would not be required for the subsequent "free float" block size limit afterwards.

Therefore, the current thinking is to see if and when a majority of miners are signalling for EC, somewhere about 75%, and then, with the miners co-operation, a flag-date would be announced, perhaps 1 month ahead. At that date the miners will lift their EB and MG levels and a >1MB block will soon be mined. If not enough of the remaining miners and full-node count have enabled EC then this date can be deferred during the flag-date period.

Once the next release of BU is out (hopefully early January), with the final EC changes, then we will create a pure EC patch which Core can use if they wish to.

Ideally any miners on a weak-fork will be 10% or less, and the difficulty adjustment to get back to 10 minute blocks will take a year or more, as miners drift off the weak fork. It will probably stall quickly.

So, rather than create a BUIP ahead of time when so many variables are unknown, it is better to wait until an EC majority is reached and then view the landscape.

So, would you be OK to remove the BUIP042 tag, but lets leave this open for debate as there are many issues to consider before any code gets written (and which may not be needed)?

edit: Adding that only BU members can raise BUIPs, however, if a member wants to sponsor this BUIP and work with honeybadger to produce a more detailed specification, and/or code, then that option is also available.

[edit renaming the BUIP to a temporary name until sponsorship is achieved]
 
Last edited:
  • Like
Reactions: Bagatell

honeybadger

New Member
Dec 14, 2016
4
3
@solex
>Ideally any miners on a weak-fork will be 10% or less, and the difficulty adjustment to get back to 10 minute blocks will take a year or more, as miners drift off the weak fork. It will probably stall quickly.

Another problem with not orphaning core blocks is that I can see the following happening:
1. wealthy early-adopter smallblockers create core-only transactions with enormous fees, eg. 300 btc.
2. they buy special core-only mining contracts at high price

How long does it take for a miner with ~15% hashpower to earn 300 btc? Not revenue, but income. With margins in the low one digits that's close to a month. That's an enormous incentive to defect. After collecting the fee they want the old 1MB chain to be valid, so they continue mining on it.
Now you have 25% of hashing power back, which makes remaining miners more likely to defect. Repeat high fees. At the end of the day it's BU fork that has 10% of the hashing power.

If 300 btc is not enough, how about 1000 btc? Staggered over several transactions to entire different miners.

I guess it's possible for BU supporters to start throwing BU-only high fees and buy contracts... It's unclear who would win, but in any case this bidding would be dangerous and enormously wasteful.

Theoretically all this also applies to the merge mining case, but here the majority of hashing power would have to defect at once, which makes it significantly less likely.

I personally can't see a switch to >1MB blocks happening without merged mining. Excluding a miracle option in which Core changes its mind.

>So, would you be OK to remove the BUIP042 tag

ok
 
Last edited:

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
@honeybadger
300corecoin != 300BTC

assuming the >1MB fork happens with a super majority.

then BTC blocks will produce ~1BTC worth of fees ( maybe more now that they can fit double the TX )

assuming coincoin retain 10% of there values they would have to be willing to pay minners 10corecoins every ten minutes just to keep up with BTC fee output,
but the block reward is corecoin too so that 12.5BTC is suddenly worth 1/10th that of the real chain.

so there fees/ core-block would have to be an even 110corecoin just to match the value being minted by BTC blocks, that

thats 660corecoins an hour, 15,840corecoins a day 110,880 corecoins a week

just to offer the same value BTC is offering miners
[doublepost=1481832765,1481831927][/doublepost]i guess they could flat out buy miners with real post-forked BTC to get there blockchain rolling again.

i have a feeling that would be a very bad financial move on there part.