Quote from: jbreher on May 27, 2016, 10:25:55 PM

Quote from: exstasie on May 27, 2016, 09:39:47 PM

Quote from: jbreher on May 27, 2016, 09:26:43 PM

So you cede that The SegWit Omnibus Changeset is antithetical to its stated goal of decentralization through small resource demands.

Huh? Its stated goal is fixing transaction malleability.

So you also cede that for the same set of transactions, the Omnibus SegWit Changeset consumes more memory and more bandwidth than without The SegWit Omnibus Changeset. Excellent. Who's next?

That's an odd question. "For the same set of transactions" suggests that OP_SEGWIT is not relevant here. Segwit transactions are not "the same set of transactions" as non-Segwit transactions.

But I acknowledge what you're getting at -- outputs. Technically, by pulling the witness out, a 1MB block becomes 500kB, as far as the byte counter in the consensus code is concerned. If you are suggesting that Segwit transactions might technically be bigger by a few bytes, you'd be right. However, Schnorr signatures (Segwit-required) alone will not only negate that, but will significantly reduce transaction size.

If, in regards to Segwit's [flex] block size increase, you're asking whether more data = more data, then yes. More data = more data. To which I would ask, what point are you trying to make? You deleted the portion of my quote that explains the relevant issue:

Quote

That's why it's so important that Segwit is opt-in (and backwards compatible), at a time when many node operators (including myself) are already near the max of upload bandwidth they can contribute.

It is also pertinent here to define resources costs; since you bring up memory, lets talk about the UTXO set. For example, in standard transactions, due to the size of signatures vs. preimages, Txouts are about 25% of the size of TxIns (hence the 75% discount for Segwit transactions). This means it can be cheaper, currently, to split coins (increasing UTXO set size and creating more dust) than to merge them (decreasing UTXO set size). The discount addresses the rational, but perverse incentive that currently exists to perpetually increase the UTXO set unnecessarily by creating dust outputs and not spending them, which increases required memory resources across the board... and mining latencies.

Quote from: jbreher on May 27, 2016, 10:25:55 PM

Quote

The stated goal of bitcoin is decentralization

Just no. Other than the fact that 'decentralization' is a nebulous concept (decentralization of what notwithstanding), the bitcoin whitepaper does not mention decentralization even once.

Um, what did you think "Peer-to-Peer" referred to in "Peer-to-Peer Electronic Cash System?" Feel free to google "peer-to-peer":

https://www.google.com/search?q=Peer-to-Peer&ie=utf-8&oe=utf-8

Quote

denoting or relating to computer networks in which each computer can act as a server for the others, allowing shared access to files and peripherals without the need for a central server.

Quote from: jbreher on May 27, 2016, 10:25:55 PM

In fact, the goal, as explained in the first sentence, is "A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution."

Indeed. Peer-to-peer is by definition decentralized. Removing financial institutions from transactions means removing centralized third parties. It looks foolish on you to argue that decentralization doesn't matter in regards to bitcoin, given that it was its stated raison d'etre. To suggest that decentralization matters not means that bitcoin need not be P2P.

Quote from: jbreher on May 27, 2016, 10:25:55 PM

Quote

at a time when many node operators (including myself) are already near the max of upload bandwidth they can contribute. Big ups to Core for maxuploadtarget and blocksonly to help us contribute the maximum possible without interfering with other bandwidth-heavy activities (gaming, streaming, torrents, video-conferencing, etc).

Cheese? Who's in the Free Shit Army^TM now?

What are you babbling about? I'm contributing all the bandwidth I can for nothing in return. Big blockers suggest that we increase capacity simply to keep transactions cheap or free for users. That means externalizing the cost of transactions away from users (who get cheap fees) and forcing them onto node operators (who need to propagate them to all connections). I'm happy to pay more for transaction fees -- transaction relaying and validation is not free; the IC3 paper put it at $1-6 per confirmed transaction. I'm not happy to endlessly give up more and more bandwidth because people don't want to pay to push transactions. I don't have an option to access more bandwidth from my residence, so those externalized costs would just force me off the network eventually, all else equal.

I don't expect anything for free. I contribute my bandwidth partially out of security and partially out of altruism. You seem to think I should pay for users to transact for free or extremely cheap, forever, with no regard for the actual cost of validating/relaying transactions, nor UTXO set cost -- people who refuse to contribute to bitcoin's security. No thanks. I'm happy to see those people get their transactions stuck and/or dropped from mempool if they refuse to wise up. This isn't a fucking charity. Bitcoin isn't a public service for users to transact for free -- it is an incentive-based economy.