ToominCoin aka "Bitcoin_Classic" #R3KT

[JayJuanGee]

Can't we see what Luke Jr. releases first?

  I doubt that Luke Jr. is going to include hardfork language in the coding unless it appears that there is consensus for such... I thought that Luke Jr. already pretty much said that a hardfork would not be necessary in order to implement a 2 mg increase in the blocksize limit, so long as there is consensus for such protocol changes?  And, even right now, there doesn't even seem to be any kind of consensus that an increase in the blocksize is actually needed prior to seg wit going live for some time.

luke JR was explaining that segwit has changed the parameter. there is no longer a MAX_BLOCK_SIZE variable in segwit
(well its there just renamed)

instead segwit is set as MAX_BLOCK_SERIALIZED_SIZE = 4000000 (all data tx and signatures)
but to not break consensus and cause a hard fork, segwit works by separating the tx and witness
this is done by
MAX_BLOCK_BASE_SIZE = 1000000
meaning traditional transactions(full tx of nonsegwit) and the non-witness(tx part of segwit) fits into MAX_BLOCK_BASE_SIZE
leaving 3mb spare for the signature area.

in short/layman MAX_BLOCK_BASE_SIZE is the same as MAX_BLOCK_SIZE

now to increase the capacity for traditional transactions is to increase the MAX_BLOCK_BASE_SIZE to 2000000
this will however need consensus because it is a hardfork(basically its the same as other imps increasing MAX_BLOCK_SIZE to 2000000)

for luke to forfil his agreement as a *cough*"independent core contributor"*cough* he has to release code for the MAX_BLOCK_BASE_SIZE=2000000
currently this (MAX_BLOCK_BASE_SIZE=1000000(1mb hard block))
https://github.com/bitcoin/bitcoin/commit/395521854efd5804433d57aaf69f46676e4b6efc
needs to change

Likely I will need to accept your representations regarding some to of these technicalities, but still my point stands that we would need to see the code that is released before your earlier propositions would even come into play. 

Accordingly, none of the individual developers can bind core, but yeah, they are free to make various code proposals, and whether consensus can be achieved regarding code language may suggest what reasonable next steps would be taken.  Even the author of a code could chose to amend his code if others suggest that there are problems with the code, so suggesting that Luke Jr would be insisting upon either a hard fork or an alt coin spin, seems to be considerably premature.

In fact, developers may have fairly intense disagreements regarding what are the problems, if there are problems and the importance of various proposed solutions, so even if one developer takes a fairly strong position concerning what he perceives to be a problem, he may also change his mind regarding the degree or extent of the problem and whether the proposed solution is a reasonable measure in respect to the problem.

So, it makes little sense to me, to attempt to lock in positions, and even describe hostilities and combativeness between developers when the assessments about problems and solutions are works in progress, and code proposition (by Luke Jr.) has not even been released yet.  He could also release his code with a lot of passion and advocacy for such code or he could release it without taking a strong stance in regards to his beliefs regarding the code as a one size fits all solution.

[franky1]

Can't we see what Luke Jr. releases first?

  I doubt that Luke Jr. is going to include hardfork language in the coding unless it appears that there is consensus for such... I thought that Luke Jr. already pretty much said that a hardfork would not be necessary in order to implement a 2 mg increase in the blocksize limit, so long as there is consensus for such protocol changes?  And, even right now, there doesn't even seem to be any kind of consensus that an increase in the blocksize is actually needed prior to seg wit going live for some time.

luke JR was explaining that segwit has changed the parameter. there is no longer a MAX_BLOCK_SIZE variable in segwit
(well its there just renamed)

instead segwit is set as MAX_BLOCK_SERIALIZED_SIZE = 4000000 (all data tx and signatures)
but to not break consensus and cause a hard fork, segwit works by separating the tx and witness
this is done by
MAX_BLOCK_BASE_SIZE = 1000000
meaning traditional transactions(full tx of nonsegwit) and the non-witness(tx part of segwit) fits into MAX_BLOCK_BASE_SIZE
leaving 3mb spare for the signature area.

in short/layman MAX_BLOCK_BASE_SIZE is the same as MAX_BLOCK_SIZE

now to increase the capacity for traditional transactions is to increase the MAX_BLOCK_BASE_SIZE to 2000000
this will however need consensus because it is a hardfork(basically its the same as other imps increasing MAX_BLOCK_SIZE to 2000000)

for luke to forfil his agreement as a *cough*"independent core contributor"*cough* he has to release code for the MAX_BLOCK_BASE_SIZE=2000000
currently this (MAX_BLOCK_BASE_SIZE=1000000(1mb hard block))
https://github.com/bitcoin/bitcoin/commit/395521854efd5804433d57aaf69f46676e4b6efc
needs to change

Likely I will need to accept your representations regarding some to of these technicalities, but still my point stands that we would need to see the code that is released before your earlier propositions would even come into play.  

Accordingly, none of the individual developers can bind core, but yeah, they are free to make various code proposals, and whether consensus can be achieved regarding code language may suggest what reasonable next steps would be taken.  Even the author of a code could chose to amend his code if others suggest that there are problems with the code, so suggesting that Luke Jr would be insisting upon either a hard fork or an alt coin spin, seems to be considerably premature.

In fact, developers may have fairly intense disagreements regarding what are the problems, if there are problems and the importance of various proposed solutions, so even if one developer takes a fairly strong position concerning what he perceives to be a problem, he may also change his mind regarding the degree or extent of the problem and whether the proposed solution is a reasonable measure in respect to the problem.

So, it makes little sense to me, to attempt to lock in positions, and even describe hostilities and combativeness between developers when the assessments about problems and solutions are works in progress, and code proposition (by Luke Jr.) has not even been released yet.  He could also release his code with a lot of passion and advocacy for such code or he could release it without taking a strong stance in regards to his beliefs regarding the code as a one size fits all solution.

well the code changes are simple. but the ultimate "idea" is that its not going to be a bitcoin-core release. but code on luke Jr's personal github.
literally making it an independent non-core release just like BU, XT, classic and the several other non-core implementations.

so the overall decision is, accept the harkfork because luke is more trusted "independent" coder.. or.. vilify luke the same way as the other non-core implementations

[Thatstinks]

Is it true the Chinese are launching Toomincoin?

[JayJuanGee]

Can't we see what Luke Jr. releases first?

  I doubt that Luke Jr. is going to include hardfork language in the coding unless it appears that there is consensus for such... I thought that Luke Jr. already pretty much said that a hardfork would not be necessary in order to implement a 2 mg increase in the blocksize limit, so long as there is consensus for such protocol changes?  And, even right now, there doesn't even seem to be any kind of consensus that an increase in the blocksize is actually needed prior to seg wit going live for some time.

luke JR was explaining that segwit has changed the parameter. there is no longer a MAX_BLOCK_SIZE variable in segwit
(well its there just renamed)

instead segwit is set as MAX_BLOCK_SERIALIZED_SIZE = 4000000 (all data tx and signatures)
but to not break consensus and cause a hard fork, segwit works by separating the tx and witness
this is done by
MAX_BLOCK_BASE_SIZE = 1000000
meaning traditional transactions(full tx of nonsegwit) and the non-witness(tx part of segwit) fits into MAX_BLOCK_BASE_SIZE
leaving 3mb spare for the signature area.

in short/layman MAX_BLOCK_BASE_SIZE is the same as MAX_BLOCK_SIZE

now to increase the capacity for traditional transactions is to increase the MAX_BLOCK_BASE_SIZE to 2000000
this will however need consensus because it is a hardfork(basically its the same as other imps increasing MAX_BLOCK_SIZE to 2000000)

for luke to forfil his agreement as a *cough*"independent core contributor"*cough* he has to release code for the MAX_BLOCK_BASE_SIZE=2000000
currently this (MAX_BLOCK_BASE_SIZE=1000000(1mb hard block))
https://github.com/bitcoin/bitcoin/commit/395521854efd5804433d57aaf69f46676e4b6efc
needs to change

Likely I will need to accept your representations regarding some to of these technicalities, but still my point stands that we would need to see the code that is released before your earlier propositions would even come into play.  

Accordingly, none of the individual developers can bind core, but yeah, they are free to make various code proposals, and whether consensus can be achieved regarding code language may suggest what reasonable next steps would be taken.  Even the author of a code could chose to amend his code if others suggest that there are problems with the code, so suggesting that Luke Jr would be insisting upon either a hard fork or an alt coin spin, seems to be considerably premature.

In fact, developers may have fairly intense disagreements regarding what are the problems, if there are problems and the importance of various proposed solutions, so even if one developer takes a fairly strong position concerning what he perceives to be a problem, he may also change his mind regarding the degree or extent of the problem and whether the proposed solution is a reasonable measure in respect to the problem.

So, it makes little sense to me, to attempt to lock in positions, and even describe hostilities and combativeness between developers when the assessments about problems and solutions are works in progress, and code proposition (by Luke Jr.) has not even been released yet.  He could also release his code with a lot of passion and advocacy for such code or he could release it without taking a strong stance in regards to his beliefs regarding the code as a one size fits all solution.

well the code changes are simple. but the ultimate "idea" is that its not going to be a bitcoin-core release. but code on luke Jr's personal github.
literally making it an independent non-core release just like BU, XT, classic and the several other non-core implementations.

so the overall decision is, accept the harkfork because luke is more trusted "independent" coder.. or.. vilify luke the same way as the other non-core implementations

Still seems premature to me for you to assert that the proposed code language is going to be a hardfork in the way that you describe it.   I will believe it when I see it.   So far, even though you seem to be stretching the speculation in such a way to assume facts that have not happened, yet, you are not really saying anything much different from me.  So, yeah, anyone can make a proposal, and if the proposal is hostile to Core, then maybe Core would be hostile to Luke Jr; however, if the code is merely a proposal, then there may not be any reason to be hostile to him for making a proposal that can be weighed and considered by core.

On the other hand, if Core were to release code, then yeah, it has been vetted by various PTB within core in order to suggest that it is already an endorsed version.  In any event, it seems that you are getting ahead of yourself because we would need to see the extent to which the code is hostile to core and whether the code has any persuasive power in terms of either changing core or causing others to defect from core's code or vision.

[AliceGored]

Can't we see what Luke Jr. releases first?

  I doubt that Luke Jr. is going to include hardfork language in the coding unless it appears that there is consensus for such... I thought that Luke Jr. already pretty much said that a hardfork would not be necessary in order to implement a 2 mg increase in the blocksize limit, so long as there is consensus for such protocol changes?  And, even right now, there doesn't even seem to be any kind of consensus that an increase in the blocksize is actually needed prior to seg wit going live for some time.

luke JR was explaining that segwit has changed the parameter. there is no longer a MAX_BLOCK_SIZE variable in segwit
(well its there just renamed)

instead segwit is set as MAX_BLOCK_SERIALIZED_SIZE = 4000000 (all data tx and signatures)
but to not break consensus and cause a hard fork, segwit works by separating the tx and witness
this is done by
MAX_BLOCK_BASE_SIZE = 1000000
meaning traditional transactions(full tx of nonsegwit) and the non-witness(tx part of segwit) fits into MAX_BLOCK_BASE_SIZE
leaving 3mb spare for the signature area.

in short/layman MAX_BLOCK_BASE_SIZE is the same as MAX_BLOCK_SIZE

now to increase the capacity for traditional transactions is to increase the MAX_BLOCK_BASE_SIZE to 2000000
this will however need consensus because it is a hardfork(basically its the same as other imps increasing MAX_BLOCK_SIZE to 2000000)

for luke to forfil his agreement as a *cough*"independent core contributor"*cough* he has to release code for the MAX_BLOCK_BASE_SIZE=2000000
currently this (MAX_BLOCK_BASE_SIZE=1000000(1mb hard block))
https://github.com/bitcoin/bitcoin/commit/395521854efd5804433d57aaf69f46676e4b6efc
needs to change

Likely I will need to accept your representations regarding some to of these technicalities, but still my point stands that we would need to see the code that is released before your earlier propositions would even come into play.  

Accordingly, none of the individual developers can bind core, but yeah, they are free to make various code proposals, and whether consensus can be achieved regarding code language may suggest what reasonable next steps would be taken.  Even the author of a code could chose to amend his code if others suggest that there are problems with the code, so suggesting that Luke Jr would be insisting upon either a hard fork or an alt coin spin, seems to be considerably premature.

In fact, developers may have fairly intense disagreements regarding what are the problems, if there are problems and the importance of various proposed solutions, so even if one developer takes a fairly strong position concerning what he perceives to be a problem, he may also change his mind regarding the degree or extent of the problem and whether the proposed solution is a reasonable measure in respect to the problem.

So, it makes little sense to me, to attempt to lock in positions, and even describe hostilities and combativeness between developers when the assessments about problems and solutions are works in progress, and code proposition (by Luke Jr.) has not even been released yet.  He could also release his code with a lot of passion and advocacy for such code or he could release it without taking a strong stance in regards to his beliefs regarding the code as a one size fits all solution.

well the code changes are simple. but the ultimate "idea" is that its not going to be a bitcoin-core release. but code on luke Jr's personal github.
literally making it an independent non-core release just like BU, XT, classic and the several other non-core implementations.

so the overall decision is, accept the harkfork because luke is more trusted "independent" coder.. or.. vilify luke the same way as the other non-core implementations

Still seems premature to me for you to assert that the proposed code language is going to be a hardfork in the way that you describe it.   I will believe it when I see it.   So far, even though you seem to be stretching the speculation in such a way to assume facts that have not happened, yet, you are not really saying anything much different from me.  So, yeah, anyone can make a proposal, and if the proposal is hostile to Core, then maybe Core would be hostile to Luke Jr; however, if the code is merely a proposal, then there may not be any reason to be hostile to him for making a proposal that can be weighed and considered by core.

On the other hand, if Core were to release code, then yeah, it has been vetted by various PTB within core in order to suggest that it is already an endorsed version.  In any event, it seems that you are getting ahead of yourself because we would need to see the extent to which the code is hostile to core and whether the code has any persuasive power in terms of either changing core or causing others to defect from core's code or vision.

Besides voluntarily bringing activation to 90%, miners could soft limit themselves to producing <1MB for as long as they wanted... thus bringing about a change, but not a fork, until they felt the economic support had formed.  

[Lauda]

Is it true the Chinese are launching Toomincoin?

No, it is not true. There was a proposal on 8btc (which is not censored at all) by a random person. He announced some "Terminator Plan" which is horribly risky just to gain additional 3 TPS. This post was on r/bitcoin and labeled as FUD for a while but was eventually taken down. The 'people' at r/btc have been basically celebrating, using new idiotic phrases such as Corexit, even though there is zero evidence that any major pool would participate in this. Keep in mind that the comment section on that website can be easily manipulated (as long as you have 1 person to talk Chinese for you).

[AliceGored]

Is it true the Chinese are launching Toomincoin?

No, it is not true. There was a proposal on 8btc (which is not censored at all) by a random person.

Strange way to phrase that, as if the contrary would be a (good) thing. Also, this came a day(?) after that mysterious call for clarity from HaoBTC, a strong supporter of Core, almost as strong a Core supporter as BTCC.

He announced some "Terminator Plan" which is horribly risky just to gain additional 3 TPS.

The HK agreement includes something similar to this “horribly risky” plan, let that sink in.

The idea of the poster’s plan was to bring the 75% activation point to 90%, those in favor of strong consensus should favor such a development.

This post was on r/bitcoin and labeled as FUD for a while but was eventually taken down. The 'people' at r/btc have been basically celebrating, using new idiotic phrases such as Corexit, even though there is zero evidence that any major pool would participate in this.

While I agree this seems to be largely conjecture and a wish-post on 8btc, the lack of any strong formal (or weak informal) denial was deafening. Keep in mind the context of Luke-Jr basically flicking HaoBTC off his shoulder the day prior.

Keep in mind that the comment section on that website can be easily manipulated (as long as you have 1 person to talk Chinese for you).

Unlike here, where staff are paid to remain staunchly objective.

[Lauda]

Strange way to phrase that, as if the contrary would be a (good) thing.

I definitely do not think that this rash plan would be good.

Also, this came a day(?) after that mysterious call for clarity from HaoBTC, a strong supporter of Core, almost as strong a Core supporter as BTCC.

People tend to use these things for manipulation. Nothing surprising.

The HK agreement includes something similar to this “horribly risky” plan, let that sink in. The idea of the poster’s plan was to bring the 75% activation point to 90%, those in favor of strong consensus should favor such a development.

I doubt that. The HF proposal would most likely have a high activation threshold and long grace period, making it much safer.

While I agree this seems to be largely conjecture and a wish-post on 8btc, the lack of any strong formal (or weak informal) denial was deafening. Keep in mind the context of Luke-Jr basically flicking HaoBTC off his shoulder the day prior.

People were too quick to draw to conclusions even though there have been practically no statements from any major pools so far.

Unlike here, where staff are paid to remain staunchly objective.

The views and opinions of that individuals is in no way related to their staff contributions.

[smoothie]

icebreaker and gmaxwell is knee deep in monero.

funny think is monero has the ability of larger blocksize.

can anyone see the hypocrisy

the 2 main people crying out non-core implementations are altcoins (yet classic, xt, bu, bitcoinj, etc all only relay and handle bitcoin data) are the 2 guys that are hoarders of altcoins and that altcoin has the ability of bigger blocks..

How is it hypocrisy if they believe different solutions regarding block size should be associated with a particular project?

Just curious

read the last 120 pages of them crying that hardforks, big blocks, altcoins and anything else not blockstream is bad..

That isn't much proof.

Got any quotes that backup your statement in bold?

[marcus_of_augustus]

Is it just a coincidence that the sold-out bulls of the big block camp are getting more toxic and shrill the higher the price goes?

Must be sour those grapes huh guys?

Can't imagine what Mike Hearn was thinking dumping and trashing on Bitcoin in NY Times with loudmouth bitcoin trash-talker Nathaniel Popper at $450 ... he's looking like the stupid twit he is now. What did he say? "I can only see price declining from here"? What prize wankers those guys turned out to be.

[hdbuck]

lmao, quoting this dipshit for posterity. or say one month heh.

ffs hopeless squeaking prick. fuck you.

ok then.. lets get an answer from you
luke JR is going to release some code.. but it wont be core code, but independant. just so that he can forfil his agreement.

will you
A) accept luke Jrs implementation as something "bitcoin" even if it has the hardfork
b) do a REKT campaign saying luke Jr released an altcoin, the same way as you lot said gavin and hearne did..

come on open your mouth and show your opinion.. A or B
go on. just answer A or B

.

Fuck the agreement.

[JayJuanGee]

Is it just a coincidence that the sold-out bulls of the big block camp are getting more toxic and shrill the higher the price goes?

Must be sour those grapes huh guys?

Can't imagine what Mike Hearn was thinking dumping and trashing on Bitcoin in NY Times with loudmouth bitcoin trash-talker Nathaniel Popper at $450 ... he's looking like the stupid twit he is now. What did he say? "I can only see price declining from here"? What prize wankers those guys turned out to be.

Yep, and some of them likely sold a fairly large percentage of their BTC stash (and maybe even really stupidly believing that there is some kind of major technical flaw in bitcoin), and waiting and waiting and waiting for a major correction in order that they can buy back in.... ... and maybe even feeling a bit stupid, because it really does not seem like their conjectured "major correction" is going to take place... and probably don't feel too good buying back at higher prices (shit $450 seemed high, at the time)... so they continue to complain and hope, for what seems quite unlikely.

[BlindMayorBitcorn]

Beyond a leadership vacuum, Bitcoin’s “leadership” is less clear and toxic. Greg Maxwell, technical leader of Blockstream which employs a solid chunk of core developers, recently referred to other core developers who were working with miners on a block size compromise as “well meaning dips***s.”

 

What? you don't read this thread? (the comment he was referring to was a few pages back)-- I guess it's interesting to know that Coinbase's executives are reading this thread.

More deceptive garbage-- in particular, it makes it sound like I wasn't referring to my own freeking employees there, or that my flip comment had something to do with working with miners on compromise when instead I explicitly pointed out it was because they went off to hold a secret meeting and let themselves get coerced (literally locked in a room until 3-4am) into an agreement which-- in the sense it was understood-- was physically impossible for them to comply with (because none of them have the authority to control what core releases or what the network runs)... and they did so after explicitly promising other people-- concerned about the ethics of meeting in secret to collude with miners-- that they go only to learn and share information and not make agreements. I don't feel any hesitation in calling that a foolish move. (and not just in hindsight, I warned about this kind of outcome in advance)

But while we're on the subject of foolish moves, whats the deal with coinbase continually insulting bitcoin technology and antagonizing the people whom are actually working on it?  They contribute _NOTHING_ to the technology, they don't even contribute to maintaining their beloved "classic".  I guess they might be happier with Ethereum, since it's a far more centralized system they'll know exactly who to lobby to get whatever they want without putting in any effort themselves...  But, considering that Coblee was bragging months ago about how much Ethereum people at coinbase were buying, I think the main attraction is something Bitcoin couldn't match: the ability to use their company to pump an asset they could all buy personally on the cheap-- it's much harder to do that for a system which is mature and less based on speculation.

You must have some thick skin to weather this kind of negative media attention. I've met Vitalik. If/when this kind of shit hits his fan, I'm afraid he'll cry for days. Did you hear about the Wiki editor who had a nervous breakdown? Ya, don't do that.

That was some fast comeuppance. Poor kid.

[iCEBREAKER]

@Carlton Banks
I don't think that bitcoin is for the rich now... but some are pushing on this way buy doing wrong short term choices, to please their investors.

Other clients (unlimited, xt and classic) are working on solutions to scale "on-chain", they are doing it because it is possible and they haven't any conflict of interest on giving these kind of solutions.

HostFat managed to be so wrong about so much, in this hilariously not-aging-well assertion of his favorite controversial hard forks' superiority.

Unlimited, XT, and Classic are abandonware now, while BAB and BSV are notorious for their conflicts of interest created by the very rich people known as Roger Veer, Jihan Woo, and Calvin Airhead.

[Carlton Banks]

HostFat managed to be so wrong about so much, in this hilariously not-aging-well assertion of his favorite controversial hard forks' superiority.

Unlimited, XT, and Classic are abandonware now, while BAB and BSV are notorious for their conflicts of interest created by the very rich people known as Roger Veer, Jihan Woo, and Calvin Airhead.

Even funnier: what's the latest tech addition to Bitcoin Cash in their May fork?

Lightning.


And whose (unfinished) work did they copy & paste to make Lightning possible on Bitcoin Cash? Bitcoin Core's Schnorr sigs spec.  

[iCEBREAKER]

Even funnier: what's the latest tech addition to Bitcoin Cash in their May fork?

Lightning.


And whose (unfinished) work did they copy & paste to make Lightning possible on Bitcoin Cash? Bitcoin Core's Schnorr sigs spec.  

How is this possible?  No Lightning without a malleability fix.  Will Bcash-BAB bend the knee to segwit?

[Carlton Banks]

How is this possible?  No Lightning without a malleability fix.  

Schnorr sigs are inherently non-malleable, or at least sigs using the schnorr implementation that Bitcoin Core devs designed (and Bitcoin Cash devs copy-pasted) are

In other news, Toomin is apparently thrashing around trying to get a tiny percentage improvement in block propagation over BIP152 compact blocks (now ~2 year old tech). Such innovate.

[hv_]

LN is so useless, same as SW and all the other dev- tries to inject any of their experimental tech will.

Stable, simple and legal impl of the white paper will win all markets.

I can only see BSV being the true and acceptable Bitcoin.

[DooMAD]

Stable, simple and legal impl of the white paper will win all markets.

I can only see BSV being the true and acceptable Bitcoin.

On what possible basis?  BSV has ~650 nodes.  LN has ~6500 nodes.  It's pretty clear which one the market prefers.

[hv_]

Stable, simple and legal impl of the white paper will win all markets.

I can only see BSV being the true and acceptable Bitcoin.

On what possible basis?  BSV has ~650 nodes.  LN has ~6500 nodes.  It's pretty clear which one the market prefers.

Economic incentives , usability and security level will decide that.