No. All the above is noise. That's my point. The only signal is the emergent consensus of the network. The only vote that matters is the ultimate decision on who accepts what within a block. That majority will determine the longest chain. The longest chain, in turn, defines Bitcoin. Anything other than that is an unreliable 'measure' of power within the system.

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


For better or worse (I would say for worse), in this era of industrial mining, non-mining nodes have essentially zero power. Any viable mining operation has sufficient  resources to run a node of its own, and connect explicitly to other mining entities that share its philosophy. The only power outside of miners is the threat that users abandon the chain en masse.

Your incessant use of this canard only weakens your arguments. bitcoinocracy is no more credible than consider.it.

Sorry. Got my signals crossed.

Though this thread in entirety is entitled Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal!. Seems relevant. That, and I did reply directly to a point you made about "block size".

To return to your side branch, though, perhaps you can tell me in what manner you think LN contributes to decentralization. The way I see it, it will inevitably end up a hub/spoke system - meaning more centralization. Also with node and path discovery being mediated by (other?) centralized actors.

No. As I have pointed out to you before, with SegWit, all nodes that want to operate in a trustless manner require processing the signature chain as well as the 'blockchain-minus'. There is NO efficiency gain for a node operating in a trustless manner. What you call 'efficiency gain of SegWit' is only achievable by nodes that must trust other nodes to perform validation for them.

As such, SegWit does nothing for the centralization issue.

The SegWit Omnibus is already several significant independent changes being rolled out as a single release.

Hey - remember back when Ripple's market cap was greater than Bitcoin's? Yeah - those were the days.

According to coinmarketcap, as of yesterday, Bitcoin's share of the entire crypto space was 88%. That seems around last year's mean, if memory serves. IOW, there has not been a significant recent flight from Bitcoin to alts.

Of course, if you do, you have no assurance that bitaddress.org does not have a copy of your private key. Sure, it is said that the code runs locally. Did you audit it? At that instance?

If you're gonna be paranoid, you better noid harder.

Note: you can download the bitaddress page locally, and run it on an airgapped computer. Not too complex an operation to be sure your funds are safe.

As compared to you attempting to ridicule me for pointing out that this particular analysis is inapplicable to the topic under discussion? Certainly.


Except, of course, that the linked material is irrelevant to 'the issue'.

eta:

I can only assume you did not read it in entirety, as the comments therein have OrganOfCorti admitting that his analysis is off in its conclusions. By roughly two orders of magnitude. And contains an unfulfilled statement that it will be updated to fix this error.

I can only assume you did not read the followon info, which shows that it would take at least six years for any discernible chance that the 75% fork would false trigger at any less than 70% actual.

But by all means, keep repeating the same inapplicable statement.

A link, coupled with a statement implying that the material in the link was applicable to the particular 75% fork threshold being discussed, and that it necessarily indicated a 'problem':

It is not so much the math, but interpreting what it means in real terms. OrganOfCorti's post seems to focus upon mathematics, yours seems to focus upon hysteria. Shall we analyze this together?

The damning part of the analysis is specific to BIP 101, and assumes 'vote spoofing' upon the part of nefarious actors. Such is fine, and important in regards to analyzing the BIP 101 situation. However, you present it as if it is  universally-applicable to any 75% proposal. 'Flaw #3' is inapplicable to any situation where the tabulation of 75% is strictly based upon hash power.

So yes, it seems to me that you are trolling.

Even so, there is an admitted latent issue with the order of magnitude in the comments, unaddressed for months.


Or more importantly, the amount of time for variance to result in a false trigger is important. The other analysis in the quoted comment above puts the chance as "TL;DR: At anything less than 70% of steady hashrate, triggering a fork would take at least 6 years, and gets exponentially less likely as miner share decreases."

Even the bulk of Core devs are seeming to claim that it will be necessary in the not-too-distant future to increase the block size. Just not now. For some unstated reason. If variance results in a trigger after Core would have already increased the block size anyhow, then the trigger is a non-event. No chain fork results. So what?

In Wuillie's presentation at Scaling Bitcoin Hong Kong, I believe* he stated that by looking at recent transactions, the current scaling factor would seem to be about 1.75x. Or that signature data is slightly less than half the block data.

*my memory is at times faulty. But I'll stick to a claim that some prominent Core dev stated that analysis of recent blocks led to this figure.

Others I have seen use a 4x figure - totally dependent upon an assumption that multisig become a much larger portion of the transaction volume.

For this little branch of the discussion, the salient point is that any node that performs validation (i.e. any node operating in a trustless manner) must process not the claimed 1MB block size worth of data, but an amount of data that reflects the signature data as well - 1MB multiplied by this (instantaneous) scaling factor, be it 1.75x, 4x, or whatever else represents the proportion of signature data associated with the transactions included in that block.

Because the stated 75% criteria produces a negligible yet discernible chance that we get a false trigger at an actual 67% adoption rate due to variance? Yawn. Troll harder.

Yes, they can. And they must process more than 1MB of data in order to validate what they are calling a 1MB block. The difference in quantity of data, of course, being the amount of data in the signatures.

So tell me again why this does requirement for more data not lead to node centralization, when many SegWit boosters (perhaps not yourself - I can't keep track) rely upon 'increasing block size to 2MB will lead to node centralization' as one of their strongest arguments? Or at least as their only argument for their claim that a simple block size increase is unsafe?

(bold not in original)

Please define what you mean by 'upgraded client'.

If such a client is getting a 'capacity boost', the only way this can be accomplished is by that node ignoring signature data. Ignoring signature data in and of itself makes that node dependent upon others to perform validation. Accordingly, such a node cannot operate in a trustless manner. It is insecure.

No need. I'll interpret this merely as you replying 'No'.

It is just that I remember interactions in years past whereby I thought you typically provided solid reasoning. Your posts of the last month or so don't seem so to me. More along the lines of axioms stated as proven fact followed by conclusions with no intervening reasoning. Sorry - just calling it as I see it.

I can't tell what is subject and what is object in your reply. But if I have your words parsed properly, than I believe you are making a false statement. Let me try again.

For any given node:
- In order to operate in a trustless manner, a node must fully validate
- In order to fully validate, a node must have access to signature data
- SegWit partitions transaction data into two chains - the operational data and the signature data
- the 'capacity increase' that SegWit claims is entirely due to the fact that they don't tabulate the signature data as being part of the block size accounting

Ergo, any node wishing to operate in a trustless manner does not get any 'block size increase'

You may reply 'but fraud proofs'. But this is yet another mechanism entirely dependent upon outsourcing validation to other nodes. IOW, not trustless. Insecure.

Nonsense. Any rational exchange, seeing the threshold nearing, will implement trading for both chains independently. With tools to allocate to such chain funds that are being spent from the common trunk as desired by the nominal 'owner' of such funds. Any exchange that does not is incompetent, and deserves to be put out of business.

I note that even SegWitters are starting to recognize the possibility of chain splitting due to the SegWit fork, anyways.

In and of the fact that politics is nothing more or less than the adjudication of who wields power in a group dynamic, this particular part of Bitcoin is indeed 100% political.

One group (small blockers) want one thing, and another group (big blockers) want another. What outcome wins? It will be decided by those who amass political power. Period.

Sure, it all has to operate within the constraints of what technology allows, but it is still political. All your pollyanna posturing can't change that fundamental truth.