Topic: ToominCoin aka "Bitcoin_Classic" #R3KT - page 22. (Read 157135 times)

Correct.

And even if we did, it would be futile, since neither devs nor miners can force users to adopt it.
It is literally technically impossible for miners to activate a HF period.

Correct.

And even if we did, it would be futile, since neither devs nor miners can force users to adopt it.
It is literally technically impossible for miners to activate a HF period.

so you're saying you think core will not/should not, add in the code required to allow miners to activate a HF with >75% hashing power.

The HK roundtable included agreement on this point, that miners do not decide hardforks. It doesn't contradict it in any way.

Even if it wasn't part of the document, this inability of miners to decide hardforks is an aspect inherent in the nature of hardforks, not something I nor anyone else has decided.

The HK roundtable included agreement on this point, that miners do not decide hardforks. It doesn't contradict it in any way.

Even if it wasn't part of the document, this inability of miners to decide hardforks is an aspect inherent in the nature of hardforks, not something I nor anyone else has decided.

so much for "Luke is focused on fulfilling the promise"  

Definitely not. Miners do not decide hardforks, much less vote on them.

All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.

I don't want you to freak out or anything but Luke is focused on fulfilling the promise. Luke's opinion is also one that blocks should be limited to 0.5MB by miners right now. Additionally, it was made abundantly clear that the developers at that meeting do not speak for core. Thus your hopes for getting a consensus of core supporting Luke's HF proposal is very low, especially since there are so many other solutions on the table to increase capacity and scalability without the same tradeoffs.

Now this would be the better way to convince developers to support an increase in the blocksize:

1) Figure out a method to encourage more decentralized nodes and decentralization of mining to alleviate their concerns. Developers have a clear understanding of the security vulnerabilities of bitcoin unlike the average user and see how vulnerable it is now, placate these fears with real solution or evidence and they will be much more likely to agree that increasing capacity with the blocksize is safe

2) Focus on helping layer 2 solutions like LN , payment channels, ect to increase capacity.

sigh.

I don't even know why I'm responding here.  People's minds are clearly made up, and people's lines are clearly drawn.

Full disclosure.  I yelled pretty loudly last year that I thought the block size needed to be raised.  Some agreed; others didn't.  That's okay.  It's not a decision for one person, whatever I think of the quality of my assessment.

I watched blocks start filling up, and on some days there was a very large backlog of transactions.  People were still arguing about the block size increase.  

The camps started to regard each other as enemies and accuse each other of trying to destroy Bitcoin.  Still no block size increase.  Arguments only growing hotter.

People started to openly threaten each other, with schemes to deliberately subvert consensus and plans to engage in deliberate double spends and other scamming behavior held over one another as threats.

Some asshat started blowing something like $60G per week (unless it was a miner - in which case they may or may not have broken even on the increased fees that legitimate transactions were paying) just to stuff the block chain - either because of an enormous financial need to influence the block size decision, or because hey, if we can make them compete with each other more for the fixed amount of space available, it's profitable.   Community could have had any number of constructive responses but instead just started howling and blaming each other.

At about this time I gave up on the community and sold my coins.  If the people driving the decision were functional and worked together, or even if they had been discussing the problem in good faith, I would still be a believer even if block size didn't immediately increase.  But that's not what happened, and I've seen too many other cryptocurrency ideas die horrible deaths.  Digicash, Ecash, E-gold, Beenz, etc...  All kinds of things that existed before the Nakamoto Consensus Protocol was invented, showed up and died.  Most of the centralized or owned ones wound up in court.  The few "decentralized" schemes (which still required a central authority to control userIDs because they were focused on reavealing a userID if AND ONLY IF that user attempted a double spend), died of non-participation as people didn't bother dealing with a gatekeeper.  And a couple of other systems that might have succeeded, died of toxic communities and an inability to work together to solve problems.  IE, of exactly what is happening here.

This one got further than any of the others, and a lot of non-cryptography people have heard of it where most never heard of the previous ones.   So writing it off was a real shame.  But I have not recently seen any reason to believe this community is going to start working together to reach any consensus, and in the absence of any willingness to try, it's simply a poor investment.  And the technical problem with scale is real.  I haven't seen any worthwhile approach to dealing with it - not the one I suggested nor any of the others.  

So...  I'm out.  And I'm pretty sure I'm not the only one.

Now this would be the better way to convince developers to support an increase in the blocksize:

1) Figure out a method to encourage more decentralized nodes and decentralization of mining to alleviate their concerns. Developers have a clear understanding of the security vulnerabilities of bitcoin unlike the average user and see how vulnerable it is now, placate these fears with real solution or evidence and they will be much more likely to agree that increasing capacity with the blocksize is safe

2) Focus on helping layer 2 solutions like LN , payment channels, ect to increase capacity.

House repairs, and three years tuition set aside for a Ph.D program.

I understand that the 2MB HF will need a high % of mining backing it in order for it to activate, but i would like to know if core plans on adding in the code to allow this process to happen.

House repairs, and three years tuition set aside for a Ph.D program.

How'd you cash out your swag?

How'd you cash out your swag?

The Agreement has nothing to do with Greg , Blockstream , or the rest of core devs that didn't participate. Luke has promised to deliver the code to fulfill the agreement by July, whether the miners and the community decide to use it or not is unknown. The earliest a HF will occur will be in July 2017 if the miners stick to the agreement so don't expect anything soon.

Your question is odd because it assumes that Greg is running the show or even has commit access. He gave that up a long time ago. A question that would make sense in this context is asking each individual core devs their opinion.