Gold collapsing. Bitcoin UP.

[torusJKL]

@Griffith
I wanted to introduce a tie-breaker rule in the past.
Unfortunately it didn't make it into the Articles.
https://bitco.in/forum/threads/buip050-closed-double-yes-with-tie-break-question.1924/

That would have been a possibility to force an outcome.
But changing the rules from within its own BUIP doesn't work.

 

[Griffith]

We can't have proposals that removes the option of rejecting the proposal.
[doublepost=1553690345][/doublepost]These games might work on a 5y old, but c'mon. We are grown ups here.

voting yes results in no change. that would be the equivalent to rejecting change

 

[Norway]

@Griffith

Hypothetical:
Let's say BUIP113, BUIP114 and BUIP115 gets rejected because you try to control all the outcomes of the vote. How do you think this will be interpreted?

 

[Griffith]

@Norway in the scenario where all 3 fail, which i do think is very unlikely, it would show a deep rooted split within the organization. i think this would be pretty much in line with current feelings towards BU as expressed on reddit and sometimes within this own forum (in the form of extreme senseless bickering)

at this point it should be up to the elected board running the org to save it, which is why i suggested giving them the decision making power. to save us from ourselves so to speak

 

[Norway]

in the scenario where all 3 fail, which i do think is very unlikely, it would show a deep rooted split within the organization.

No. It would only show that the membership rejected your proposals.

 

[Griffith]

@Norway yes, membership rejected the support of all 3 coins. we then would support nothing. then what?
[doublepost=1553692315][/doublepost]i edited the BUIP to reflect feedback from other members of the forum. in the event that all 3 buips fail to pass no changes are made.

 

[Norway]

I think the most exciting going on in BU right now, is @sickpig taking the BU node for a spin at the Scaling Test Net (STN). Can it handle a consistent stream of 512MB blocks? If not, what are the bottlenecks?

Thanks again to @sickpig for stepping up and doing this.

 

[Norway]

@Peter R just released the article Why you should resign from Bitcoin Unlimited

Peter, do you think I should resign from BU because I'm impressed by Craig Steven Wright's wheelbarrow of degrees, papers, patents, companies, mining, articles, talks and vision?

You should dig up the courage to tell it to my face if you mean that.

 

[torusJKL]

I can mostly agree with the article.

You are impressed by technobabble, a wheelbarrow full of degrees, and lawsuits against open-source bitcoin developers.

Unfortunately this last reason is very biased and I don't see how it relates to the core principles of BU.

Interestingly I would say that BSV is even more in line with this article than BCH.
This sums it up very nicely:

[...]We don’t really need Lightning, CTOR or the acronym of the month next month. The only change Bitcoin ever really needed to succeed was the removal of the single line of code that limited the block size. BU achieved that and so much more.

 

[Peter R]

@Norway I meant everything I said in that article. I think you are working to make bitcoin successful, but if "you are impressed by technobabble, a wheelbarrow full of degrees, and lawsuits against open-source bitcoin developers" yes I think you should resign from BU.

One of BU's central tenants is "to foster competing implementations of the Bitcoin protocol in order to provide more choice to node operators and to add robustness to the network." Being impressed by those who are suing the developers of these competing implementations is antithetical to BU IMO.

 

[torusJKL]

Nobody is stopping BU to be a competing node implementation on BSV.
The protocol is fixed so nobody is in charge of it anymore.*

I would love to see BU compete in the scaling race currently happening on BSV.

*some changes are pending (e.g. sun-setting p2sh) in order to get as close as possible to version 0.1.

 

[Norway]

@Peter R
I see you choose your words carefully here. Let's be clear:

I'm not impressed by technobabble. I was not impressed by the conditional probability you constructed to cover the flaw of a missing premise in your bet with CSW.

I'm impressed by CSW's achievements and talks. Do you think I should resign?

 

[cypherdoc]

Nobody is stopping BU to be a competing node implementation on BSV.
The protocol is fixed so nobody is in charge of it anymore.*

I would love to see BU compete in the scaling race currently happening on BSV.

*some changes are pending (e.g. sun-setting p2sh) in order to get as close as possible to version 0.1.

yes, it's actually important for BU to provide an alternate implementation on the BSV protocol as a fallback to any shenanigans that asshole CSW might pull, if he can (im doubtful that he can).

I'd also add that there's the final piece to the blocksize limit that BSV requires; either unlimited or adapted blocksize.

 

[Norway]

@cypherdoc

I'd also add that there's the final piece to the blocksize limit that BSV requires; either unlimited or adapted blocksize.

AFAIK, the roadmap of BSV is 512MB May this year, 2GB November this year and unbounded May next year.

 

[79b79aa8]

i would like to address the perception that BU members that have been critical of BCH are therefore BSV supporters. further, since such support is seen as (technically?) nonsensical, such members must have been either bamboozled or coopted.

what i am, primarily, is an investor in bitcoin. as such:

1. i am interested in the P2P electronic cash and payment system, not in a particular piece of software, or a ticker symbol.
2. i am skeptical of BCH's governance structure, as revealed on nov. 15 2018. specifically, i am reasonably certain that a protocol that can be altered against the advice of a significant number of participants in order to meet a software developing schedule cannot function as the basis of a transnational currency.
3. i see BSV as providing alternative, coherent, economically-grounded guiding principles.
4. i conclude, prudently, not to discount BSV.

as many have pointed out before, an us-vs-them mentality is not a sound investing principle. here is an imperfect, but nonetheless telling analogy: i prefer to brush my teeth with crest over colgate. but i own shares of both procter & gamble and colgate palmolive. should one of the two be mismanaged, the other is likely to pick up the business.

 

[cypherdoc]

I'll ask again, why is @freetrader smack dab in the middle of helping to spearhead yet another major divisive event in Bitcoin history by suddenly increasing his profile activity on r/btc and here to do so? the former fork was arguably desired but should have not included replay protection imo. this current BU splitting event ludicrously so. this one came totally out of the blue and no one was concerned until some of us, not even BU members (!) started complaining about ABC. I can assure you, lawsuit or no lawsuit, that won't stop.

 

[Christoph Bergmann]

Thanks for taking the ball, @Griffith, with making the situation in BU less uncomfortable. But I think your voting setup is flawed. I proposed an additional BUIP, 117.

 

[torusJKL]

Based on all these freestyle voting rules BUIPs (113 - 117) popping up I'm tempted to create yet another one.

I'll be calling it "redistribution of wealth between the members".

If voted in favor 50% of the BTC/BCH/BSV of the coins in possession of the BU organisation will be distributed evenly bettween the members. The other 50% will be given to the creator of the BUIP.

If voted against then 50% will stay in the possession of the BU organisation and 50% will be given to the creator of the BUIP.

Because this BUIP is very controversal, and members could fight it by spoiling their votes, the mandatory minimal votes to get a quorum shall not apply to this BUIP.

And any BUIP that contradicts this one shall be void no matter the outcome.

/s

 

[rocks]

The WP states:

"In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. "

The fact that is intra-block or inter-block it's an interpretation.

The Bitcoin timestamp server timestamp's all transactions in a block with the block's timestamp not the timestamp a transaction arrived to a node. The block's timestamp is the only timestamp in the system and it is tied to the real world through PoW mining, there are no other timestamps. As a result blocks are provided ordering at the inter-block level because all transactions in a block have the same timestamp. To see it any other way is confusing the protocol vs. the client. There are no zero-confirm issues with CTOR vs. TTOR because the whole block is either valid or invalid.

Again, the way ABC did it was wrong though. They should have made it an option where clients could request blocks in TTOR or CTOR ordering so that clients wouldn't need have to implement a massive update. By forcing CTOR on a short timeframe it in effect kicked other clients off of the network, I can see why BU and other clients would have been pissed.

If this was the only change ABC made I would have been fine with it, it was the other changes that do affect the protocol that I took issue with because it makes BCH something closer to an ABC altcoin, than Bitcoin.

 

[Christoph Bergmann]

Yes, to be honest ... For me this smells like an attack on BU. First Mengerian, Amaury and Todo leave in a loud and salty way, demanding participan in their warmanship-rhetoric. Then we have a BUIP proposing the reset of membership.