Gold collapsing. Bitcoin UP.

[Griffith]

how did this organization even operate before you got lawyeriffic on the buip's?

I'm not supposed to lawyer it? Am I doing it wrong? I thought I was doing it Wright...
[doublepost=1555744021][/doublepost]

Personally I don't see much of a problem implementing an adaptive algorithm like the one @imaginary_username has proposed. Getting rid of the cap entirely could be another future option, but we need massively better clients before then.

We will get there

I don't see a solid reason why we should delay putting in the dynamic limit now. It gets more expensive to do HF upgrades the longer we wait anyway. deadalnix had a pretty good explanation about why this is on youtube somewhere...
[doublepost=1555744090][/doublepost]

The warning is here:
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-1425#post-92019

EDIT:

PS. I might formulate my proposal on BCH different than "Drop BCH support" to get the maximum benefit from the voting rules regarding majority etc. All the tricks used against BSV are on the table.

I find it very interesting that you dont like the proposal to get BSV its own client.

 

[cypherdoc]

>I don't see a solid reason why we should delay putting in the dynamic limit now. It gets more expensive to do HF upgrades the longer we wait anyway. deadalnix had a pretty good explanation about why this is on youtube somewhere...

This is a good idea and should be implemented now.

don't you see the hypocrisy of him admitting BCH will ossify longterm yet a blocksize increase can wait? or that BCH can increase when needed indefinitely?

 

[satoshis_sockpuppet]

Sincere thanks to all the hardworking EC devs.

These guys are really amazing. Just a 100 % positive thing to watch.

 

[cypherdoc]

>I don't see a solid reason why we should delay putting in the dynamic limit now. It gets more expensive to do HF upgrades the longer we wait anyway. deadalnix had a pretty good explanation about why this is on youtube somewhere...

This is a good idea and should be implemented now.

don't you see the hypocrisy of him admitting BCH will ossify longterm yet a blocksize increase can wait? or that BCH can increase when needed indefinitely?

likewise, bsv should just remove the limit entirely right now.

if they're gonna have the miners start off with a"hard" limit (soft by some definitions) of 512MB anyways, what's it matter?

 

[Zarathustra]

The CSW Devil Cult celebrates the reorg.


@shadders , ally of the devil
"On forks, orphans and reorgs"

https://www.yours.org/content/on-forks--orphans-and-reorgs-0c0c39d3c79b

 

[cypherdoc]

excellent article @shadders

as I've always said; FSFA ftw

 

[rocks]

Perfectly stated

 

[imaginary_username]

The fact that people are cheering for Shadder's extremely dishonest article shows how beyond help this thread has become. You can't "monitor both chains" at the time of reorg battle if they existed due to slow propagation in the first place. You will never be sure if there's a third chain tip either - even if the miner is honest - and you can "monitor" it even less. At extreme ends - as we've seen in the gigablock testnet - propagation and validation never catches up and chains can end up semi-permanently spltting, so you can never know if things in your mempool is doublespent in another chaintip.

In the end you're stuck with exchanges requiring 144 confirmations to be safe as we've seen today. Sure man, businesses with money on the line are all wrong, you're the one who's right!

Jesus christ.

 

[Zarathustra]

Jesus christ. Allowing stress tests resulted in a situation where we can already handle ten times the 22 MB capacity of our competitors.

@Zangelbert Bingledack linked to this epic post:

https://www.reddit.com/r/btc/comments/99q4ke/socalled_poison_blocks_what_greg_maxwell_called/

 

[sgbett]

You will never be sure if there's a third chain tip

That is always the case and always has been, you never know. You build the one you think is valid. Majority hash wins. This is bitcoin 101 stuff.
[doublepost=1555836750][/doublepost]*transactions unaffected.

 

[rocks]

@imaginary_username you either agree with @shadders because that is the mechanism which creates economic incentives to invest in scaling, or you agree with this insanity on r/bitcoin which is what you are left with when economic incentives are removed.

https://bitstagram.bitdb.network/m/raw/a8d70d3f65a71c1523bf0befdb7fc885ea87dcefcbb233d8bf4bae2bffa47568

The problem with Bitcoin core is the dev team believed it was their job to scale Bitcoin. However this is wrong, scaling is the job of network participants and economic incentives motivate investment.

Worse core held the protocol back so no one could scale. This action removed the very economic incentives that are necessary for Bitcoin to scale, and so it didn't. Then years later everyone in the core camp says "see Bitcoin can't scale", but it didn't scale because it can't, instead it didn't scale because they fundamentally broke that which they don't understand....

 

[freetrader]

The Bitcoin Cash community gathered more than $5000 in pledges towards forking Bisq to use BCH as base currency.

 

[bitsko]

The fact that people are cheering for Shadder's extremely dishonest article shows how beyond help this thread has become. You can't "monitor both chains" at the time of reorg battle if they existed due to slow propagation in the first place. You will never be sure if there's a third chain tip either - even if the miner is honest - and you can "monitor" it even less. At extreme ends - as we've seen in the gigablock testnet - propagation and validation never catches up and chains can end up semi-permanently spltting, so you can never know if things in your mempool is doublespent in another chaintip.

In the end you're stuck with exchanges requiring 144 confirmations to be safe as we've seen today. Sure man, businesses with money on the line are all wrong, you're the one who's right!

Jesus christ.

what does it have to do with the thread?

(vote to kick out imuname BU2019)

 

[cypherdoc]

Jesus Christ, Happy Easter.

 

[Zarathustra]

 

[Norway]

Jesus Christ, that music comes from bitcoin. My bank account can't do that.

 

[cypherdoc]

>My bank account can't do that.

I'm sure your BCH and BTC wallets will never do that.

 

[Norway]

Some people are trying to make BCH the default blockchain supported by Bitcoin Unlimited over the head of the membership.

Currently, the client supports both BSV and BCH, but has BCH parameters set as default.

The membership never voted on setting BCH parameters as the default. This was a decision by the elected officers. Not by the membership.

The default parameter setting is now leveraged to sement the BCH support by BU. It's a power grab without an honest vote by the members of the organization.

BUIP113 and BUIP114 build on the false assumption that BCH is the default client supported by BU as an organization, and puts support for BSV on trial.

I hope people can see these underhanded tactics at play. If the membership is to vote on support of BCH and BSV, the proposals should be symmetrical. Anything else is dishonest and undermines the membership.

 

[cypherdoc]

you're absolutely right. the officers of BU have now put their own interests/sentiments/biases above those of the membership without a vote.

 

[Griffith]

Some people are trying to make BCH the default blockchain supported by Bitcoin Unlimited over the head of the membership.

Currently, the client supports both BSV and BCH, but has BCH parameters set as default.

The membership never voted on setting BCH parameters as the default. This was a decision by the elected officers. Not by the membership.

The default parameter setting is now leveraged to sement the BCH support by BU. It's a power grab without an honest vote by the members of the organization.

BUIP113 and BUIP114 build on the false assumption that BCH is the default client supported by BU as an organization, and puts support for BSV on trial.

I hope people can see these underhanded tactics at play. If the membership is to vote on support of BCH and BSV, the proposals should be symmetrical. Anything else is dishonest and undermines the membership.

You never read BUIP 063 did you? Dont worry. ill quote it for you

BUIP063: (passed 23:0:0) Support Bitcoin Cash with an official implementation

The purpose of this BUIP is to regularise BU Cash as an official BU implementation with equal status as the existing BitcoinUnlimited implementation which has been advanced and maintained since November 2015.

BUIP 063 clearly outlines official support of Bitcoin Cash via an official second client called BUCash which is why it is the default and the BSV chain is able to be followed via user configuration of BCH HF params.

BUIP 113 would give BSV official support in its own client.



BTC is also officially supported on EQUAL status with BCH within BU right now as stated in BUIP063. We just dont have any developers within the organization who want to dedicate time to working on the BTC client right now. BUIP 115 is what would end support for BTC. It is currently still active

Edit: bolded the word equal for you