Gold collapsing. Bitcoin UP.

Griffith

Active Member
Jun 5, 2017
188
157
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

Well-Known Member
Aug 26, 2015
5,257
12,994
>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?
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
>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?
 

imaginary_username

Active Member
Aug 19, 2015
101
174
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.
 
  • Like
Reactions: freetrader

rocks

Active Member
Sep 24, 2015
586
2,284
@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....
 

bitsko

Active Member
Aug 31, 2015
730
1,532
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)
 
  • Like
Reactions: Norway

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
>My bank account can't do that.

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

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410
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

Well-Known Member
Aug 26, 2015
5,257
12,994
you're absolutely right. the officers of BU have now put their own interests/sentiments/biases above those of the membership without a vote.
 
Last edited:

Griffith

Active Member
Jun 5, 2017
188
157
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