Topic: Big block support observer - page 2. (Read 6677 times)
Final warning to people who want to debate here. I made this very clear in the OP: This thread is NOT for big block debate, including the discussion of pros and cons of different proposals and implementations.
What good is Coinify's support for XT?
Aren't they a day late and a dollar short?
What difference, at this point, does it make?
Shameful? More like hilarious! It was a brilliant marketing exercise, using XT's social engineering attacks to bring in suckers to help mine some blocks.
Nothing hilarious in making a move like this. Supporting a specific client and/or BIP should be something done, not simply thought out. Slush apparently only thought out and didn't really act. He didn't support his beliefs with an act. He should have simply change the client on the big block support port.
Decisions like these in Bitcoin should be weighed in. It's the future of the whole system and economy we're deciding.
You expected an established pool to just suddenly drop untested shite like XT into their production environment,
Yes, I did. What makes the spoofed client more reliable than the client that supports big blocks? What makes the client that supports big blocks less reliable than the spoofed client or the reference client? I'm talking stability-wise only, of course.
just to appease some cranky insignificant Gavinista malcontent splinter group?
This has nothing to do with a single entity in my opinion. So I seriously don't know what to say about the "cranky insignificant Gavinista malcontent splinter group"
But hey, at least your not among the dead-enders bitterly clinging to the idea that Slush wasn't spoofing, Because Intentions And Stuff.
The way to hell is paved with good intentions.
Shameful that Slush isn't really running a client that supports big blocks. Wasn't expecting this from them. They publicised their pool as big Block supporting and gave miners a tutorial to join them in the big Block pool, but end up spoofing 
Shameful? More like hilarious! It was a brilliant marketing exercise, using XT's social engineering attacks to bring in suckers to help mine some blocks.
You expected an established pool to just suddenly drop untested shite like XT into their production environment, just to appease some cranky insignificant Gavinista malcontent splinter group?
LOL, tell us another one!
But hey, at least you're not among the dead-enders bitterly clinging to the idea that Slush wasn't spoofing, Because Intentions And Stuff.
Shameful that Slush isn't really running a client that supports big blocks. Wasn't expecting this from them. They publicised their pool as big Block supporting and gave miners a tutorial to join them in the big Block pool, but end up spoofing
I wonder how many pools REALLY support big blocks and if any block has been mined with a client that has not been spoofed. Giving the idea that you support something isn't really the same as supporting it.
That known website that tracks blocks also seem to have stopped differentiating spoofed from real nodes. Anyways, I certainly know what nodes I'm running.
I wonder how many pools REALLY support big blocks and if any block has been mined with a client that has not been spoofed. Giving the idea that you support something isn't really the same as supporting it.
That known website that tracks blocks also seem to have stopped differentiating spoofed from real nodes. Anyways, I certainly know what nodes I'm running.
XT has 0.1% of the network. Rounded to the nearest whole number, that equals zero support.
Also, that singular "XT" block was mined with a spoofed version string, not by an actual XT node.
So in reality, XT support is stuck at absolute zero.
Also, that singular "XT" block was mined with a spoofed version string, not by an actual XT node.
So in reality, XT support is stuck at absolute zero.
Jeff Garzik finally made a proper BIP draft and it is up online now at https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki. This file actually specifies the method for deployment and method for changing the block size limit. It also seems to have included some other changes that people have suggested.
Those are "BIP101 blocks", not "XT blocks". BIP101 won't be active until January 2016 so it makes no difference at this moment.
The only "XT" blocks mined thus far are actually from a spoofed XT node.
Spoofed nodes will inevitably lure XT into a death trap from which there is no escape. Cite: http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html
All the Gavinistas have done is helped Slush's pool by rewarding its cheap marketing theatrics.
% RealXT blocks: 0
% FakeXT blocks: 100
% #R3KT Hearn: >9000
The only "XT" blocks mined thus far are actually from a spoofed XT node.
Spoofed nodes will inevitably lure XT into a death trap from which there is no escape. Cite: http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html
All the Gavinistas have done is helped Slush's pool by rewarding its cheap marketing theatrics.
Quote
Quote
% RealXT blocks: 0
% FakeXT blocks: 100
% #R3KT Hearn: >9000
The only "XT" blocks mined thus far are actually from a spoofed XT node.
Spoofed nodes will inevitably lure XT into a death trap from which there is no escape. Cite: http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html
All the Gavinistas have done is helped Slush's pool by rewarding its cheap marketing theatrics.
Quote
Quote
% RealXT blocks: 0
% FakeXT blocks: 100
% #R3KT Hearn: >9000
Now Breadwallet supports BIP101
https://www.reddit.com/r/bitcoinxt/comments/3iwdan/aaron_voisine_of_breadwallet_voices_support_of/
https://www.reddit.com/r/bitcoinxt/comments/3iwdan/aaron_voisine_of_breadwallet_voices_support_of/
Does it mean that Gregory Maxwell can unilaterally reject a proposal to assign any BIP no. ?
He cannot unilaterally reject a proposal. It is not in his power to judge a BIP, only to determine if it is sound and complete. See this section of BIP 001: https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki#BIP_Editor_Responsibilities__Workflow 
BIP100 by Jeff: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
BIP101 by Gavin: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files
BIP??? by Pieter (called "BIP103" below): https://gist.github.com/sipa/c65665fc360ca7a176a6
This one needs to be added to the list in my opinion - https://bitcointalksearch.org/topic/bip-106-dynamically-controlled-bitcoin-block-size-max-cap-1154536BIP101 by Gavin: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files
BIP??? by Pieter (called "BIP103" below): https://gist.github.com/sipa/c65665fc360ca7a176a6
There are hundreds if not thousands of proposals like this. They won't be included unless a BIP number is assigned, or I believe it's very likely to be assigned.
Does BIP number get assigned only to core dev's proposals ?
That proposal is still being discussed on the mailing list. I don't know if he has submitted it to gmaxwell yet.
Does it mean that Gregory Maxwell can unilaterally reject a proposal to assign any BIP no. ?
Bitfury now supporting Bip 100.
Proof ?
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
Bitfury now supporting Bip 100.
BIP100 by Jeff: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
BIP101 by Gavin: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files
BIP??? by Pieter (called "BIP103" below): https://gist.github.com/sipa/c65665fc360ca7a176a6
This one needs to be added to the list in my opinion - https://bitcointalksearch.org/topic/bip-106-dynamically-controlled-bitcoin-block-size-max-cap-1154536BIP101 by Gavin: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files
BIP??? by Pieter (called "BIP103" below): https://gist.github.com/sipa/c65665fc360ca7a176a6
There are hundreds if not thousands of proposals like this. They won't be included unless a BIP number is assigned, or I believe it's very likely to be assigned.
Does BIP number get assigned only to core dev's proposals ?
That proposal is still being discussed on the mailing list. I don't know if he has submitted it to gmaxwell yet.
BIP100 by Jeff: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
BIP101 by Gavin: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files
BIP??? by Pieter (called "BIP103" below): https://gist.github.com/sipa/c65665fc360ca7a176a6
This one needs to be added to the list in my opinion - https://bitcointalksearch.org/topic/bip-106-dynamically-controlled-bitcoin-block-size-max-cap-1154536BIP101 by Gavin: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files
BIP??? by Pieter (called "BIP103" below): https://gist.github.com/sipa/c65665fc360ca7a176a6
There are hundreds if not thousands of proposals like this. They won't be included unless a BIP number is assigned, or I believe it's very likely to be assigned.
Does BIP number get assigned only to core dev's proposals ?
It has become obvious that the node count is a pretty useless piece of information in this debate (due to the easiness of manipulation).
OP you need to update your thread on a few points:
BIP 100 support:
DiscusFish / F2Pool
Kano CKPool
BitClub Network
OP you need to update your thread on a few points:
BIP 100 support:
DiscusFish / F2Pool
Kano CKPool
BitClub Network
Thanks and updated. Will make it tidier later
It has become obvious that the node count is a pretty useless piece of information in this debate (due to the easiness of manipulation).
OP you need to update your thread on a few points:
BIP 100 support:
DiscusFish / F2Pool
Kano CKPool
BitClub Network
OP you need to update your thread on a few points:
BIP 100 support:
DiscusFish / F2Pool
Kano CKPool
BitClub Network
Jump to: