Don't mean to be pedantic Greg, but if Segwit transactions can't be validated by Bitcoin nodes should we be calling them bitcoin transactions?
it's time to increase the block size and quit messing around with all this other stuff.
Topic: ToominCoin aka "Bitcoin_Classic" #R3KT - page 13. (Read 157066 times)
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?
As I said , it is a prerequisite to allow for Schnorr signatures. Thus a very small temporary increase in bandwidth and storage will allow us great savings later.
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.
It effects us all right now , and while few people currently have nodes crashing currently due to maxBlockSize being limited to 1MB , the whole point of segwit is to be forward looking to increase scalability. Have you read the LN roadmap or cores roadmap with flexcap? Core's plan is increasing capacity with larger blocks in the future. It is only rational to make bitcoin more scalable before or while you increase capacity. In this case segwit rolls in protection within the same capacity upgrade.
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.
Sure some miners may restrict certain Tx's , others will not and this will cause havoc with nodes.
and thereby through this mechanism increases decentralization. Which is demonstrably false.
Both proposals will likely decrease full node count and do little to change the somewhat more centralized nature of mining. Ignoring all of the unrelated benefits of Segwit, it has the benefit to bandwidth, and storage costs in the future , and protect against the more important concern of UTXO bloat and quadratic cost in signature hashing right now.
You aren't considering the extreme danger this presents when the blocksize is increased. Additionally, Segwit allows SPV nodes to run more secure in the future (fraud proofs) and lower bandwidth immediately. Additionally, because Segwit opens the door for the LN sooner than Classic by fixing tx Malleability we can finally incentivize nodes and increase decentralized node count.
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.
Pedantically, this is not correct. They validate many things about them-- locktimes, spend consistency, prevention of double spending, fees, non-inflation. The only thing they don't validate is segwit signatures. However, they also also drop and ignore segwit txn unless they're in blocks-- they won't relay them, or mine them, or show them as unconfirmed transactions in wallets. Non-upgraded nodes also know something is going on about that they don't understand and will tell the user, and if you wanted to set yours up to shut down until you upgrade it to be segwit aware you could-- though it would be an unusual thing to do. (Except "Bitcoin Classic"-- they just started ripping out the notification logic because it was telling users they were out of sync due to CSV's pending activation-- rather than just integrating this long coming, well understood, simple script addition that we already wrote for them...)The same non-checking of the new thing but still checking the old stuff was is true for CSV which will activate soon, it was true for CLTV, it was true for P2SH, it was true for nlocktime by block-height back when Bitcoin's creator added that. This particular upgrade mechanism is an intentional part of Bitcoin's design with specific affordances in the transaction structure and script system. It's one that has been used many times in the past without trouble via a process which has evolved and matured in response to experience (in the above listed changes as well as a number of additional ones).
Before and when segwit activates your nodes will tell you (unless you're running the most recent "Classic" software...), at that point you can figure out what you want to do.
The obvious thing to do is to upgrade-- but you don't have to: things will continue to work and if you are already requiring multiple confirmations to consider transactions confirmed or primarily sending funds it's hard to argue that your security would be in meaningfully degraded. If you'd like to upgrade but you are running customized or un(der)maintained software (like Bitcoin "Classic", or one of the many abandoned full node implementations) you can get the full security effect of upgrading by setting up an upgraded node and then -connect-ing your non-upgraded node to it. This means that you can upgrade on your on terms, when it fits your schedule, and in a way that minimizes costs and disruption to your activities. It means that, if you want and/or your process requires it, you'll have all the time you need to have new software audited to your requirements or to forward port and test your customization. Of course, you'll likely just upgrade-- as it's easy to do, and after doing so you can get the benefits of using segwit yourself but when and how you upgrade is up to you and on your terms. And that is really how it has to be: We can't build a system who's value proposition begins with personal freedom and autonomy with a system maintained through coercive synchronous forced upgrades.
Quote
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?
This is an effect that was reasonably expected in 2011/2012 which has been thoroughly debunked by experience. The user count has grown astronomically while the node count has declined pretty much right along with the increase in the initial sync time. More users means more nodes, but not when running a node makes your systems obviously slower, chews up enough bandwidth to run you into data caps, and takes a week to sync up. In Core we've been working frantically for years slamming out performance improvements to try to use optimization to compensate for load increases to protect decentralization.Segwit increases capacity, but does so in a way that can eat less into those factors than a simple blocksize increase-- because it is a true scalablity improvement-- and it sets the stage for further efficiency increases down the road. Today even many big name bitcoin businesses outsource their node operations to centralized APIs, and this was something that no one working on Bitcoin really anticipated in 2011.
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?
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?
Quote
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.
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?
Quote
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.
Quote
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.
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 -
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?
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 -
Quote
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.
Quote
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?
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?
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.
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 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:
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?
- Capacity increases for the Bitcoin system: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
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?
Quote
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
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.
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.
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.
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..
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?Quote
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.
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..
Quote
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...
classic's gutting of validation. Tisk tisk.
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
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.
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.
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.i think u meant minimum not median
Quote
after all most blocks are averaging about 2500tx not 4424tx.. so get with reality..
You're just being mean. 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?
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$).
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)
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.-snip-
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. ...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.
Jump to: