Pages:
Author

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

legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
legendary
Activity: 4410
Merit: 4788
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.
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 core is saying that there would be no code release THIS YEAR to allow USERS to show they want 2mb.. to then slowly over months get to a certain saturation point of that would then allow the pools to move forward..
is this whole round table stuff just smoke and mirrors and that no one(users or pools) will have any code that has 2mb as an option untill summer 2017..

if so.. what is so special about summer 2017.. why not have the code available sooner (this year) and then activate when a certain circumstance is reached.
why of why does it have to be based on seasons of a year, instead of how prepared and ready the community is by actually having the code in place ready.

code does not care or understand the word "SUMMER" so a technology should not be hindered based on seasons. and instead have code ready and prepared to activate when a certain network saturation level is reached.

if i see luke JR mention that the HF is dependent on a date or season. and code will only be released based on such season.. then that to me is just him delaying it for no logically or technical reason. but based on human decision.


here is a hint.. even with the 1mb rule.. pools didnt just jump to 1mb instantly.. even today some pools just want to make 0.2mb blocks. so pools can have the 2mb code existing in their program. but have preferential setting to only make <0.998mb blocks until they think the users nodes can handle it without mass rejection.

if a pool makes a big block to early it would get rejected and they would learn their lesson..
no one can predict which date on a calendar to move forward. and delaying the option or possibility purely because you cannot imagine a particular date on a calendar is also a futile mindset..

in short RELEASE THE CODE and then let users run it... then later pools can start making bigger blocks when and only when they deem the saturation point has been reached that their blocks wont get rejected/orphaned. without having to check a calendar to find out when spring turns into summer.

RELEASE THE CODE AND LET USERS GET PREPARED AND START THE BALL ROLLING TO ALLOW POOLS TO DECIDE WHEN THEY THINK THEIR BLOCKS ARE SAFE TO BE MADE BIGGER

by stopping users from having the code your just delaying any prospect of pools ever growing. RELEASE THE CODE AND GET THE BALL ROLLING
legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.
Definitely not. Miners do not decide hardforks, much less vote on them.

so much for "Luke is focused on fulfilling the promise"  Cheesy
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 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.
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.

hashing power has a strong incentive to align itself with the will of the userbase.
your right miner cannot HF somthing the user base will not adopt
but IMO you're wrong in thinking the user base will not adopt a 2MB HF should if it achieve >75% hashing power and get activated.

it's really sad to hear you will not code in that 2MB HF.
legendary
Activity: 2576
Merit: 1186
All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.
Definitely not. Miners do not decide hardforks, much less vote on them.

so much for "Luke is focused on fulfilling the promise"  Cheesy
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 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.
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.
legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
if core doesn't allow the miners to vote try to get >75% hashing power to activate the 2MB HF
that 5-7% hashing power classic has, will incress substantially.
but dont worry, socioeconomic majority decides hardforks  Wink
 Cheesy
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.
Definitely not. Miners do not decide hardforks, much less vote on them.

so much for "Luke is focused on fulfilling the promise"  Cheesy
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.

Miners do not decide hardforks; the socioeconomic majority decides hardforks.

No agreement may change this arrangement, no matter how much beer and dim sum are consumed in the process of its creation.

For details, see the first page of this thread:


legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.
Definitely not. Miners do not decide hardforks, much less vote on them.

so much for "Luke is focused on fulfilling the promise"  Cheesy
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 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.
legendary
Activity: 2576
Merit: 1186
All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.
Definitely not. Miners do not decide hardforks, much less vote on them.

so much for "Luke is focused on fulfilling the promise"  Cheesy
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.
legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.
Definitely not. Miners do not decide hardforks, much less vote on them.

so much for "Luke is focused on fulfilling the promise"  Cheesy
legendary
Activity: 2576
Merit: 1186
All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.
Definitely not. Miners do not decide hardforks, much less vote on them.
legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
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.

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.

"Luke is focused on fulfilling the promise"

well thats good to know, I wonder if all the core devs will at least agree to allow this HF code in so that miners can at least TRY and get the 2MB HF activated.

frankly i do not care that a few devs think that 1MB should not get bumped up, and i dont want to reason with them. there are many devs that think upping the limit is OK, there have been a few studies done, the most conservative of which concludes 4MB wouldn't have much effect on node decentralization and there have been many optimizations that gr8ly reduce the centralizing effect of bigger blocks (like thin blocks). We do not need support from ALL the devs, what we need is a huge amount of hashing power.

All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
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.

No mention of segwit's effective blocksize/tps increase?  Not sure if honest oversight or intentional deception....

Sorry you couldn't cope with the unbearable economic reality of cosmic background spam and $0.05 tx fees for using (the premiere) Magic Internet Money.

Actually it's a relief to read this, as it signals a bullish capitulation from the "MOAR RIGHT NAO BECAUSE FREE TX4EVA" side of the debate.

Granted Cryddit is a crypto Greybeard and I'm just a smart-ass troll (albeit one who likewise watched "Digicash, Ecash, E-gold, Beenz, etc..." come and go) but none of Bitcoin's antecedents came close to providing the revelatory, world-changing potential I saw when first reading Satoshi's Holy Whitepaper.

I still feel the same inspiration, and my optimism is trending higher than ever thanks to the antifragility demonstrated by Bitcoin's successful resistance to the Gavinista governance coup (and implied contentious hard fork).

My greatest regret in this matter is not buying some collectible Golden Age BTC from Cryddit (a suspected Satoshi associate/member) when I still had the chance.   Cry

In both of our cases, Bitcoin is once again the Devil's way of teaching economics to nerds.   Tongue
legendary
Activity: 4410
Merit: 4788
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.

making "users" put their coins into 'layer 2 solutions' will ruin any encouragement for increasing the decentralized nodes total.
think logically.. if your coins are locked into LN, using hubs.. why would you care about preserving bitcoins onchain ledger. because you would literally never use it practically as its just a behind the scenes thing to the user of 'layer 2 solutions'..
even sidechains.. if you threw all your coins over to an "elements" altcoin why would you want to preserve bitcoins blockchain..
even pruned, no witness mode is not actuall a 'full node' so does not help at all with the decentralized nodes total

the solution is not to dilute the population of decentralized nodes by moving people away from bitcoin full nodes, but to show the practical information
EG
the full roadmap features when finally all inplemented in mid 2017 would be a 5.7mb block of a potential 7600tx
or
just sticking to traditional transactions and raising the blocksize limit(capacity increase), along with linear signatures (checking speed increase)
1mb= ~2500tx
2mb= ~5000tx
4mb= ~10,000tx

and logically state that if both core and miners think that the REAL 5.7mb roaddmap result is ok for 7,600tx.. then 4mb (less data bloat) for 10,000tx (more capacity potential) is the logical win..

but i will presume that the blockstream believers will now use insults and lack of stats to try to say the opposite.
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
So...  I'm out.  And I'm pretty sure I'm not the only one.

How'd you cash out your swag?

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

Those tuition funds are probably going to be wasted on a free thinker like you, imho. Do some MOOCs or other on-line learning about topics that genuinely interest you (e.g. like network scaling of distributed systems using spontaneous emergence exhibit by embedded small rule sets of crowds following aligned incentives).  Cheesy
full member
Activity: 126
Merit: 100
You don't bother change bitcoin protocol because its impossible, especially for marketing or political reasons.

legendary
Activity: 994
Merit: 1035
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.

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.
legendary
Activity: 1260
Merit: 1116
So...  I'm out.  And I'm pretty sure I'm not the only one.

How'd you cash out your swag?

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

Tuition fees are too damn high. Embarrassed
legendary
Activity: 924
Merit: 1132
So...  I'm out.  And I'm pretty sure I'm not the only one.

How'd you cash out your swag?

House repairs, and three years tuition set aside for a Ph.D program.
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
So...  I'm out.  And I'm pretty sure I'm not the only one.

How'd you cash out your swag?

Started a "blockchain" company called 'Credits' ? ... and issued an ICO?
legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
@gmaxwell

will you comply with Antpool's demands and include the 2MB HF code into the next release?


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.

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.

I thought gmaxwell was one of the main driving forces behind core.

you're right i should reword my question.

@gmaxwell

will you personally oppose Antpool's demands and include the 2MB HF code into the next release?
do you believe core will put yield to Antpool's demands?
Pages:
Jump to: