Topic: Gold collapsing. Bitcoin UP. - page 120. (Read 2032248 times)

It is clear that the people here are not so far apart after all. In reality it is differences of opinion on how to reach similar goals.

What is highlighted above would be fine if we were talking about a traditional centralized system, where a few people have control of all the software instances. Of course it would be possible to wait until there is actual tx congestion or fees tracking too high, unwise maybe, but very do-able, because it would be relatively quick to upgrade and continue as before.

With a decentralized system this is a luxury which does not exist, because the many instances within it are controlled by different people with different priorities, situations, political constraints, and speak different languages. A change that affects all of them needs to be given as much time as possible to be implemented.

Ideally, Satoshi should have listened to Jeff Garzik and caveden and implemented a flexible cap with his 1MB change in 2010. Done 5 years ago, the hard-fork would be a big fat nothing event as close to 100% of the full nodes in Bitcoin's network would be upgraded before the first >1MB block. If the change was done early in 2013, when the matter was heavily discussed, it would have given a 2-year delay before activation, so perhaps 95% of the full nodes would be upgraded. This is what BIP 100 assumes is still possible, but the 1Mb has become politicized so 95% is unlikely to be achievable and a rogue miner with 6% of the hash-rate could cripple Bitcoin long-term. So Gavin's BIP 101 assumes a 75% threshold, plus a grace period to help boost numbers. This is much more realistic but a rough hard-fork is now inevitable. The worst option is to wait until the change is obviously needed and try to do what Greg thinks is easy: a 2-week hard-fork. This might be easy for Core Dev gurus, but for thousands of full nodes this will come as a major shock, maybe leaving 50% of the nodes on each fork for a while. A "battle of the forks" might be an interesting and amusing real-world scenario test for cryptogeeks, but for 99% of Bitcoiners this would be a nightmare, they would be scared about the fate of their BTC, it would cause a serious loss of faith in this paradigm of new money.

Being preemptive about the 1MB reminds me of the Y2K situation. I spent a large chunk of 1998 on this as our company had 600 programs to change (requiring individual review) in just one sub-system, which also had 20 million abbreviated dates in the db and datafiles (requiring synchronized conversion with the programs), many of which existed from the 1980s when storage of all types was at a premium. The amount of testing required was laborious. Without this work the sub-system would have failed on Jan 1st 2000 costing the company tens of millions and making the name of the IT division "useless scum" in the minds of all the users. This was a centralized instance of software under the control of a handful of people. Even then the change was done over 1 year in advance of the Y2K date, and worked beautifully on the day.

TL:DR
If a software change needs 6 months or a year to happen then get it in progress 6 months or a year before it is needed by the user-base.

And I guess we will have to ask you if the fees are "appropriate" or not.

I had forgotten this gem.    Fortunately your personal opinions don't matter; this is not a centrally planned economy.

lightening transactiosn can support up to 2 tx per day for 7 billion people, within 2TB storage space and 133MB blocks.

lol, I do not understand why you do not want to create 1TB block. The bigger block the more spammers have to pay and the more miners will earn. I'll suggest to use infinite blocks and miners will earn infinite amount of $ and BTC.

I've conveniently forgotten nothing.  Your poor reading comprehension is pitiful, so I will charitably aid you by bolding the parts you most need to sound out until comprehension sets in.

spammers don't control size of blocks in a no limit scenario.  miners do.  so we won't have 1TB blocks b/c miners have the incentive to not destabilize or destroy the network so they will construct large enough blocks that are efficiently optimized so as to not get orphaned and not create significant decentralization of full nodes.  they will also raise their minfee to keep their mempool from destabilizing their full nodes and to keep users access open and readily accessible.  spammers will actually have to pay instead of just recycling their unwritten spam fees.

You've conveniently forgot this:


Did you agree?

Sorry, but this cannot be true. It is like perpetuum mobile. The bigger block the cheaper it is => let's are try 1 TB block => it must be free

that's a good point.

so what do you think about No Limit, which i would contend is a blend of the two BIPS, ie, it takes the block size determination out of the hands of core dev and puts it into the hands of a decentralized negotiated optimum btwn miners and users on a realtime basis going forward?

The value of money comes from future economic output.

The majority of entities that will produce the most economic value in the future is the majority that matters.

In many cases, people who have accumulated a large amount of money in the present have done so because they have a high capacity to produce economic value and so in their case they contribute significantly to the economic majority.

This is not true in all cases, however. Someone who obtained large amounts of money through luck or via processes which are not repeatable in the future don't contribute as much to the economic majority as their current holdings would suggest.

This is the primary flaw behind who try to frame debates in terms of "rich" vs "poor". They aren't being sufficiently precise.

So pretty much it is more costly to the spammer if miners just write the spam (or accept the tx) into the block chain.

Interesting.

BIP100 essentially takes the block size it out of the hands of developers and gives it to the miners.  They will decide if it grows or not.
BIP101 keeps block size as a centrally managed resource, pre-determined by developers, and if modification up or down is needed, it would need to be done by developers.

The weighting of your discussion suggests the developer centralization is a more serious concern, which suggests that BIP100 would be a strong favorite for you.

Personally I like BIP100 more also just because it does not have the hubris to attempt to predict what future changes to block size may be best suited for the protocol, and leaves those decisions to the future folks who will know better than we could possibly do now.
I also like that it decentralizes the management of the decision to the miners, which to me is a fine place for it.

That you favored BIP101 was the surprising part for me, I don't see why that would be the case considering your concerns.

It is about a majority of brain cells and intellectual authority.

I'm not sure I see the contradiction, my understanding is based on the situation we have now and it's a typical political one.

The moment we started to see mining pools and solo miners contributing hashing power with little regard to hard forks is when this trajectory started, I cant remember what the BIP was back in 2011/2, where miners had to choose which fork to support, back then I didn't care as it was the fundamentals that were important to me and that wasn't considered one given my limited understanding back then.  ( i just supported my "political mining pool by giving them my vote" to use as they saw fit.)

anyway I think all developers need a reason to develop and I'm happy with the idea that some will be commercial, however developers are just developing the code that runs the protocol. The people that invest in Bitcoin invest because they understand the incentive structure that makes the protocol possible.

Bitcoin is more about the network of current users than it is about the code, changing the code and protocol to appeal to old world industrious is not how we should be working, we want them to change to adopt Bitcoin.

I may be underestimating the concerns with centralized mining but I dont see it as an issue, miners will always mine the bitcoin that has the most users, and that typically is misunderstood as the most nodes, so long as miners do not have a say in changing the incentives in the protocol I see no problems moving forward with larger blocks. (Blockstream have crossed this line)

I am concerned that development is very centralized just a handful of people determine the code that runs on almost 99% of nodes, I favor many implementation of the code, not just Core, so in my view BIP100 and BIP101 are a political compromise to keep centralized development in the hands of a few.



 

Fundamentally, anyone with a vote, could also sell their vote.

Well, that was sort of just him trolling, (but he won't call it that), call it link-bait or whatever, but Matonis never really said any such thing.
Lawyerly parsing of his statements just say that many of the the arguments are in a similar form, not that he advocates for either.

I called him on it directly also.

any dev here want to work on adding a turing complete scripting platform (already existing, not ethereum) to the bitcoin core through a currently existing blockchain implementation? It will act as a testbed for bitcoin rolling forward. You will be compensated in existing blockchain tokens fairly. Looking for someone with good core bitcoin knowledge, it is a bit of work and it will truly decentralize things including all bitcoin clones (no need for sidechains). So if you want to take part in something that really will change things for the better let me know.

you mean the parts where nullc says, "UTXO is not in RAM", but yet we see this from him just 2 mo ago?:

https://www.reddit.com/r/Bitcoin/comments/35asg6/gavin_andresen_utxo_uhoh/cr2za45

or this part?:

I am very sure about what I said in the above quote.

As for Peter's tangentially related bet, that's already been covered:


Please keep up with the discussion and try not to slow down the rest of the class.