Quote from: jbreher on May 28, 2016, 03:07:22 AM

Let's back up the bus a sec. Seems we have a terminology overload. When I said "the same set of transactions", I'm speaking of economic transactions, not their encoding upon the wire.

For the same set of _user_transactions_ -- as in user X transfers value Q to address Z' -- more data must must be stored by a fully validating node using SegWit than without. It ain't a matter of the centrally-planned block size increase, its a matter of adding the ability to correlate the correct data in the 'main' block chain with the correct data in the 'witness' block chain. This is not free - there is overhead added.

Quite a long-winded, pointless way to talk past what I said:

Quote from: exstasie on May 28, 2016, 12:53:01 AM

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.

Schnorr aggregation alone can reduce transaction size by 30-40%+. So a few bytes overhead per transaction to utilize Segwit tx structure... then transaction size can be drastically reduced by utilizing Segwit tx structure. And in ways that incentivize decreasing, rather than increasing the UTXO set. What's your point?

We're not even considering LN and sidechains here, which can drastically improve scalability for that minimal overhead cost.

As BitUsher said:

Quote from: BitUsher on May 29, 2016, 12:15:36 AM

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.

As gmaxwell said:

Quote from: gmaxwell on May 29, 2016, 12:04:55 AM

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.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Quote

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).

'About', yes. Today. On average. Kind of. Tomorrow? Who knows the ratio? Nobody - that's who.

It can be easily changed through a soft fork, if for some reason it is problematic. Feel free to explain why it would be, and why we couldn't address it in the future.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

The direction BU seems to be headed to deal with this is via emergent consensus - let the free market decide, rather than being centrally planned 75%, which will be simply wrong for certain transaction mixes. Which, incidentally, is what BU does today for the maxblocksize -- let the market decide.

Individual users throttling different limits for consensus-critical specifications can result in many, many unintended forks of the blockchain. Any time two nodes disagree on a consensus-critical issue (like block size), they will fork from one another if each continues to build on their respective chain. I wish BU luck, as I think most people realize by now that this is untenable for the idea of a single, global ledger -- hence its lack of devs and users.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Rather than rely on the centralization of the ever-so-well-meaning dev oracles (who are bright guys, but I think are headed down a blind path on economic matters), I would rather put my trust in the decentralized market.

Pull requests and commits are open and publicly debated. Anyone in the world is welcome to contribute to Core; there were nearly 100 contributors in the 0.12 release. How many developers are working on BU? Clearly developers are by and large choosing to work on Core instead of other implementations.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Quote

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_.

[emphasis added] I note your quoted definition has exactly no correlation to the type of 'centralization' we are discussing. Note that 'a'? Note 'server' in the singular?

LOL, really -- no correlation at all? Why does bitcoin software connect to peers, rather than dedicated central servers? If there exists at least two central servers (perhaps, financial institutions) that all users connect to (rather than each other), it's a peer-to-peer system--is that what you're saying? Why are you ignoring the part that says "computer networks in which each computer can act as a server for the others?"

Read the whitepaper. It refers to the parties in peer-to-peer transactions, who run nodes. The only useful distinction to make is that not all nodes perform proof-of-work anymore. If the centralization of nodes (mining or non-mining) is not relevant, then what is? Who are the "peers" in bitcoin's "peer-to-peer" system?

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Quote

It looks foolish on you to argue that decentralization doesn't matter in regards to bitcoin

It looks foolish on you to attribute an argument that I do not make. There are many ways that a complex system can be decentralized. True, one is in the number of non-mining fully-validating nodes. I would argue that we could lose at least an order of magnitude here, and it would affect the security of bitcoin not one whit. After all, other than the fact that non-mining, fully-validating nodes tend to be run by bitcoin owners, such nodes are essentially powerless.

According to the whitepaper (and common sense), all actors in the bitcoin system run nodes (or connect to them). That includes miners. Clearly the issue of decentralization refers to nodes--the "peers" on the peer-to-peer network.

Your suggestion that "non-mining nodes are powerless" is silly, considering that the value proposition for miners to support the network is to receive coins that they can use to transact with the economy (see "Incentive" in the whitepaper). If they, for instance, break the software's consensus rules, non-mining nodes (and mining nodes that are enforcing the consensus rules) will fork them off the network for mining invalid blocks. And in the absence of highly decentralized mining nodes, decentralized non-mining nodes are the only defense from Sybil attacks. Here's a good post with more on why they are essential to securing the network: https://bitcointalk.org/index.php?topic=1338166.msg13879163#msg13879163

Quote from: jbreher on May 28, 2016, 03:07:22 AM

The node's only option is whether or not to forward a particular transaction. Sure, the user operating the node can abandon the chain created by the mining majority. But that is not the node acting, it is the holder of the coins.

If a block is invalid, the user operating the node doesn't do anything. His node software doesn't recognize the block as valid and won't build on it. The user consents to the software's consensus rules by operating a node; his node defends the consensus rules.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Another dimension the system might be centralized across is in mining power. Or implementations. Or decision making. Or even total number of users of the monetary unit. But we don't care about these, do we? (Well, I do, but it seems you may not).

Miners operate nodes which perform proof-of-work. Of course the level of decentralization among mining nodes matters. They are specifically part of the peer-to-peer network.

"Other software implementations" have no bearing on the economy. If they don't disagree on consensus-critical issues, there is no effect. Feel free to reference the whitepaper on why "decentralization of software versions" matters.

As far as decision-making goes:

Quote

Firstly, pull requests and commits are open and publicly debated. Anyone in the world is welcome to contribute to Core; there were nearly 100 contributors in the 0.12 release. How many developers are working on BU? Clearly developers are by and large choosing to work on Core instead of other implementations.

If developers disagree with Core's direction, they are free to move on to other projects. Unfortunately for you, that doesn't appear to be happening.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

If you're contributing all the bandwidth you can, you're gonna be kicked out of the club of contributing nodes as soon as SegWit activates. Gee, thanks Core!

I can contribute as much as I can now. With or without Segwit, blocksonly and maxuploadtarget help to maximize the contributions that those with limited upload bandwidth can make.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Incidentally, I operate a fully-validating node as well. Several, in fact. So sorry you live in a backwater. Must be analogous to trying to mine in Sweden, rather than China.

I live in a central area of one of the largest US cities. I'm not sure what kind of standards you expect of your peers on the network, but your vision surely does not sound like a "global" currency. You sound like an asshole, tbh.

I used to run VPS nodes, but I'm not concerned about bootstrapping the network at this point. And those nodes didn't contribute to anyone's security (certainly not mine). My home node is physically controlled by me and secures my money.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Quote

Big blockers suggest that we increase capacity simply to keep transactions cheap or free for users.

Perhaps some. Not the ones I speak with. We suggest we increase capacity in order to increase capacity. Making room for more transactions.

What gives you the impression that full blocks are bad? Increasing capacity surely makes room for more cheap transactions. Other alternatives include optimizing transaction size. Businesses and users can batch payments more efficiently, and payors can use higher fees to push transactions during peak transaction times. I don't see an issue.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Which would make room for (all else equal) more bitcoin users. More users, more momentum, more value, more hashpower, more security, more headstart before the vampire squid awakens to the significance of this radical new money.

"More room" doesn't equate to more users. It certainly doesn't equate to more nodes or more miners. The rest of your slippery slope is just that.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

We trust that the miners are capable, as a group, to provide the proper value for maxblocksize.

Why would we trust miners to do anything but order transactions? Which is already quite a lot of power re: censorship.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Your solution is a centrally-planned fixed unit of size for this crucial economic variable. Yet you claim to desire decentralization? *psh!*

The entire premise of bitcoin was centrally planned. Designing and maintaining a peer-to-peer system that attempts to align the incentives of its actors is the essence of central planning. Satoshi was the biggest central planner of all, creating the money supply and controlled inflation mechanisms to incentivize users to transact in, and mine bitcoins. He said himself IIRC that bitcoin was much more about design than code. If you think that throwing out all knowledge and logic and leaving technical decisions about consensus-critical issues "to the market" is a solution to something (to what, I am unsure) then I disagree. Again, I am concerned about the decentralization of nodes (mining and non-mining) -- the peers in a peer-to-peer network, the actors in the bitcoin economy. Not some arbitrary idea that software development must be spread out across a minimum number of incompatible (hard fork-inducing) versions or that miners or individual users should throttle their own block size limits (or other consensus-critical specs).

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Quote

transaction relaying and validation is not free

Yet nodes do not get paid for this service - only miners do.

That does not change the fact that it is a cost for all nodes (including miners). Again, if your argument is that we remove the "peer-to-peer" as a requirement for bitcoin, then I disagree.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Ergo, miners are the ones with the incentive to arrive at the proper value for this crucial economic variable.

What direct incentive do they have? They have hardware limits. How do they know the limits of others? Why would we trust miners any more than we have to? Different miners have different incentives; if most miners are behind the GFW, bigger blocks insulate Chinese miners from orphan risk, while increasing the orphan risk of everyone outside of the GFW. Larger miners benefit from bigger blocks because they squeeze out smaller miners, increasing centralization pressure: https://www.reddit.com/r/bitcoin_devlist/comments/3bsvm9/mining_centralization_pressure_from_nonuniform/ So miners are not incentivized to keep the system peer-to-peer; larger miners tend towards centralizing behavior. And what incentive do miners have to retain node decentralization? None. Miners have no uniform incentive to protect the basic principles of the system which block size affects. Why would we grant them that power? Again, if your argument is that we remove the "peer-to-peer" as a requirement for bitcoin, then I disagree.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Quote

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

You make no sense. You are already working for free.

Doesn't mean that it doesn't cost my bandwidth to increase capacity rather than force users to pay the actual cost of confirmed transactions. Whether we are talking about nodes generally or mining nodes specifically, the implication is the same: users are not paying. The cost of their transactions is simply socialized among nodes. I am suggesting that transaction fees are integral for block rewards as subsidy drops, to incentivize miners to secure the system.

Quote from: jbreher on May 28, 2016, 03:07:22 AM

Quote

Bitcoin isn't a public service for users to transact for free -- it is an incentive-based economy.

The only possible incentives for operating a non-mining, fully-validating node are the ones you mentioned earlier - security and altruism. Well, maybe the ability to handle your transactions without needing to rely on others. Nevertheless, you don't get a share of the monetary incentives under any scenario. (kinda sad nodes are not renumerated, maybe someday the next satoshi will figure that problem out).

The point, again, was about block rewards. I'm not talking about incentives to run a non-mining node. As subsidy drops, non-subsidy reward must increase, all else equal, to retain the same security. With each halving, the cost (risk) of double-spending drops in half vs. reward.

Quote from: jbreher on May 28, 2016, 03:10:44 AM

Quote from: exstasie on May 28, 2016, 01:17:38 AM

Quote from: jbreher on May 28, 2016, 01:06:21 AM

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

A non-Segwit node can always validate transactions that are relevant to them. They do not validate the witness portion of Segwit transactions. They also do not generate Segwit addresses, nor do they participate in Segwit transactions. What you're talking about is moot.

What part of 'fully-validating node' do you not understand?

Why don't you begin by explaining the problem? Go ahead and explain the attack vector or consensus-critical bug that would be enabled. I know you like to repeat this line, but can you explain the significance?

As gmaxwell said:

Quote from: gmaxwell on May 29, 2016, 12:04:55 AM

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.