Topic: The Barry Silbert segwit2x agreement with >80% miner support. - page 63. (Read 120014 times)

It wouldn't have to fill up very quickly if the blocksize was variable and could only increase by finite increments.  It looks as though what I'm proposing is officially more moderate than what a significant number of your opponents are considering.  Plus the number of your opponents appears to be increasing.  There's probably not much time left to compromise before they put their plans into action and you potentially end up with 8MB blocks earlier than a variable approach would permit.  

I disagree somewhat. A chain split would mean a severe usability reduction. Every user that uses a certain number of Bitcoin services (e.g. exchanges, merchant sites, remittance services) is deprived from using a part of them in the case of a chain split if he doesn't want to use both chains. And using both chains is also a severe usability hassle (even if there were "multichain" clients).

Usage is what actually gives value to cryptocurrencies - without usage, they would be simply a software with no real use cases, because "low-to-zero" valued blockchains are easily attackable and wouldn't even usable as a Factom-style "notary" ledger.

So my stance is that alt-chains are a cleaner way to experiment with different implementations. If you are worried about the distribution of the supply, then your alt-chain can simply use a snapshot from the Bitcoin balances at a certain block (like "BTX" and "CLAMS" have done).

That's also why I support the agreement and only would support UASF in the case it has a real chance to get a supermajority of miners, exchanges/economy and users.

I can see franky1 posting but I can't see what he's saying since he's the number 1 ignore I have on at the moment. If someone feels his posts are pure trolling (as they normally are), point them out and I'll delete them.

how long it will take to move 46million outputs to be in segwit kypairs to then actually start utilising the witness area. hint. its not instantly filed just because of 'activation'

remember native keys can only fit ~2500 tx a block usually spending just 2 outputs on average (5000outputs spent per 10 minutes)
do the maths. (hint 9200 blocks minimum)
hint if every block was fill with tx that were ALL moving to segwit keypairs. it would take 2 months of mempool bloating drama to get every output over to segwit to achieve:
barrysilbert(2b:6w) base=2mb witness =2.2   4.2mb total weight

---

imagine spammers stayed with native keys and 75% of base block was native key.. only 25% of base block was segwit
bip9 segwit(1b:3w):
base=1mb witness =0.25   1.25mb total weight
silbertsegwit(2b:6w):
base=2mb witness =0.5   1.5mb total weight

imagine spammers stayed with native keys and 50% of base block was native key.. 50% of base block was segwit
bip9 segwit(1b:3w):
base=1mb witness =0.55   1.55mb total weight
silbertsegwit(2b:6w):
base=2mb witness =1   3mb total weight

imagine spammers stayed with native keys and 25% of base block was native key.. 75% of base block was segwit
bip9 segwit(1b:3w):
base=1mb witness =0.77   1.77mb total weight
silbertsegwit(2b:6w):
base=2mb witness =1.5   3.55mb total weight

imagine no spammers stayed with native keys and 100% of base block was segwit
bip9 segwit(1b:3w):
base=1mb witness =1.1   2.1mb total weight
silbertsegwit(2b:6w):
base=2mb witness =2.2   4.2mb total weight

Yes I acknowledge how big 8MB blocks would be potentially. Will they fill up immediately? I seriously doubt it will fill immediately but I do see demand for ~2MB of transactions easily in the current climate of transactions and we've already easily outgrown that. So why would I advocate for any more space than segwit alone provides?

A number of things that I'll list off the top of my head (no doubt there's much more I can't think of right now).
- I believe that there is room for more on-chain growth, even if we move micro-transactions off-chain (which I do believe is the answer to scaling to massive sizes.)
- If we assume bitcoin already needs double the space that it currently has based on current transaction volume, it means we should already be aiming for double that again at a minimum, and while segwit provides up to 4MB of transactions, it depends entirely on the type of transactions as to how much extra space will actually be available.  Given the most pessimistic estimate of 1.7MB that means we have already outgrown that capacity.
- Why should we aim for a blockchain that has up to 8MB of transactions per block instead of 1MB and require the extra storage? There's a self fulfilling prophecy there if you want to have more transactions on the chain; if you want to fit twice as many transactions you need to be providing twice as much space.
- Segwit transactions will allow one to throw away the signatures if they desire to ease storage space as an argument in favour of more segwit transactions. Yet there isn't a great deal of difference in concept between this and pruning nodes of classic transactions and blocks; if storage becomes prohibitive then nodes should set to prune which is working here and now very safely with running wallets. Yes we will see more pruned nodes in the future but we have the technology now to allow them to run fully validating nodes without necessarily storing every single block and transaction.
- Storage space and bandwidth has gotten cheaper. I'm not advocating for any planned continuous growth based on any outdated concepts like Moore's law but most of us can easily afford a lot more space and bandwidth now. 1MB has been manageable for a number of years now already. 8MB is much more I agree but again I can't see us suddenly going from 1 to 8MB just by activating the change.
- I am absolutely against the idea of a change of PoW and it has nothing to do with the fact that 95% of the mining is done with my software and I've gotten my place in bitcoin from the mining world. I firmly believe that any disruptive change of the size of a PoW change will cause massive destabilisation of bitcoin and it would take a long time to recover. Additionally any move towards an "asic resistant" algorithm is folly and purely a temporising measure. In the words of the hardware people I have worked with over the years: There is no such thing as an asic resistant algorithm. It's only a matter of time before we end up in exactly the same place we currently are with mining and at the cost of ridiculous instability in the meantime. For the record I have only a single 7TH miner to my name and I mostly use it only for testing since I can't even justify the electricity costs of running it here so it's clearly not because I'd lose my ability to mine. Additionally it would be trivial for me to create a pool for any other mining algorithm too. The reason I mention PoW is mining fees.
- Mining fees - love them or hate them depending on whether you're a miner or a user; if for argument's sake we do not want the network to fork off with a PoW change and fuck off all the miners out there, the reality is that segwit provides a degree of growth in transactions and consequently requires more resources - storage, bandwidth, even if it decreases cpu at verification, and yet does not provide more reward to miners. This is the sticking point that no doubt is pissing off the vast majority of Jihan's cohort. I was happy to sacrifice mining fees temporarily for the growth provided by segwit, though the rest of the mining world was not, but what happens after that?
- With lack of another scaling plan beyond segwit, and in all likelihood a network that will fill that capacity immediately, the only other way to expand transaction space without another technological advancement in scalability is by expanding the base block size.

I've intentionally omitted the quadratic scaling discussion because your argument was about storage space specifically.

I agree that the miner centralization is a design error of bitcoin, and its main problem is that when the mining pools get too few, they CAN sit in a room and decide upon something - in the same way that until recently, Core could decide upon something (and maybe still can, with difficulties).

In the ideally decentralized view (which bitcoin has never reached, and will never reach) with hundreds of small miners, tens of different development teams, and thousands of users, never colluding over anything, the only possibility is immutability - which is in fact the only REASON to want decentralization in the first place: to have the guarantee that the rules are graved in stone for ever.

Strictly speaking, 3 miner pools having each 33% of the hash rate, but NEVER colluding over anything, would still do the job of immutable protocol, decentralized system and permissionless system.  The problem is that with 3, the guarantee that 2 of them will never sit down together is weak.

It is very very funny to see people desiring a decentralized system asking for "people to sit together and come to an agreement".  Because that's what decentralization was supposed to avoid.

Not so sure ...

i know my post will get deleted but here goes

1. to even fill the 6mb witness area. people need to first move funds over to segwit key pairs. <- most important part
2. IF EVERY tx used segwit keypairs then the 2mb base will be filled but only ~2.2mb of the 6mb witness will be filled making 4.2mb data weight
3. comparison of bip9 segwit IF EVERY tx used segwit then the 1mb base will be filled but only ~1.1mb of the 3mb weight will be filled making 2.1mb data
4. to get to that point a majority of the 46m outputs need to be on sgwit keys for the majority of users to be spending 'segwit' outputs to achieve anything close to it

it would take alot of time, months/years if ever for a block to be bip9segwit 2.1mb of 4mb or BSsegwit 4.2mb of 8mb, due to the headache of moving funds across to new keypairs to dilute down the native keypairs that only utilise the base block

Yes - in ideal theory this might work - but still the imbalanced incentives (only miners) lead to centralization (sure proper metric needed ...) , and repulsive forces I cannot see much except keep code & rules = protocol as simple as possible (validity of blocks) than there should be room for more (best guess).

It is Satoshi's genius invention: have a decentralized system that obeys game theory in such a way that the Nash equilibrium coincides with "respecting the established rules" ; if there is no central authority any more deciding on those rules and having the (moral?) authority/raw power to force the change upon someone, this *locks in* the rules for ever.  In other words: Satoshi's genius invention is the notion of immutability in a decentralized system.

Tx - I had no deeper dive into that yet - interesting...

Whoohoo !  That's a whopping $30.- per year mining pools exchanges and other big actors will have to concede if they need to run a full node !

Another example of a Nash equilibrium, signalling, and the Tragedy of the Commons: the parable of the big barrel of wine:

http://www.chabadofmv.com/templates/blog/post_cdo/aid/1086982/PostID/17549


This is a logical game-theoretical outcome, also called the Tragedy of the Commons.

Each participant has two possible strategies: pouring in water, or pouring in wine.  The first strategy is less costly than the second one for any configuration.   In a barrel full of water, it would be outright stupid to pour one bottle of wine: what you will drink will essentially be water.  In a barrel full of wine, it would not change much to the outcome, you will be drinking wine, and it is cheaper to put in water.  Whatever the others do, putting in water and drinking what comes out is always better than putting in wine and still drinking what comes out.

This is why the Nash equilibrium of this system is a barrel full of water.  There is no way of obtaining a barrel full of wine.

[thumps cognition]

What makes you think that 2 MB base + 6 MB witness blocks aren't going to get filled up to the 8MB max very quickly? That's a potential 40GB+ of new blockchain per month, 360GB per year.

Are you stupid? Because it's either me or you that is

Bitcoin works in the community, so it always needs to vote by the majority, and we need to vote for the community benefit. Miners refuse it because when transaction costs decrease, they will exploit less, that is their selfishness. I want them to work in the community.

You mean, the expression "catch-22" ?

https://en.wikipedia.org/wiki/Catch-22_(logic)

Jumping to another Nash equilibrium is such a case.  Are you aware of the prisoners dilemma ?

https://en.wikipedia.org/wiki/Prisoner%27s_dilemma

It illustrates a kind of non-trivial Nash equilibrium.  "tragedy of the commons" is another game-theoretical catch-22 situation.

I don't know if this helps ?

Trace is a chuckle-head - he's the last guy you want explaining bitcoin forks to anyone. He's trying, but he doesn't really get it. Notice his banter about the bitcoin price at the beginning of the video? He suggests SPV wallets are "more secure because they run on top of bitcoin core"? Mmmmkayyy...

TLDR; UASF will never work

Sorry - could you pls elaborate a bit on that 'catch-22 in a decentralized system' ? What is the clou here?

I found this here but don't know much about the red line in it:

http://ascelibrary.org/doi/10.1061/%28ASCE%290733-9372%282006%29132%3A2%28149%29

Tx!

Follow-up on the game theory aspect of changing protocol:

Core had set up a very, very smart game-theoretical way of modifying the protocol that gave the impression that it was happening in a decentralized way: the signalling system.   Indeed, this seemed to solve the problem of individual entities needing to leave a Nash equilibrium for another one, which is game-theoretically impossible.  So how did Core defeat game theory (at first sight) ?

Well, the difficulty to leave a Nash equilibrium is that as individual entity, "changing strategy on your own" is a losing proposition (as by definition of Nash equilibrium).  However, "changing together with the others" can be a winning proposition, but that supposes collusion which is absent in a decentralized system (by definition).   In other words, every single entity needs to be SURE that a lot of other entities are going to switch to the new equilibrium in order for him to do this also, which is normally a catch-22 in a decentralized system ; moreover, this switch has to be simultaneous.  This is where the "signalling" comes in: signalling is not a change in strategy (you can stay in the current equilibrium) but you can express your "engagement" to switch at a given moment in the future.  If a very large majority engages itself into switching, then at that date, one can presume that the new equilibrium will be the one the system is in, and "remaining in the old equilibrium" is then the deviant position.

However, the caveat in this thing is that you need an *engagement* not just a *signal*.  Because at the given moment, you STILL don't know if the other entities will actually do what they signalled.  You might signal for something to trick some others in changing position, so that their loss is your gain.  But this is where Core's monopoly comes in: their software is such that the signal also triggers the switch, and most people are USING their software, so they have no choice but to switch.

==>  the signalling + engagement comes from the central authority of the software monopolist.  Other software might just as well signal but not switch.

Moreover, changing something can always be done in different ways, according to different variations of the protocol: if different competing propositions are out there, none will signal an overwhelming majority, and even less will assure the engagement behind the signalling, which brings us back to the original Nash equilibrium.

That's not the argument.  The argument is as follows.  Once upon a time, there was a centralized system that had a certain protocol to which all new incoming entities participating in it had to agree because if they didn't, the system would reject their disagreement.  Every system starts out as a centralized system, because one entity proposes it.  If that system becomes decentralized, that means, if there is no central authority any more that decides and is the unique entity proposing collective changes, then the participating entities are STILL adhering to the protocol they used up to then.  Now, I take decentralization as the fact that entities don't collude, but take their decisions individually and that no central entity has authority/power over any large set of entities.  In other words, I take a decentralized system as one where game theory is valid and entities behave as "free participants" that only decide for themselves, and are not bound by "collective agreements" ; however, they undergo also the consequences of their own strategies.  If such a system falls into a Nash equilibrium, then it can normally not leave it.
A Nash equilibrium is defined as a set of entities of which each entity applies an individual strategy, and is such, that for any given entity, if that entity is the ONLY one deviating from the Nash equilibrium strategy, the outcome for said entity is worse than if it kept to its equilibrium strategy.

Well, "keeping to the existing protocol" for all entities in a decentralized crypto like bitcoin, is a Nash equilibrium. If all the others keep to that strategy, and one single entity deviates from it, then this single entity will be in a worse position, no matter what it will pick as a deviating strategy, than if its strategy were "following the existing protocol".

Of course, there are MANY Nash equilibria.  There are as many Nash equilibria as there are thinkable protocols ! But ONCE you are in ONE Nash equilibrium the system cannot leave it.  It is only if there is a concerted effort that makes MANY entities decide TOGETHER to jump to another equilibrium, that this new equilibrium becomes the active Nash equilibrium ; however, BY DEFINITION, "a large part of all entities colluding" is exactly what is the end of decentralization, which, by hypothesis, means that entities don't collude.

So, a decentralized system (one in which entities don't collude and have no central leadership) where game theory is hence applicable, that finds itself in a Nash equilibrium, will remain in that Nash equilibrium for ever.  The Nash equilibrium being the protocol, it means that the protocol will remain the same for ever, hence is immutable.

QED.

Note that in bitcoin speak, Nash equilibrium is called consensus and defines implicitly a block chain protocol.

The only initiative a single entity can make, is to hard fork.  This kills potentially the Nash equilibrium if the hard fork is successful and has other entities joining it ; it remains the original Nash equilibrium if nobody follows and the fork dies: the forking entity made a wrong decision and lost, proving the Nash equilibrium of the original protocol.  If the fork is successful, the Nash equilibrium is gone, until a new one settles: one with the new chain, one with the old chain, or one with both, becoming distinct "ecosystems".

The only way the protocol can change, is through centralization (software monopoly, cartel formation of miners. ....) with central authority deciding and no alternative.  This was the state of bitcoin until recently, and maybe still somewhat, with Core the software monopolist and hence the central authority deciding with no alternative.