Highly agree with OP, some *not* sane people seem to go with anything else than core, any horse-shit that comes along. theymos has even made a page so that its understood: https://bitcointalk.org/dec/p1.html
It comes up whenever forum ads aren't shown
Topic: Bitcoin Classic = a bunch of idiots running the full node (Read 2291 times)
maybe Core will add 2 MB and end this mess? that would be a cool story 
2MB + SegWit + LN etc would be great.
2MB + SegWit + LN etc would be great.
I think Core should add 2MB earlier than Classic then test the SegWit and give miner and service providers to update to the SegWit.
Yes this will happen. I'm looking forward 2MB and SegWit
seems redundant, because it would be like having 3.6 mega of space, 2mb will suffice, so segwit is enough for the time being
maybe Core will add 2 MB and end this mess? that would be a cool story
2MB + SegWit + LN etc would be great.
2MB + SegWit + LN etc would be great.
I think Core should add 2MB earlier than Classic then test the SegWit and give miner and service providers to update to the SegWit.
Yes this will happen. I'm looking forward 2MB and SegWit
maybe Core will add 2 MB and end this mess? that would be a cool story
2MB + SegWit + LN etc would be great.
2MB + SegWit + LN etc would be great.
I think Core should add 2MB earlier than Classic then test the SegWit and give miner and service providers to update to the SegWit.
All you clasSick posters here on bitcointalk are really kind of like a rat infestation - Hard to control but do-able.
Like a cancer. A chemo can sometimes help, but still fatal.
Oh noes, wallet providers might force us to use cheaper transactions !!!
:D:DYour been deceived by Bitcoin Core, the transactions have the same size in bytes stored on blockchain for full nodes, so Segregated Withness transactions might be cheaper only because Bitcoin Core says lets not count the signature size part for fee calculation for Segregated Withness transactions, but the signature size part using the same bandwich and storage capacity of full nodes in both cases.
Its basically political decision policy to make Segregated Withness transactions more popular with miners paying the cost with reduced fees for these Segregated Withness transactions yet they have to use the same bandwich and storage capacity requirements compared to today transactions.
I wish I could return to my young times when I was clueless too though, the life was much easier back then!
All you clasSick posters here on bitcointalk are really kind of like a rat infestation - Hard to control but do-able.
Oh noes, wallet providers might force us to use cheaper transactions !!!
:D:DYour been deceived by Bitcoin Core, the transactions have the same size in bytes stored on blockchain for full nodes, so Segregated Withness transactions might be cheaper only because Bitcoin Core says lets not count the signature size part for fee calculation for Segregated Withness transactions, but the signature size part using the same bandwich and storage capacity of full nodes in both cases.
Its basically political decision policy to make Segregated Withness transactions more popular with miners paying the cost with reduced fees for these Segregated Withness transactions yet they have to use the same bandwich and storage capacity requirements compared to today transactions.
I wish I could return to my young times when I was clueless too though, the life was much easier back then!
Oh noes, wallet providers might force us to use cheaper transactions !!!
:D:D My maybe like 1.33-1.5MB is based I dont believe SegWit transactions will be used much in first year, unless ofcourse new wallet clients forces us to use only SegWit transactions...
Oh noes, wallet providers might force us to use cheaper transactions !!!
Ok, when your so knowledgable write one two technical facts Im wrong with explanation worth a programmer instead of your general "your talking nonsense".
My maybe like 1.33-1.5MB is based I dont believe SegWit transactions will be used much in first year, unless ofcourse new wallet clients forces us to use only SegWit transactions...
I've posted an actual link to the calculations that show what kind of increase we should be expecting.My maybe like 1.33-1.5MB is based I dont believe SegWit transactions will be used much in first year, unless ofcourse new wallet clients forces us to use only SegWit transactions...
BTW "It depends on how many people are using updated clients" and whether it will be possible to use normal today transactions in updated clients as well (and what kind of transactions will be choossen to user by default).
New clients can send transactions to old ones and old ones can send transactions to new ones. It is just that transacting between new clients becomes more efficient. 
Seeing staff member doing ad homiem attacks is pretty disgusting, so I checked your post history and you had hard time understanding SegWit at first, and based on your comments I doubt you understand SegWit at all even now, and definitively your not a programmer so I dont understand how you can even comment my summary when you have so little knowledge on the topic.
So stating the fact that you're talking nonsense equals to 'ad hominem'? Please don't attempt to use logical fallacies when you are unable to use them correctly. I have not attacked you. I understand SegWit probably better than the majority here. I do wonder though where you came up with the false conclusion that I'm not a programmer? Just to teach you a bit, if SegWit is implemented, the effective total blocksize depends how much people will be using special SegWit transactions instead of the normal ones. I dont expect within a year there will be more SegWit transactions than the normal ones, making the limit maybe like 1.33-1.5 MB at the end of the first year. Unless off course Bitcoin Core forces us to use just SegWig tansactions instead of possibility to choose normal ones, which would not surprise me given how the RBF features cant be turned off in Core 0.12.
And it is crappy workaround because it is much more complicated solution, which leads in my experience to more likely bugs and future increased development time because of the more complex code.
It depends on how many people are using updated clients. Also the increase will not be 'maybe like 1.33-1.5MB' at the end of the first year. This is speculating and not based on calculations. The actual calculations can be found here. People are very hyperbolic when it comes to the complexity of SegWit. And it is crappy workaround because it is much more complicated solution, which leads in my experience to more likely bugs and future increased development time because of the more complex code.
If you had real knowledge on the matter you would:
1) Stop talking nonsense.
2) Realize the pros and cons of a hard fork in comparison to a Soft work.
3) Stop complaining that SegWit is a 'crappy workaround', when it fact it is not.
1) Stop talking nonsense.
2) Realize the pros and cons of a hard fork in comparison to a Soft work.
3) Stop complaining that SegWit is a 'crappy workaround', when it fact it is not.
Ok, when your so knowledgable write one two technical facts Im wrong with explanation worth a programmer instead of your general "your talking nonsense".
My maybe like 1.33-1.5MB is based I dont believe SegWit transactions will be used much in first year, unless ofcourse new wallet clients forces us to use only SegWit transactions...
BTW "It depends on how many people are using updated clients" and whether it will be possible to use normal today transactions in updated clients as well (and what kind of transactions will be choossen to user by default).
Seeing staff member doing ad homiem attacks is pretty disgusting, so I checked your post history and you had hard time understanding SegWit at first, and based on your comments I doubt you understand SegWit at all even now, and definitively your not a programmer so I dont understand how you can even comment my summary when you have so little knowledge on the topic.
So stating the fact that you're talking nonsense equals to 'ad hominem'? Please don't attempt to use logical fallacies when you are unable to use them correctly. I have not attacked you. I understand SegWit probably better than the majority here. I do wonder though where you came up with the false conclusion that I'm not a programmer? Just to teach you a bit, if SegWit is implemented, the effective total blocksize depends how much people will be using special SegWit transactions instead of the normal ones. I dont expect within a year there will be more SegWit transactions than the normal ones, making the limit maybe like 1.33-1.5 MB at the end of the first year. Unless off course Bitcoin Core forces us to use just SegWig tansactions instead of possibility to choose normal ones, which would not surprise me given how the RBF features cant be turned off in Core 0.12.
And it is crappy workaround because it is much more complicated solution, which leads in my experience to more likely bugs and future increased development time because of the more complex code.
It depends on how many people are using updated clients. Also the increase will not be 'maybe like 1.33-1.5MB' at the end of the first year. This is speculating and not based on calculations. The actual calculations can be found here. People are very hyperbolic when it comes to the complexity of SegWit. And it is crappy workaround because it is much more complicated solution, which leads in my experience to more likely bugs and future increased development time because of the more complex code.
Just to teach you a bit, if SegWit is implemented, the effective total blocksize depends how much people will be using special SegWit transactions instead of the normal ones. I dont expect within a year there will be more SegWit transactions than the normal ones, making the limit maybe like 1.33-1.5 MB at the end of the first year. Unless off course Bitcoin Core forces us to use just SegWig tansactions instead of possibility to choose normal ones, which would not surprise me given how the RBF features cant be turned off in Core 0.12.
And it is crappy workaround because it is much more complicated solution, which leads in my experience to more likely bugs and future increased development time because of the more complex code.
And it is crappy workaround because it is much more complicated solution, which leads in my experience to more likely bugs and future increased development time because of the more complex code.
You're talking out of your ass.
Return to your masters and have him review your homework.
You get a -F
For your usual troll work, you get A for trolling. Congrat.
Just to teach you a bit, if SegWit is implemented, the effective total blocksize depends how much people will be using special SegWit transactions instead of the normal ones. I dont expect within a year there will be more SegWit transactions than the normal ones, making the limit maybe like 1.33-1.5 MB at the end of the first year. Unless off course Bitcoin Core forces us to use just SegWig tansactions instead of possibility to choose normal ones, which would not surprise me given how the RBF features cant be turned off in Core 0.12.
And it is crappy workaround because it is much more complicated solution, which leads in my experience to more likely bugs and future increased development time because of the more complex code.
And it is crappy workaround because it is much more complicated solution, which leads in my experience to more likely bugs and future increased development time because of the more complex code.
You're talking out of your ass.
Return to your masters and have him review your homework.
You get a -F
2MB + SegWit + LN etc would be great.
2 MB on its own is not deemed as really safe at the moment. A combination of 2 MB blocks and SegWit would be the same as an effective 4 MB block size which is worse.If the Core developers had common sence they would:
-snip-
If you had real knowledge on the matter you would:-snip-
1) Stop talking nonsense.
2) Realize the pros and cons of a hard fork in comparison to a Soft work.
3) Stop complaining that SegWit is a 'crappy workaround', when it fact it is not.
Seeing staff member doing ad homiem attacks is pretty disgusting, so I checked your post history and you had hard time understanding SegWit at first, and based on your comments I doubt you understand SegWit at all even now, and definitively your not a programmer so I dont understand how you can even comment my summary when you have so little knowledge on the topic.
Just to teach you a bit, if SegWit is implemented, the effective total blocksize depends how much people will be using special SegWit transactions instead of the normal ones. I dont expect within a year there will be more SegWit transactions than the normal ones, making the limit maybe like 1.33-1.5 MB at the end of the first year. Unless off course Bitcoin Core forces us to use just SegWig tansactions instead of possibility to choose normal ones, which would not surprise me given how the RBF features cant be turned off in Core 0.12.
And it is crappy workaround because it is much more complicated solution, which leads in my experience to more likely bugs and future increased development time because of the more complex code.
maybe Core will add 2 MB and end this mess? that would be a cool story
2MB + SegWit + LN etc would be great.
2 MB on its own is not deemed as really safe at the moment. A combination of 2 MB blocks and SegWit would be the same as an effective 4 MB block size which is worse. LN is not related to this and is slowing coming along. 2MB + SegWit + LN etc would be great.
I doubt core would harm bitcoin on purpose, too much at stake for developers.
I concur. 
I agree that 2mb block would silence lots of criticism and probably would be good for community and all that. However, I think that Bitcoin is still working pretty well for now. Just wait a little longer and see what happens. I doubt core would harm bitcoin on purpose, too much at stake for developers.
maybe Core will add 2 MB and end this mess? that would be a cool story
2MB + SegWit + LN etc would be great.
2MB + SegWit + LN etc would be great.
If you had real knowledge on the matter you would:
1) Stop talking nonsense.
2) Realize the pros and cons of a hard fork in comparison to a Soft work.
3) Stop complaining that SegWit is a 'crappy workaround', when it fact it is not.
Well said.
If Bitcoin core implements the 2MB block size within two months, there is no need for bitcoinclassic. But will Core do that?
Of course they won't do that. Why would they? SegWit is planned for April and it brings an adequate (possibly equal or greater to a 2 MB block size) increase. If the Core developers had common sence they would:
-snip-
If you had real knowledge on the matter you would:-snip-
1) Stop talking nonsense.
2) Realize the pros and cons of a hard fork in comparison to a Soft work.
3) Stop complaining that SegWit is a 'crappy workaround', when it fact it is not.
something you need to understand that the bitcoin core is not being changed just because of the biased factor, if bitcoin core just changed into XT one for biased reason, then bitcoin core would not likely be trusted by the users anymore. 
What are you talking about? This made no sense to me. Jump to: