ToominCoin aka "Bitcoin_Classic" #R3KT

[beastmodeBiscuitGravy]

miners are sufficiently smart to recognize that they don't want to be part of a mining poole that acts so recklessly and takes stupid and unjustifiable positions.

You write as though you are under the impression that more than 10% of Antpool's hash rate isn't owned by a single business.

What one miner decides is what 90+% of Antpool's mining power will do.  And I'd bet on 90% of the stuff he DOESN'T own just sucking along for the ride.

You're quoting someone who thinks "protecting" an ill-defined "non-mining node decentralization" is worth capping the potential growth of Bitcoin... while keeping ALL of his coins on a centralized exchange. The man's an enigma.

The more cunning of the Blockstream apologists advocate making BTC less competitive to encourage price appreciation in altcoins like Monero. JJG doesn't own any. A mystery wrapped in an enigma. 

Look at you beastmodeBiscuitGravy, I mean lambie.  Continuously studying me in order attempt to distract with irrelevant skewed personal details.  Why don't you provide some details of your own trading strategy and cryptoholding practices to the extent we may be able to believe any of it?

Let me see if I can summarily respond to your nonsense regarding more or less what I am advocating (one individual, me), at the moment? 

1) I mentioned the mining poole topic because if some dumb ass miner poole leader suggests that his mine poole is going to take some partisan position to not adopt seg wit etc, merely because they want to get a blocksize limit increase - like taking a hostage threat, they are likely going to lose business, either mining power or increased competition against them in other ways. 

2) I advocate that bitcoin is not broken or technically flawed and suggest that there are a lot of solid innovations in this space.  Accordingly, any proposed changes to the status quo should be achieved with evidence and logic in order to persuade that the change is necessary.  If any new proposal cannot achieve an overwhelming level of support by the decentralized powers that be in the bitcoin community, then the proposed change does not get adopted.  Yeah, it can be revised and re-preposed and tweaked and if it is good, then it will get adopted sooner or later, but we do not need to rush into adopting something that is not agreed-to because currently bitcoin is not broken... and if evidence is presented that there is some kind of break of bitcoin, then proposals to fix such break would likely be adopted fairly quickly.

 

Poole?       Poole?

Stahp, please, my sides.

[iCEBREAKER]

So much "congestion" 

https://bitcoinfees.21.co/

Which fee should I use?

The fastest and cheapest transaction fee is currently 60 satoshis/byte, shown in green at the top.
For the median transaction size of 226 bytes, this results in a fee of 13,560 satoshis (0.05$).

ZOMG 5 CENTS

SATOSHI'S PRECIOUS BABY IS CRIPPLED.  AND STRANGLED.

WHO WOULD EVER PAY 5 CENTS FOR FINANCIAL SOVEREIGNTY WHEN THAT MUCH MONEY MIGHT BUY A CHICLE IN RURAL CUBA?

[jbreher]

With KNC gone, Classic is completely done.

For some odd definition of 'completely', I guess.

[Lauda]

For some odd definition of 'completely', I guess.
-snip-

Classic still has some, mostly-corporation funded, nodes online indeed. There's nothing surprising there. Those nodes matter the same way that the other ~800 mattered that went down the same day.

ZOMG 5 CENTS

Don't you remember the time when it was 4 Cents? Bitcoin is too expensive now and I fear that people will move to alts, said the Classic supporter!

-snip-
...and so on. Bounties can go a long way to get things done even when there is lack of coding talent in one's side (as is the case). Instead they are wasting money on useless sybil nodes.

Instead they're wasting their money with rented hashrate and not accomplishing anything with it.

[franky1]

So much "congestion"  

https://bitcoinfees.21.co/

Which fee should I use?

The fastest and cheapest transaction fee is currently 60 satoshis/byte, shown in green at the top.
For the median transaction size of 226 bytes, this results in a fee of 13,560 satoshis (0.05$).

ZOMG 5 CENTS

SATOSHI'S PRECIOUS BABY IS CRIPPLED.  AND STRANGLED.

WHO WOULD EVER PAY 5 CENTS FOR FINANCIAL SOVEREIGNTY WHEN THAT MUCH MONEY MIGHT BUY A CHICLE IN RURAL CUBA?

median transaction size of 226byte??
i think u meant minimum not median

after all most blocks are averaging about 2500tx not 4424tx.. so get with reality..

the AVERAGE transaction size of 400byte = 0.00024btc = slightly over 0.11$

which is a 6x increase in under a year...

note i could use 500byte as that is a more fair amount. but i actually tried to do you down players a favour by rounding the average up to 2500tx a block(400byte) instead of down to 2000tx a block(500byte).
i even rounded down the 0.1164$ to 11 instead of up to 12.. just to be helpful to you down players...
i even rounded the dollar valuation down to the days average of $485 instead of the exact price at time of posting of $498

but if you want to knit pick, you wont like the actual numbers because it would get worse for you and hurt your down playing motives
(454byte(2200tx)=0.0002724btc fee = $0.1356552($498 valuation)

[jbreher]

But again, for the same number of economic transactions, The Omnibus SegWit Changeset actually increases the bandwidth and storage burden upon fully-validating nodes.

This increase is very small ...

So BitUsher also cedes the point that SegWit does nothing to ease centralization due to burden of larger blocks upon fully-validating nodes. Joining Lauda, exstasie, and forevernoob. Excellent. Who's next?

[gmaxwell]

So BitUsher also cedes the point that SegWit does nothing to ease centralization due to burden of larger blocks upon fully-validating nodes. Joining Lauda, exstasie, and forevernoob. Excellent. Who's next?

Nice classic-speak jbreher--  Someone saying that a change increases bandwidth usage doesn't mean they're saying it does nothing to mitigate.

For those who actually care about the facts: Segwit does ease the burden compared to a blocksize  increase: It eliminates the quadratic cost in transaction signature hashing, it opens up new sync mode for full nodes that are using pruning that will allow them to skip downloading the signatures they aren't going to validate or store,  it also allows running a non-upgrade segwit node to get a mostly-validating state (which is useful as a last resort for someone who's alternative would be to not run a node at all), and (compared to Bitcoin Classic's proposal) doesn't make the potential impact on the UTXO set size any worse (so on this point, it's an increase, but less of an increase than just changing the blocksize limit would be).

median transaction size of 226byte??
i think u meant minimum not median

That is the median size.

after all most blocks are averaging about 2500tx not 4424tx.. so get with reality..

You're just being mean.

[franky1]

So BitUsher also cedes the point that SegWit does nothing to ease centralization due to burden of larger blocks upon fully-validating nodes. Joining Lauda, exstasie, and forevernoob. Excellent. Who's next?

Nice classic-speak jbreher--  Someone saying that a change increases bandwidth usage doesn't mean they're saying it does nothing to mitigate.

For those who actually care about the facts: Segwit does ease the burden compared to a blocksize  increase: It eliminates the quadratic cost in transaction signature hashing, it opens up new sync mode for full nodes that are using pruning that will allow them to skip downloading the signatures they aren't going to validate or store,  it also allows running a non-upgrade segwit node to get a mostly-validating state (which is useful as a last resort for someone who's alternative would be to not run a node at all), and (compared to Bitcoin Classic's proposal) doesn't make the potential impact on the UTXO set size any worse (so on this point, it's an increase, but less of an increase than just changing the blocksize limit would be).

all i can see is them trying to downplay how they are reducing the FULL VALIDATING NODE count

how can you be a FULL NODE if your pruning and skipping downloads of signatures they are not going to validate...
if your not validating fully.. your not a full validating node.

[gmaxwell]

all i can see is them trying to downplay how they are reducing the FULL VALIDATING NODE count

All you can see is random distortions that confirm your world view.  Clue up: You know that your Bitcoin Classic now doesn't check any signatures at all on blocks where the miner-provided timestamp in the header is a day old?   If you're concerned about these details you should be rallying against "classic".

I gave you a long list of ways that segwit improves actual scalablity and all you can do is focus on skipping validation WHICH EVERY SINGLE EXISTING FULL NODE ALREADY SKIPS and on the _option_ of a possible new mode that still protects against inflation and the users own transactions which someone could use when their alternative is to NOT RUN A NODE AT ALL. And you suggest that it's reducing something-- but you ignore classic's gutting of validation.  Tisk tisk.

[franky1]

all i can see is them trying to downplay how they are reducing the FULL VALIDATING NODE count

All you can see is random distortions that confirm your world view.  Clue up: You know that your Bitcoin Classic now doesn't check any signatures at all on blocks where the miner-provided timestamp in the header is a day old?   If you're concerned about these details you should be rallying against "classic".

I gave you a long list of ways that segwit improves actual scalablity and all you can do is focus on skipping validation WHICH EVERY SINGLE EXISTING FULL NODE ALREADY SKIPS and on the _option_ of a possible new mode which someone could use when their alternative is to NOT RUN A NODE AT ALL. And you suggest that it's reducing something-- but you ignore classic's gutting of validation.  Tisk tisk.

part of your delusion is that you think i was or am a classic fanboy..
sorry.. but im not

im independent and just want proper and logical scaling via the blocksize limit..
your attempts to try pushing anyone that wants scaling via a blocksize limit, into the classic camp is a narrow minded onesided and biased view..

please open the small box in your mind.. step out of it. and then look outside of the box..

WHICH EVERY SINGLE EXISTING FULL NODE ALREADY SKIPS and
...
 classic's gutting of validation.  Tisk tisk.

lol so he admits core is just as bad as classic because core must be in the "every single existing node" category

by the way i have never defended classic.. i think blockstream is just the same as R3 and both 'camps' are as bad as each other

[gmaxwell]

part of your delusion is that you think i was or am a classic fanboy..

This is, after all, the "classic" thread-- so, I guess since your concerns are so sincere and neutral I should be expecting to see you open an issue on the classic github to tell them that disabling validation on blocks claimed to be a day old is bad and they should undo it?

lol so he admits core is just as bad as classic because core must be in the "every single existing node" category

Nice ninja edit there.  No-- Classic turns off validation based on a timestamp set by the miners. Core and every other full node other there skip signature checking on blocks below a hardcoded block 100,000 deep in the chain (a behavior, added by Gavin in 2011, which-- incidentally-- i argued against, but is now one of the things keeping the initial sync time tolerable on low power devices).  In any case, your dispute there is with every existing full node software, not Core. (And at least in core you can disable that behavior by setting checkpoints=0).  

I hope you can see the difference between not checking things in a chain with months of POW on top of it vs not checking when miners simply say so in block headers.

[franky1]

part of your delusion is that you think i was or am a classic fanboy..

This is, after all, the "classic" thread-- so, I guess since your concerns are so sincere and neutral I should be expecting to see you open an issue on the classic github to tell them that disabling validation on blocks claimed to be a day old is bad and they should undo it?  

just like segwit node wont validate blocks before certain milestones...

please take off the blockstream hat, for just 1 minute. and wear the coders logic hat.. and answer one question
can you atleast see the hypocrisy of both camps..

[BitUsher]

So BitUsher also cedes the point that SegWit does nothing to ease centralization due to burden of larger blocks upon fully-validating nodes. Joining Lauda, exstasie, and forevernoob. Excellent. Who's next?

This is just dishonestly misrepresenting my whole statement. To think I donated and helped promote your daughter recoup her losses after your arrest as well and this is how you treat me? If you disagree , fine , but this dishonesty is really shameful.

[gmaxwell]

Franky1-- So, you're saying that you are not going to complain to "classic" about behavior a million fold riskier than what you're complaining about in Core that exists in all other full node software?

And we're supposed to continue to believe your concerns are sincere? Oookkay.

Meanwhile you continue to flood this thread with things you fake-disagree with (as evidenced by not caring about classic doing something far worse) to push off the list of scalability improvements in segwit where you can't find anything to distort into a fault.

Keep in mind that this thread is about "Bitcoin Classic"-- if that isn't what you want to talk about, your posts are offtopic.

[jbreher]

So I see franky1 has already posed the first question to gmaxwell, to wit: "What part of 'fully-validating' do you fail to understand?"

So BitUsher also cedes the point that SegWit does nothing to ease centralization due to burden of larger blocks upon fully-validating nodes. Joining Lauda, exstasie, and forevernoob. Excellent. Who's next?

Nice classic-speak jbreher--  Someone saying that a change increases bandwidth usage doesn't mean they're saying it does nothing to mitigate.

So gmaxwell also cedes the point that SegWit does nothing to ease centralization due to bandwidth and storage of larger blocks upon fully-validating nodes. Joining Lauda, exstasie, and forevernoob, and [edit: BitUsher may not be correct - standby for explanation]. Excellent. Who's next?

...

And I was so hoping we could discuss the following:

In one hand they are stopping block size increase citing lack of consensus, and in other hand they are force feeding RBF & SegWit without consensus.

Removing the rules against actions that the network protocol expressly forbids against the will of an economically significant portion of users, and risking a persistent ledger split in the process is not a comparable thing. It's something that Bitcoin Core strongly believe it does not have the moral or technical authority to do, and attempting to do so would be a failure to uphold the principles of the system. It's not something to do lightly, and people who think that it's okay to change the system's rules out from under users who own coins in it are not people that I'd want to be taking advice from-- that kind of thinking is counter to the entire Bitcoin value proposition.

So just to be clear - do you maintain that block size increases are necessarily "Removing the rules against actions that the network protocol expressly forbids", and are therefore necessarily evil?

Finally--at some point the capacity increases from the above may not be enough.  Delivery on relay improvements, segwit fraud proofs, dynamic block size controls, and other advances in technology will reduce the risk and therefore controversy around moderate block size increase proposals (such as 2/4/8 rescaled to respect segwit's increase).

- Capacity increases for the Bitcoin system: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

[jbreher]

So BitUsher also cedes the point that SegWit does nothing to ease centralization due to burden of larger blocks upon fully-validating nodes. Joining Lauda, exstasie, and forevernoob. Excellent. Who's next?

This is just dishonestly misrepresenting my whole statement. To think I donated and helped promote your daughter recoup her losses after your arrest as well and this is how you treat me? If you disagree , fine , but this dishonesty is really shameful.

1) You said "the increase is very small", correct? Accordingly, I interpreted this as you agreeing there was indeed an increase. In what way is that misrepresenting your statement? I am just trying to cut through the fog to figure out exactly _where_ our disagreements actually lie, in this thread full of shillery on both sides of the argument. Do you now deny there is an increase in bandwidth and storage required with vs. without The SegWit Omnibus Changeset for representation of each transaction? And if you do, then by what mechanism are the main chain transaction structures correlated to the witness chain transaction structures?

2) Thanks for your donation. Sincerely. But that was not for me nor my daughter -- it was for fellow forumite BurtW - well, actually for his daughter. And him as well, I guess, as a show of solidarity, if not monetarily. A worthy cause totally divorced from the discussion at hand.

[BitUsher]

it was for fellow forumite BurtW - well, actually for his daughter.

Fair enough, yes you were merely trying to help him as well.

1) You said "the increase is very small", correct? Accordingly, I interpreted this as you agreeing there was indeed an increase. In what way is that misrepresenting your statement? I am just trying to cut through the fog to figure out exactly _where_ our disagreements actually lie, in this thread full of shillery on both sides of the argument. Do you now deny there is an increase in bandwidth and storage required with vs. without The SegWit Omnibus Changeset for representation of each transaction? And if you do, then by what mechanism are the main chain transaction structures correlated to the witness chain transaction structures?

Segwit is a necessary for Schnorr signatures which do indeed reduce Bandwidth and storage(far more than what is added with segwit). Additionally, there are greater concerns than storage costs and bandwidth for scalability such as eliminating the quadratic cost in transaction signature hashing and reducing UTXO bloat.

Are you trying to insinuate that the package of benefits that Segwit provides is worse than the initial slight increase in overhead to bandwidth and storage costs?

[forevernoob]

Oh hell with it - I'll answer first, though it really be your turn. Better - I'll answer in the form of a question...

And how is kumquats not hairbrushes?

In no sane set of definitions for 'bigger blocks' and 'centralization' are they equivalent. English much?

Now, it is _possible_ that bigger blocks _might_lead_to_ centralization. It is also possible that it does not.

Now here's a question for you -

It doesn't really matter how bad SegWit is. What you advocate is far worse.

As:
a) you think SegWit is The One True Way;
b) you cede that SegWit requires more resources of a fully-validating node than the status quo to represent each transaction; and
c) you seem to value centralization very highly;
then:
is your true goal to 'decentralize' by reducing transaction count to zero?

I vote none of the above. I want Bitcoin to stay Bitcoin.
I don't want it hijacked by democracy loving sheeples.

You don't seem to get it. What is most important for me is consensus and how Bitcoin is developed. 75% is not consensus.
I don't really care about SegWit since it's a soft fork and not something forced upon me.

Now, it is _possible_ that bigger blocks _might_lead_to_ centralization. It is also possible that it does not.

I don't believe SegWit will centralize the network.
I am however certain that forever growing blocks will centralize the network. And your answer didn't change my mind about that.

SegWit isn't perfect but at least it's opt in. It's not forced on anyone.

Bull fucking shit. It turns fully-validating nodes into non-validating nodes.

Care to explain this in detail?

[jbreher]

1) You said "the increase is very small", correct? Accordingly, I interpreted this as you agreeing there was indeed an increase. In what way is that misrepresenting your statement? I am just trying to cut through the fog to figure out exactly _where_ our disagreements actually lie, in this thread full of shillery on both sides of the argument. Do you now deny there is an increase in bandwidth and storage required with vs. without The SegWit Omnibus Changeset for representation of each transaction? And if you do, then by what mechanism are the main chain transaction structures correlated to the witness chain transaction structures?

Segwit is a necessary for Schnorr signatures which do indeed reduce Bandwidth and storage(far more than what is added with segwit).

While that may be, I was unaware that this Schnorr signature feature was a part of The SegWit Omnibus Changeset. Last I heard, the devs concluded 'expect BIP within next year or so'. No?

Additionally, there are greater concerns than storage costs and bandwidth for scalability such as eliminating the quadratic cost in transaction signature hashing and reducing UTXO bloat.

At his point in time, I am unaware of anyone reporting the quadratic cost in signature hashing as being a significant issue other than the one party who intentionally created a single-transaction maxblocksize block to perform an experiment that ended up as nothing but fodder for concern-trolling. Either way, there are other solutions to this issue. I think the free market would solve this on its own. What incentive does a miner have to continue hashing on a block that it knows is going to take multiple block intervals to hash? The miners' own self-interest would cause them to orphan that block and get back to hashing. Whatever - that's peripheral to the proximate discussion.

Are you trying to insinuate that the package of benefits that Segwit provides is worse than the slight increase in overhead to bandwidth and storage costs?

No. I am trying to cut through the FUD. This entire argument has had each point meme-ified, to the point where a large number of people are under the impression that SegWit itself (as merely part of The SegWit Omnibus Changeset) reduces the storage and bandwidth demands upon non-mining, fully-validating nodes, and thereby through this mechanism increases decentralization. Which is demonstrably false.

While I am a 'simple maxblocksize bump now' kinda guy, I acknowledge there is a lot to like in the SegWit Omnibus Changeset. Unfortunately, also a lot to loathe. So I will continue to try to publicly pull back the layers of falsehoods being circulated regarding the bigblock now position.

[jbreher]

You don't seem to get it. What is most important for me is consensus and how Bitcoin is developed. 75% is not consensus.

You're right - there is something in your statements that I don't quite get. If 75% is not consensus, then neither is 95%. So... what's your point?

I don't really care about SegWit since it's a soft fork and not something forced upon me.

Now, it is _possible_ that bigger blocks _might_lead_to_ centralization. It is also possible that it does not.

I don't believe SegWit will centralize the network.
I am however certain that forever growing blocks will centralize the network.

Yet The SegWit Omnibus Changeset grows blocks.

Just to be clear, your argument is that increasing maxblocksize centralizes the network of non-mining, fully-validating nodes, by reducing the absolute number of such nodes, due to increased per-node resource demand?

What if the number of bitcoin users increases by by some factor due to new entrants, and a few of them fire up nodes, such that absolute node count rises while percentage drops? Is that an increase or decrease of decentralization in your definition?

And your answer didn't change my mind about that.

Cool. I can agree to disagree. I'm just trying to cut to the core of the facts in dispute, and peel back the falsehoods heaped atop them.

SegWit isn't perfect but at least it's opt in. It's not forced on anyone.

Bull fucking shit. It turns fully-validating nodes into non-validating nodes.

Care to explain this in detail?

Sure. In one sentence. I thought it was crystal clear already. So here goes - to wit: Upon activation of The SegWit Omnibus Changeset, previously fully-validating nodes are rendered non-validating nodes, as they are incapable of validating SegWit transactions.