BUIP107: (closed) Sell the BCH portion of BU's funds for BSV

[Windowly]

BUIP107: Sell the BCH portion of BU's funds for BSV
Submitted by Windowly
15 December 2018

Bitcoin Unlimited was originally a group founded to let miners competitively decide the block size without any central organization of developers defining limits.

On Nov. 15, the original Bitcoin Cash chain forked, with the BCH side advocating for 32 mb blocks and the BSV side proposing 128 mb blocks with plans for totally removing any limit in the immediate future. In addition to upping the DOS limit, the BSV side has successfully stress tested 32+ mb blocks.

BSV's vision most closely coincides with Bitcoin Unlimited's vision of free competition, emergent consensus, and no delay in on-chain scaling. Consequently, this BUIP proposes to sell all BCH coins for BSV.

The trades would be carried out over the months January and February at the discretion of the President, Secretary and Lead Developer of BU (the three key holders). Coins will be stored in multisig wallets with keys held by the three BU officers at all points in time.

After the trades have been completed, the Secretary will report on the trades to the BU community (no less than 30 days after the last trade).


[At the moment this is a draft BUIP, although I plan to submit it for the January election after community feedback and tweaking.]

 

[imaginary_username]

Executing this will mean a future of BU's finances being beholden to a centralized authority who can censor and dictate its use, and hence highly undesirable for anyone who thinks an independent BU is of value.

 

[freetrader]

BSV's vision most closely coincides with Bitcoin Unlimited's vision of free competition, emergent consensus

This does not explain why BSV chose the ABC client to fork from instead of BU whose client is based on Emergent Consensus. (*)

Apart from that incongruency, I oppose this BUIP because BSV's vision of patents, aggression against chains that its leadership forks away from and lawsuits against open source developers appears nothing like the Bitcoin Unlimited vision I signed up for.

* I have reviewed the BU revision history and found that the only discernable contributions from SV developers were via merges of ABC commits authored or co-authored by Dan Connolly. That is a poor record of contribution to BU especially considering that BU implemented SV support ahead of the recent fork.

 

[Christoph Bergmann]

Not sure about this. Maybe it would be better to propose going full Norway instead of bagatell berserk.

But I am very much for voting about this proposal, as it will show where bu membership stands on the split.

Maybe we could also vote about this in a less financial way, by just giving the options to support bsv, bch or both ...

 

[solex]

This is a legitimate BUIP and @Windowly can bring it forward to vote if he wants.

I do make the observation that Bitcoin Unlimited's membership has the full spectrum of opinion about the 15 November fork and the situation with BSV and BCH. The org also holds equal amounts of both coins, which, in my opinion, is a reasonable position to maintain. A major goal of BU is onchain scaling, which the development teams for BCH and BSV both support wholeheartedly.

 

[Norway]

I want world money. To get there as fast as possible, we shouldn't be neutral. Time is ticking, and we have to secure the chain with a substantial amount of fees in case the price stays low. The next halving is just around the corner.

It took a whole year for @theZerg's great code to parallelize mempool admission to move from experimental stage to release. We need to pick up the pace if we think the Fidelity Problem is real.

I will vote yes to this BUIP. And I hope BCH proponents will make a similar counter BUIP.

Worst case scenario is that Bitcoin Unlimited stays neutral. Because we are running out of time.

 

[solex]

@Windowly, please advise whether you want this BUIP brought froward into the next vote.
Note, I added 3 heading lines,

 

[Windowly]

Yes I would like to submit this for the next Jan. 16th vote.

The full text would be as follows:

_____
BUIP107: Sell the BCH portion of BU's funds for BSV
Submitted by Windowly
15 December 2018

Bitcoin Unlimited was originally a group founded to let miners competitively decide the block size without any central organization of developers defining limits.

On Nov. 15, the original Bitcoin Cash chain forked, with the BCH side advocating for 32 mb blocks and the BSV side proposing 128 mb blocks with plans for totally removing any limit in the immediate future. In addition to upping the DOS limit, the BSV side has successfully stress tested 32+ mb blocks.

BSV's vision most closely coincides with Bitcoin Unlimited's vision of free competition, emergent consensus, and no delay in on-chain scaling. Consequently, this BUIP proposes to sell all BCH coins for BSV.

The trades would be carried out over the months January and February at the discretion of the President, Secretary and Lead Developer of BU (the three key holders). Coins will be stored in multisig wallets with keys held by the three BU officers at all points in time.

After the trades have been completed, the Secretary will report on the trades to the BU community (no more than 30 days after the last trade).
____

 

[torusJKL]

I like the idea of Bitcoin SV to have a stable protocol and in turn attract big business.
But at this point in time we don't know if this strategy is the winning one.

BU should not gamble with its finances at this point in time and I think it is to early to make this decission.

 

[theZerg]

I do not support this BUIP. Both sides of the fork have made decisions or announcements that in my opinion are counter to the spirit of global money as I described here: https://medium.com/@g.andrew.stone/bitcoin-cash-and-bitcoin-sv-stop-the-self-destruction-386ea3e09b6e

nChain has not hidden the fact that SV is going to be centralized development/decision making. But the idea that BCH is decentralized was shown as a lie in this past fork with the insistence of the majority hash client ABC to include features like the 100 byte tx limit and CTOR that were criticized by significant portions of the community, including members of BU.

Both forks have serious issues and to pick one at this time is premature.

 

[Norway]

@theZerg

nChain has not hidden the fact that SV is going to be centralized development/decision making.

When you say development, I assume you are talking about protocol development. And their roadmap is exactly the opposite. The whole point is to remove protocol development, because of all the problems it causes.

Centralized development is a small group of people changing the protocol as they wish. The single point of failiure the last five years have been protocol developers. The result has been fragmentation and loss of network effect.

Time to focus on performance improvements, like BU has been great at.

 

[theZerg]

Yes, I was talking about any hard or soft forking change which I think you are calling "protocol development". I think that their "roadmap" (I have not seen a roadmap document, please link if you know of one) is at best confused WRT freezing the protocol. CSW's blog posts seem to propose major and ongoing protocol changes.

 

[imaginary_username]

@theZerg


When you say development, I assume you are talking about protocol development. And their roadmap is exactly the opposite. The whole point is to remove protocol development, because of all the problems it causes.

Centralized development is a small group of people changing the protocol as they wish. The single point of failiure the last five years have been protocol developers. The result has been fragmentation and loss of network effect.

Time to focus on performance improvements, like BU has been great at.

"Sunsetting" P2SH is removing protocol development? "Recovering" coins?

Please stop lying.

 

[Norway]

@theZerg I'm not saying the BSV protocol is frozen now. The goal is to freeze it as soon as possible, hopefully in may.

A BU client supporting bignum in script would be cool.

 

[79b79aa8]

But the idea that BCH is decentralized was shown as a lie in this past fork with the insistence of the majority hash client ABC to include features like the 100 byte tx limit and CTOR that were criticized by significant portions of the community, including members of BU.

Both forks have serious issues and to pick one at this time is premature.

indeed.

ABC introduces changes that appear to be improvements to devs that are inexperienced technically, economically, and in project management. the resulting software may or may not become more efficient, but the underlying token has shed monetary properties.

BSV is prepared to go for a while without significant economic activity, with the sole aim of delivering a stable product that can actually compete as a currency. they therefore do not share BU's pre-fork strategy to add features in order to drive short-term adoption. they are doing this deliberately, purposefully, seemingly having long thought about economic and implementation details. the IP sabre-rattling may put off freedom-loving devs - but i doubt it is being done on a whim, rather they estimate it is in line with the single goal.

the preferable path seems clear, but out of prudence i am staying put with my own coins, and i won't vote for BU to do otherwise.

 

[Roy Badami]

I have a hard time seeing why we would want to support BSV given:

• BSV is proposing damaging changes such as:
  
  • removing P2SH (on which all practical multisig implementations depend)
    
  • a (technically impossible) plan to make it impossible to burn coins
    
  • dangerous plans to reallocate certain coins to miners, etc
• It's hard to see why anyone would trust CSW's technical stewardship, given all his published technical work is incomprehensible and nonsensical
  
• CSW/nChain make frequent threats to use patents to control development

But aside from all that, even if you think nChain's vision and stewardship represent the best option for the future, the market has spoken. All, or almost all, exchanges and payment processors have declared ABC the winner and given the BCH ticker and Bitcoin Cash name to the ABC chain. And BCH is worth almost double BSV.

The transaction envisaged in this BUIP is a risky and imprudent gamble on the losing coin - and is highly likely to lose BU significant funds.

I get that there are many people (myself included) who are not happy with the way development decisions have been taken by ABC, but I don't believe that either favouring BSV in general or supporting this BUIP in particular are the right way to improve the situation.

roy

 

[79b79aa8]

@Roy Badami

obviously we agree on how to vote on the BUIP, but not on our assessment of BSV. let me try to explain my thinking somewhat better to see if our positions can be brought closer. i'll focus on your list of "damaging changes" BSV is proposing.

first, i grant that BSV devs and stakeholders (ie BSV miners) have communicated their intentions extremely poorly. for example, it is not at all clear to me what the alleged problem with P2SH amounts to. i would appreciate it if you can point me to reliable information on the matter.

one is therefore forced to decypher the purpose of their assertions. in the case of burnt coins, the situation seems clear. the point was to criticize Wormhole and BCHABC, and to show that the people behind those projects are not thinking sufficiently far ahead, nor do they understand the ramifications of their actions. a token that essentially relies on proof of burn is poorly conceived, because, in the long run, burn addresses *will be* brute forced. there is no claim of making burning impossible, rather a thinly veiled claim that those staking a lot in the building of a token based on burnt coins are not qualified to control development.

similarly, the criticism of P2SH transactions seems to be that a change was introduced to the original protocol by the BTC devs that was not necessary, and whose ramifications, technical or legal, were not fully thought through, as they could pose problems in the long run. one would expect for further discussion of this matter to show what the problems might be, and how the benefits of P2SH could be achieved otherwise. in any case the position cannot be one of mere functionality crippling, that makes no sense, there is plenty of money on the line.

i don't know of any plans to reallocate money to miners. that seems mad. i do know that misinformation is rampant. so maybe we can check where you are getting that information from, and discuss it further.

as @AdrianX has pointed out: look at what BSV is doing, don't be distracted by what its enemies say they are saying.

 

[freetrader]

ABC introduces changes that appear to be improvements to devs that are inexperienced technically, economically, and in project management.

Which such changes are you talking about?

BTW, you're asking @Roy Badami to substantiate things that CSW and Calvin Ayre have spoken about at length on their official channels. Maybe you should first check BSV sources yourself - DYOR style - before accusing others of misinformation.

Start with Coingeek's website and Craig Wright's Medium blog.

look at what BSV is doing

If one wanted to see what BSV developers are doing or planning to do, one would have to be sitting in meetings @ nChain. Their protocol development is solely directed corporately -- there aren't even meaningful visible changes on the official repository for the period since mid-October 2018.

 

[79b79aa8]

>Which such changes are you talking about?
CTOR, merklix trees.

> look at what BSV is doing.
i wasn't referring to development per se. BSV appears to be mined with dedicated hash, not with hash on loan from BTC. i prefer the former model.

>Maybe you should first check BSV sources yourself - DYOR style - before accusing others of misinformation
you are partly right, i have not read as much as i used to. that's because i think the era of discussion over social media outlived its usefulness, both for purposes of development and adoption growth.

it was fun while it lasted. i still hold you in the highest regard.

 

[freetrader]

At least as far as CTOR was concerned, experienced developers from various clients were on the fence until late stage, and rough consensus seems to have emerged that the change can accrue (many?) more benefits than harm (technically). Of course this didn't stop SV from splitting the network over this issue.

I'll also remind again (and I'll keep doing this) that it wasn't ABC who suggested lexicographical ordering as a first step, they wanted to move to Any-Ordering first but were swayed by Tom Harding's (XT) suggestion to go directly to LTOR.

Once the devs had agreed on this for the fork, ABC just stuck to the plan.
Blaming CTOR solely on ABC is very disingenuous, although I'll allow for the possibility that you aren't aware of what transpired behind the scenes.