Topic: What are you all - Sheep? - page 3. (Read 3121 times)

Then don't be a coward and fork today. I mean, I hear so much talking about how superior larger blocks will be, yet not a single one of the loud voices ever does anything except shout.

If large blocks are superior, as soon as you fork to a chain which is making large blocks, the market will follow you.

No risk, no reward.

I will tell you what isn't going to change anything, another thread whining about Core when it's clear to me that 13.1 is being adopted rather quickly. If the "majority" wants bigger blocks, they need to do something about it instead of making another new thread.

Is he?  I hadn't heard, but I've been paying attention to extra-bitcoin politics at the expense of all else lately.  To answer your question, however, this would be fantastic news to me because 'nullc / Blockstream / GMax'.

Unless the guy has done a 180 since last I looked I couldn't be happier to have him at the helm.  And I would not have held tight to my stash had he not maintained his significant input around the time of the blocksize wars.  I'll wager that the relatively steady and none-to-shabby value performance of Bitcoin over the last year has a lot to do with the confidence people have at the dominant development team.

If that seriously is your "solution", I think you're going to be disappointed.  It only qualifies as a solution if you can make it happen.  In order to make that happen, you need the rest of the market behind you.  I doubt you'll find the support required to achieve that (impossible dissolving of a commercial entity you have no power over notwithstanding).  You'll need to make some significant compromises to your stance to make it more acceptable to others.

I have a solution: kick fucking Greg Maxwell in the fucking head and set the block limit to 8MB right away.  Then, go work on Lightning in a non proprietary open source way for the next two years.  Dissolve Blockstream and never let a private entity take control of Core commit access again.

That is my solution. Glad you asked.

Oh, OK.  Sheep then. The answer to the question is 'yes'.  Yes, we are all a fucking bunch of sheep. 

Not another one of those politically biased threads. Stop feeding into the games played by Ver. The majority of the industry is standing behind the Core contributors and on-chain scaling solutions like Segwit. For example, Segwit has more hashrate after a few days than what the XT/Classic/BU takeovers have managed to gather in over a year.

---

The community is divided, and that is obvious. However, one side is constantly being toxic and is now trying to stall via political games. Yes, wanting to block Segwit because you dislike Core, Blockstream, Maxwell or whatever irrelevant reason you have, is stalling.

I actually like your idea and would most likely support such a hard fork (if properly designed).

Are you just here to shout at everyone else or do you have genuine solutions?

I'd like to see a dynamic, albeit slightly curtailed BIP106 + Segwit too.  I say curtailed, as the doubling or halving aspect of the original proposal could easily become excessive.  A 12.5% (or if percentages prove to be a bit messy after a while, then just say plus or minus 0.125 MB) adjustment would prevent any sudden, drastic movements.  People still seem fixated on this strange notion that the blocksize limit should be a whole number, but there's no implicit reason why this should be the case.  The fees being collected by the miners, as detailed in BIP106's "Proposal 2", should also be factored in to help prevent gaming the system.

Although, if Segwit and Lightning require a certain minimum floor to function, as I'm led to believe it may, we'd have to ensure the code doesn't allow it to drop below that level.

Any coders up to the task?

Why? Because there's 3 reason :
1. Many member even don't know about this problem
2. Some member who knows about this can't do anything because they don't really understand what happens (also happens to me)
3. People still think that words won't change anything

OR we just ask core developer to increase blocksize (easier than change blocktime) and ask every full nodes user to upgrade their hardware and internet connection as well so the problem will be solved faster
But, some people won't let it happen.

Not much action required to update Bitcoin Core...

See that is the problem , ALTs are able to out perform BTC and instead of jumping in the BTC Dev and Mining pools mess,
people are just frighten it is off topic. That is why nothing gets done. Op was right.




 

this thread is for general discussion about bitcoins, i mean, please no hybrid between bitcoins, litecoins, Trump's, and too much more, that's leads me feel that this thread comes to be off topic.

Easy answer , everyone dump BTC for one of the Alts.
Problem solved. 


 

And what should we do?

Do you have any suggestions,any ideas?How to control blockstream,GMax etc.....

First come up with a plan,then call everyone sheep.

I don't even know how a radio continues to work when you shut the window so I'll leave things like this to those with greater knowledge.

Are there agendas at work? You bet. How informed are those agendas by technical worries versus ideology? I do not have a bleedin' clue.

Agree, people stand for their rights when their rights are abused HARD.
If only soft, people just continue to live their lives.
In politics same stuff.

They better do something sooner rather than later.

https://bitcointalksearch.org/topic/transaction-queue-size-1689151

Or are the Bitcrap religionous fanatics going to say 16 hours delays and counting is good for you.  





 

The issue is a matter of trust, people believed they can move Bitcoin forward, the route they are taking may not satisfy everybody but we are not where we were yesterday with Bitcoin. Segregated Witness is gaining public support each day

Unfortunately, the most attractive dynamic blocksize proposal, i.e. BIP 106 has never been coded into any reference client.

scaling:
the solution is not segwit or dynamic baseblocks.
it's both
EG
(Xmb base Xmb weight dynamic), default set to 2mb base 4mb weight to allow upgrade. and then consensus (independent node users vote) adjusts in own time. without dev spoonfeeding/controlling how or when

diversity vs centralisation:
the solution is not segwit or dynamic baseblocks. its not core or BU or classic or xt or knots, etc,
it's both, its all, its everyone included
all implementations should all have code for all features and then let consensus choose what features get utilised because all implementations can handle it, all on one chain
EG
core allows dynamic baseblocksize and segwit
classic, BU, etc includes segwit and dynamic blocksize

bloat/spam:
the solution is not to use the economic banker mindset of fee wars to control "spam" as thats just a barrier of entry for developing countries
its instead
limit sigops of transactions. as there is no rational need for a single user to need say 500-80,000 sigops in one tx.
its instead
use CODE for rules, not price tags/costs
its instead
lean clean transactional data.
its instead
not allowing arbitrary data to be added that has nothing to do with transaction/validation (even twitter/sms limits how much crap people can type and that is a communication tool. so its obvious bitcoin shouldnt be used for 2.2mb of non transactional waffle in the 4mb weight)


then the choice of "brand" implementation is not about which king should control the rules, but getting back to no king controls the rules, all "brands" are on a level playing field and the choice is then about bug risk or which has the better user interface.

split or no split:
it should never be a chain split debate. it should be about one mainnet utilising consensus.
EG if gmaxwell fears that a feature wont be popular, dont tell other implementations to intentionally fork off.. but instead code it, and then let consensus prove him right or wrong by seeing if it activates or not.