Topic: Bitcoin 20MB Fork - page 71. (Read 154787 times)

It would be quite helpful if we could collectively realize the direct significance of the lecture ideal money but I will continue to post clips that are related/prophetic:
I do not at all mean to suggest the consensus must be 100%, but rest assured there is some amount of "political" popularity the consensus must have because ultimately bitcoin is simply a bunch of people that have gotten together to agree...

If an important decision fragments the community too much then nothing really matters, you dissolve the entire movement.  We shouldn't need to show the maths or computations for that. I'm not sure if we realize this is the difficulty, and the only difficulty.  Those that are arguing clear points, from clearly sides, do not seem to fully grasp the difficulty of the issue.  In short, the trade offs do not permit "ideal-ness", and the logical argument is not necessarily going to align a large enough consensus.

What we seem to have gents (and ladies!), is a very clear game, possibly only akin to a complex PD, and what we are seemingly about to realize, is a new type of solution that brings about a new social paradigm. But what I am seeing, and my gift is only solutions and never to explain them...is many of the variables of this game cancel each other out...leaving only a SINGLE POSSIBLE FAVORABLE clear path forward...

100% consensus is not necessary.

The consensus of an economic majority is necessary, specifically an economic majority of Bitcoin investors, more specifically the investors who will present immediately after the fork.

If we imagine that any change will have less than 100% consensus, some existing investors will exit because of the change, and some new investors will enter because of the same.

If more enter than leave, the change will be successful. If more leave than enter, it will fail.

New investors will enter if they believe the change will make Bitcoin more to useful in the future.

Effectively the economic majority of future Bitcoin users decide which changes will be accepted and which will be rejected, based on the present Bitcoin actors' best guess about those future decisions.

but we mustn't forget that the nature of the problem is such that you need consensus otherwise there can be no change.

This suggests that any true change, is not necessarily to be completely ideal. So what is compromise, how much is needed and what is the equilibrium direction?

Ah, I think you've missed my perspective!  and possibly the very nature of this problem.  First in relation to money and what is considered "ideal", we should definitely consider 20 years of lectures on the subject: http://sites.stat.psu.edu/~babu/nash/money.pdf

And then of course we must consider what it is, in fact, that does create the wealth of the wealthiest "nations" http://www.gutenberg.org/files/3300/3300-h/3300-h.htm (AN INQUIRY INTO THE NATURE AND CAUSES OF THE WEALTH OF NATIONS. By Adam Smith)

It might be helpful as well, if you would be so kind to stand atop the great pyramid whilst we discuss this important matter:


And so truly we end up with the realization that CANNOT in fact have the ideal case, that by discovering a method or measurement then we might be able to choose what is ideal.  Because we are simultaneously asking the question of what that method should be.  Or in other words, because of a shit ton of backwards reverse engineering type maths, there has been a realization that there can be no consensus on the ideal.  Consensus will only come on some that is not ideal.

In other words there MUST be a single static consensus and it cannot then therefore be ideal...and so in light of such insanity the only logical solution would be to take the architects advice, and I simply point out the relation of his specific advice to the royal cubit.  We will tell the masses it is related perfectly to the pyramids, and that will make sense to them:

The ideal case is to recognize that whatever problem a protocol limit is believed to solve, it's being solved the wrong way, then solve the problem a better way, then remove the unnecessary limit.

Gavin is not claiming to know the optimal "cubit" size.  He doesn't know what the optimal size is, and would tell you that himself if he had the time.  What he is offering is his best guess at what the upper limit supportable is now and what it will be in the future.

It is, at best, an educated guess.  None of us know what the optimal size of the future is today.

People in the future may know what it is, or there may be a way to calculate it based on data that will be available then.

In the ideal case, we would discover this method of calculation, and that would let us avoid future forks over this same issue by the limit adjusting as needed, so that it never must be re-readdressed in order to "save Bitcoin".

I came from the same place we all came from, we just seem to have forgotten.  But to be clear I am only extrapolating the past from current knowledge (like pyramid archeology), as well as help from Szabo's concise article's and interesting lectures about "ideal money" and how it might come about.

I think though, we can take all this further and begin to take a look at what the market mechanism, voting system, or bargain might look like.  First we need to verify we see the problem correctly (I say "we", because I cannot self verify myself). It seems that the Architect (Gav), is suggesting after some initial pyramid data that there may in fact be an optimal "cubit" size.  There are those that recognize this and will support such a change and those that have their own ideas on what is optimal.  Since it must be some form of mass consensus only the popular ideas can win, and in fact it seems then we are left with the possibility of only the strongest (or well supported) concept in order to change, where as any amount of significant disagreement will necessarily produce "no change".

We can start to ask silly questions, such as how much will the change side be willing to pay the no change side, and what form of payments will they take?  In other words what is the market equilibrium in which you could offer enough incentive for those that do not support the most popular change to adopt/enact it?  

If enough players voted they would not accept any amount of incentive in order to make this change (especially to the royal cubit sized blocks), then it could be shown that no change could in fact take place.  What happens then if it can in fact be shown that there is some how enough incentive to transfer to those that could in fact be "bought"?

Nice analysis, but you omitted the influence of the version field change in the client B. I believe the whole rigamarole with that field is to lock the client B onto the new chain, although I haven't analyzed the details and considered all the possible attacks.
 

So, Mr. "Registered: 27 May 2014", where did you come from, and who exactly do you mean by "we"?

Oooohkay.  Let's consider the effect of a client that accepts and will cheerfully create >1Mb blocks.

Let's say I take a standard bitcoin client (client A) and create a new one (client B) that doesn't have a block size limit.  And then I start mining using client B.

Let's say that in a couple of days I make a block.  Cool.  So what's in my new block?  Because my client has been accepting blocks from the other clients, it won't repeat transactions that have already been in previous blocks.  It's looking at the same pool of outstanding transactions as everybody else.  So it'll include all the transactions from that pool that I choose to place in it, and likely have a block size between a quarter and a half-megabyte.  Everybody using client A is going to accept this block, because it follows all the existing protocols.  Then they're going to mine more blocks, and my client is going to accept those because they all follow my protocols.   And we can keep doing that for six or eight months.

But eventually after six months or so, let's say I get an 1100 kilobyte block (block B1, built on block A0).  It goes out on the network, and all the people running client A reject it.  Eventually somebody builds block A1 on block A0, because they rejected my block B1 as invalid.  And after that, A2 gets built on A1 before I get another block B2.  From my point of view it's indistinguishable from having an orphaned block.  As soon as I hear about A2, or maybe A3, I'll drop my B1 block because it's no longer on the longest chain.  From my point of view it's exactly like having a block orphaned for any other reason.

In fact, for as long as there's more hashing power using protocol A with the 1MB block limit, there will be no chain divergence possible.  There'll be no exclusively Chain-B coins, because client B will still accept client A blocks.  Every time the chain of <1Mb blocks gets longer, any chain that includes a >1Mb block will be orphaned. Even clients that find them acceptable will drop them when they aren't part of the longest chain.  And if there's more hashing power on protocol A, that'll happen before the coins from that first >1Mb block become spendable at a 100-block depth.

The next "interesting" thing that happens is when there's finally more hashing power on protocol B.  At this point a chain that includes a >1Mb block can get newer blocks built on it faster than the chain that includes only <1Mb blocks.  This is the point where an actual chain fork happens.  The majority of hashing power has shifted to protocol B, which allows chains that include >1Mb blocks, but a few holdouts, along with a bunch of crooks and their victims, stick with chain A.  

Now, here's the difference between holdouts, crooks, and victims.  A holdout continues to use chain-A outputs exclusively.  For a while, most holdout transactions are cheerfully accepted into both chain-A and chain-B blocks and cause no trouble.  But because chain A is now producing coins that are unspendable on chain B, and because crooks will eventually "taint" most chain-A outputs by double spending them, eventually holdout transactions cannot be placed into a blocks on chain B.  

A crook is using both chain A and chain B, and will spend pre-split outputs along with chain-B-only outputs in a tx on chain B (which gets rejected on chain A due to the chain-B outputs) then make a later tx on chain A to double-spend those pre-split outputs.  That makes it clear what a 'victim' is - a victim is the bagholder in the double spend.  Because he has not upgraded his client, he winds up with Bitcoins that have already been spent on chain B, which is now the main chain.  Victims can also find themselves in this position when they accept transactions from holdouts, if the holdouts have already dealt with crooks (ie, have double-spent coins) or are using chain-A-only outputs (ie, from coinbase tx which don't appear in chain B).  The holdouts may not care about the difference, but the victims sure as heck will.  

Here's the important thing about the post-split world.  Chain B is the majority of the hashing power, and every spend on chain A is also one of four things:  

a legitimate spend on chain B,  

an attempted double spend by a crook,

a spend by a holdout or crook that includes an output created in a previous double spend by a crook,

or a spend that includes coins (coinbase coins) that do not exist on chain B.

So for non-crooks, chain A is either irrelevant (your tx goes into both chains) or harmful (you get coins that are being or have already been double spent by crooks, or else coins from coinbases on an orphan chain).  The only reason to avoid switching to chain B, at the point where a fork actually becomes possible, is to preserve your ability to become someone's victim or the bagholder in an orphan chain.

In the last few seconds of this vid, Gavin raises an interesting point.  Non-financial transactions could start to push out more traditional transactions like we're currently used to if the limit stays at 1MB.  Do the anti-fork crowd have a solution to that which doesn't simply involve preventing those types of transaction  (because it's not in their vested interests to allow bitcoin to be useful for anything other than whales making big trades)? 

So then assuming we don't believe the story of a random ghost person posting a 9 page solution that radically changes the world nearly overnight...

It seems then that we could think about different ways to implement bitcoin from the get go.  And especially if we think in terms of building pyramids, there must then be successive iterations of such "structures". Other types of digital currencies that may have been useful only up and until a certain point (ie hash cash).  Knowing then that over history many such structures have been rebuilt using at least some remnants of old or "conquered" structures, we should expect then some extrapolations from past attempts projecting foreknowleagabe about how this iteration (bitcoin) may or may not work...

Putting a small limit on bitcoin initially then would be useful perhaps to reducing spam attacks (?), whereas at that stage a larger (but albeit) limit would possibly function the same as "no limit" (making adoption and price stabilization near impossible or impossible or more costly etc.). And so it may have been (or must have been) foreseen that in the future upon some x amount of acceptance (ie probably decentralized exchanges locking into equilibrium) that there would in fact need to be a consensus amongst the users (which should have the most political influence or at least enough vs the mining pools).  If we waited too long to have this discussion, such a discussion and an intelligent (or most or more useful) consensus, would be difficult, near impossible, or impossible to arrive at.

What is interesting is seemingly all major currencies in the world have been stabilizing vs bitocin in the last few weeks:


This does in fact seem to imply that the problem is really simply only consensus.  And such a problem could seemingly be solved with reason rather than conflict.  In other words, it is possibly that when viewed from the correct perspective, the consensus becomes immediate and obvious.  Sending the world into economic shock.

For example, is there a decision, that makes each of us bitcoin holders the richest fastest?  I'm sure the collective masses will "agree" to it.

Or in other words, I'm not sure reason is the reasonable course of action here.

(all this while we watch live as euro decides the fate of the ancient nation that helped us get here, and whether or not the euro currency might dissolve itself completely http://video.consilium.europa.eu/webcast.aspx?ticket=775-983-15407)

(I just picked up 5 euros with "bitreserve" just to make it fun and interesting

"Sources are saying that ‪#‎Eurogroup‬ statement is ready but ‪#‎Greek‬ minister is on the phone trying to get a yay or nay from ‪#‎Athens‬.")

O look. The pruning bullshit.

If everyones prunes the spent outputs, how does a full node synchronize from scratch?
From 'trusted' archive nodes? Gimme a break.

Some people may remember 'megauploads'.  The case is instructive.

As most here probably know, megauploads was a fairly generic file sharing locker, but one which happened to be especially successful.  At it's peak it accounted for a noticeable percentage of total global internet traffic.  Then, at the flip of a switch it was gone along with everyone's data who had been using the service no matter what the nature of the data.  Yes, the preponderance of the data probably was porn and copyrighted media, but certainly not all.

Additionally a special operations raid with helicopters and the whole works was undertaken to capture the geek who built the service.  The raid was performed by the Kiwi's, but under direction of their overloads in Washington.  The stated reason?  The guy once sent a private e-mail around asking if someone knew if/where a particular copyrighted movie that he wanted to watch might be to be had.  The guy and some of his employees spent a number of days in jail and to this day lives under threat of being extradited to the U.S.

This kind of action was driven by political machinations of a group of copyright owners centered in California.  The power they hold compared to the power of the global financial systems is tiny so it is completely anticipated that the level of pressure and the level of unfairness which Bitcoin could expect if we threaten the financial system in a noticeable way is enormous.  It would be folly to expect better treatment than Dotcom got.

Why was it so trivial to shut down megauploads?  All of the gear and networks that the service used were trivial to identify and valuable to the owners.  All the U.S. had to do was to tell the equipment owners to drop megauploads as a customer and they complied within minutes.  I remember pics of a Carpathia cage which was totally shut down and sitting idle in some datacenter while Dotcom's 'crimes' were investigated.  I think I may have seen that very cage with my own eyes when I was doing some work in an East Coast datacenter one time, but most of these cages look the same so I'm not sure.

Anyway, the upshot is that people who live under the assumption that somehow 'freedom' and 'fairness' is going to protect the Bitcoin network if the mainstream financial players, and thus U.S. govt, wants it shut down are living in a fantasy la-la-land.  There are several things which could keep it going:

 - It more useful alive than dead to the existing powers that be, and/or

 - It is decentralized and supported by gear which is both cloakable and dispensable by the operators.  There wound need be a lot of potential operators and they can be born anywhere and pop up anywhere overnight.

To me, Bitcoin is no stronger than it's ability to deal with an attack such as was undertaken against Kim Dotcom.  The megauploads attack was not some hypothetical.  It happend, and the power structures driving it have only become stronger and more totalitarian since that time.

---

Well, lookee here what I found when seeing if I spelled Carpathia correctly:  http://carpathia.com/blog/vmware-vcloud-government-service-and-carpathia-achieves-fedramp-ato/  Looks like from a corporate perspective they made a good decision when they confiscated millions of user's data.

Yes, more hardware requirement==more centralisation. But if the devs don't forget to implement the optimizations part of the plans (i.e. "The Future Looks Bright" in https://blog.bitcoinfoundation.org/a-scalability-roadmap/) then everyone can run a full peer node in the future just as easy as now.

Would there be much harm to the existing bitcoin ecosystem if someone released the gavincoin patch today?  (e.g. takes Bitcoin client such as v0.9.2 and simply changes the max to 20MB (or anything above 1MB), sets block nVersion=4, and maybe uses some other network port number).

I would like to see this as it will help us quickly learn the lesson about post-fork fungibility.

Why would anyone mine using this client (or join a pool using it)?   Well, because there is demand for gavincoins.  Why is there demand?  Post-fork there will be two chains.  All 13.8 million bitcoins pre-fork are spendable on the gavincoin side as well but if the transaction includes any amount of a gavincoin coinbase the transaction will be rejected on the Bitcoin side.

Initially many of those holding bitcoins (myself included) will want to buy a tiny bit of gavincoin to have some to be able to taint their bitcoins that will then be spent using the gavincoin client.  Even if the value of these tainted coins is a pretty trivial amount I probably will still want to sell them for whatever I can get since spending them doesn't impact my ability to use those same coins for spending on the Bitcoin side -- as that side knows nothing about the spend transaction from the gavincoin side (for those transactions that include any amount of gavincoin coinbase).

Because there is this initial demand for these gavincoins it won't take long for an exchange to pop up that offers BTC/GAV trading.  (If you still aren't convinced that a market exists, simply look at the orderbooks with  buy orders for all those shitcoins).

All then that is needed is a pool to mine using the gavincoin client which attracts at least ~6,650 Th/s (roughly $2.8M worth of the latest ASIC hardware) to cause the gavincoin side to get three blocks per day (the current Bitcoin transaction load is roughly 60MB per day so that daily load could be included in three blocks of 20MB each).   Also if this gavincoin client is using a different network port number someone would need to re-broadcast the bitcoin transactions onto the gavincoin fork (and maybe vice-versa so that all transactions that can confirm on both sides of the fork are broadcast on both sides.)

So let's say this gavincoin client comes out today and within a few days the first block on the gavincoin side is mined.    There should be no risk to the Bitcoin side of the fork as far as I can see --  at least not initially.  Now the gavincoin side ... that wlll have so little hashing capacity so those exchanges accepting gavincoin payments need to consider that a 51% attack against that side of the fork is certainly possible [Edit: after difficulty adjusts down on the gavincoin side a few times].

Then watch and see what happens.   Maybe both sides co-exist permanently, who knows.

[Edit: There is however the risk of a transaction that gets made with the intention of it being a gavincoin transaction but then it gets misconstructed where it includes only valid Bitcoins.  Since that transaction wouldn't have any gavincoin taint it will confirm on the Bitcoin side.  That gives the recipient the valuable bitcoins instead of the low-valued gavincoins.]

[Update: Also, the gavincoins generated are not spendable until they have 100 confirmations -- so that'ld take a month at only 3 blocks / day before a single "tainting" transaction could occur.]

[Update 2: A catalyst for the fork would be needed.  For that the Gavincoin patch could set a future block number as where the fork will begin and beginning with that block only blocks with nVersion=4 would be valid.]

[Various minor edits for clarity and readability.]

This is FUD. 

There is no transaction acceptable to the current network that is unacceptable with a larger block size.  There is no transaction unacceptable to the current network that would become acceptable with a larger block size.  No "incompatibility" is being proposed.  The block size issue is strictly about scale, not about features. 

The point at which old and new chains diverge is the point at which the old chain cannot handle the transaction volume.  And if it can't handle the transaction volume, it's going to fail anyway.

Who are you working for?  Who is putting up the money to try to stop Bitcoin from scaling?

I ask, not because I think you'll give an honest answer, but because the other people you're talking to need to see and think about this question.

But we will need it eventually if we are aiming for global mainstream use.
A fork then would be much worse than doing it now while its still a geek thing.

Not really in-depth.

Interesting opinion, thanks davout.

---

I've find this old video about the blocksize/decentralization : https://www.youtube.com/watch?v=cZp7UGgBR0I    Maybe someone is interested to see it and tell his opinion.