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

An accelerated delivery is not always a good thing for development quality.

I'm more of the opinion that Bitcoin will succeed, provided that it does not fail, and that a misstep can easily be worse than doing nothing.
Intelligent people may disagree with this.

Other less measurable, but nonetheless actual result, is the increasing pace
at which "layer 2" solutions are developed (Lightning Network, Sidechain, Payment
channels implementations etc etc).

So the answer to your question:
 

is still: I don't know, because it is impossible to determine his real intention.

Speculating about what? I am sorry, but the only speculative statement in the above posts between you and I is the part where you assume Gavin was just acting, just doing this for the effect it would have. Again, that's not what he said, he has not retracted what he did say to confess his secret altruistic plan to get everyone talking, nor confessed the ulterior motive you are affording him.

How do you know that his intention was not to stage a dev-team coup?

I've come to see a single core as being the single greatest threat to Bitcoin out of all of this. A better situation to me would be a bitcoin P2P network with several separately developed cores that adhere to a common set of rules. The upgrade path is then always put to a vote. Any one core could then propose a change simply by implementing it (with a rule that after x% of blocks back the change it becomes active).

Then if people like the change, more will move to that core. This in turn would cause the other core to adopt the change or lose their users, and that is how consensus is achieved. If a majority did not like the change, they would not move to that core, and the change would never be accepted.

At no point in this do any set of gatekeepers get to dictate terms. Since no core has a majority of users captured, change would always have to come through user acceptance and adoption, and developers would simply be proposers of options.

Sure facts are facts, while speculation is another thing entirely.

Gaving did something and community at large react to his stimulation.

And I prise community reactions, in particular core devs reaction.  

From what I can see we're moving forward in the process of finding
a way to make bitcoin scale.

Just to make an example in the beginning of the debate a lot of devs
(core or not) did not acknowledge that a block size increase was needed
Now almost everybody, modulo mircea popescu and mpex group, agree
about some sort of increase.

This is a result of Gavin action, and I say a positive one.

Other less measurable, but nonetheless actual result, is the increasing pace
at which "layer 2" solutions are developed (Lightning Network, Sidechain, Payment
channels implementations etc etc).

I'm less interested in rushing the hard fork than I was, now that it seems less likely that Bitcoin breaks due to full blocks.

Telling the entire core dev team, the commercial bitcoin players and the bitcoin user community that if they didn't like it, they were powerless to stop him? This is friendly gesture in your eyes?

I'm not even being rhetorical using the word "hostile", Gavin and Mike's attitude was exactly that: hostile.

Telling the entire core dev team, the commercial bitcoin players and the bitcoin user community that if they didn't like it, they were powerless to stop him? This is friendly gesture in your eyes?

Well, the facts are that Gavin literally did just that; an alternative, hardforked client with a 20 MB block limit, and anyone from the core deve team that didn't like that could watch while he lobbies miners, services and merchants to accept the new client. That was what he said, he has not retracted it, nor confessed the ulterior motive you are affording him. Those are the facts, are they not?

I'm less interested in rushing the hard fork than I was, now that it seems less likely that Bitcoin breaks due to full blocks.

let's list a few of the tactics employed by the Blockstream devs:

1.  appeal to authority- "the entire dev/technical community is against this"-which they're not if you look outside core dev.
2.  scare tactics- "if Bitcoin forks, it will fail"
3.  character assassination- "Gavin hasn't coded for over a year", "we are shocked by his behavior", "he's out courting merchants, exchanges, & miners behind our backs".

i honestly ask you, which of the 3 tactics has Gavin employed on Reddit or here?  my answer is NONE.  and here we yet another example of #2 tonite by gmax:

https://www.reddit.com/r/Bitcoin/comments/3awomg/how_the_bitcoin_experiment_might_fail/

he's getting pounded too.  and these are the reasons Blockstream will lose in the end.  no one trusts them.

[–]nullcGreg Maxwell - Bitcoin Expert 14 points 1 month ago*

To give an external perspective from Luke's on this;

I now agree that BIP17 was better; not just slightly better but very clearly better in important, meaningful ways.

At the time I preferred BIP16, in hindsight I made an error in reasoning-- part of this was that I incorrectly believed that the difference was smaller than it actually was: There were substantial differences in terms of limitations of P2SH that none of us (probably not even Luke) understood at the time. (I say not even Luke because Luke's primary argument was about the "aesthetics" of the implementation, which were not-- by themselves-- that persuasive to anyone.)

A lack of care in this deployment resulted in substantial non-trivial (3-5 blocks) network forks for a period of about two months. BIP16's irregularity resulted in alternative implementers being somewhat slower to implement and more error prone. Luke just gave a concrete example (the idiotic 520 byte limit; which I think we didn't even realize existed in BIP16 at the time, spec was updated later to mention it); another is that you can't combine multiple P2SH scripts, e.g. to get an OR where you can spend a coin with either a small script or a big one-- that one we knew existed but didn't give adequate thought to, it's turned out to be a rather annoying limitation.

At the time the fact that the BIP16 approach had more testing and work on it, especially after the embarrassing design reboot after OP_EVAL turned out to be vulnerability introducing, and Gavin's strong preference for it, combined with the assessment of "little difference" made me prefer BIP16; as anything else would have meant additional delays. In reality, it was basically years before there was widespread P2SH use, an additional delay would have been better. It's worth noting that the person (roconnor) who found the OP_EVAL flaw also preferred BIP17-- which was probably a sign we should have paid more attention to. It's not a big regret but I do consider it a lesson.

It didn't help that some people (mostly not Luke himself) tried to construct a public drama with non-technical community members over what was still just a kind of boring technical argument. Unfortunately; trying to make drama can have exactly the opposite effect of embedding people in their positions and making them immune to reason. It's almost universally a bad move if you care about achieving a high quality result. I keep trying to remind myself of the importance of deciding to be immune to political drama in order to avoid the failure modes it creates if you let it influence you.

You can see a chart of opinions at the time: https://en.bitcoin.it/wiki/P2SH_Votes BIP16 was a condorcet winner; but most people considered either approach acceptable.

the reasons Blockstream will lose in the end.  no one trusts them.

no one cares for your socialist, elitist view

Here's what inevitably happens to poor cypherdoc when he bothers me:

https://www.youtube.com/watch?v=fnSpeGlc9ic

It's been going on for years but the guy never seems to learn.

And I only wanted to box  

Me and cypherdoc:  https://www.youtube.com/watch?v=8qoys8eUn9k

Perhaps the bitcoin economy has matured enough that a set max block size is not actually needed anymore?!

What if we had some type of patch that eliminated "silly sized blocks" and allowed miners to set any soft limit they want? Have it something like: allow any size as long as it's not more than x3 (or other number) the previous months average block size.

Market incentives will drive each mining pools soft limits. Increasing the limits will stimulate growth (increase centralization if done too fast compared to technology because of resources needed) while smaller blocks will increase fees. Some may like smaller blocks because of risk of orphans while others will want large blocks to grow the user base of people using bitcoins. Allowing a x3 size block means that as long as a minority are making small blocks, those who want larger ones can still help grow the "silly size" limit and those who have weak internet connections just have to download the blocks and can continue making small ones.

A spam attacker could only create large blocks that were bigger than all the pools soft limits only by mining it himself and the largest block he could create would be a x3 of the blocks on the system. And just like it's in their economic self interest to not get bigger than 51% it would also be in pools own self interest to not have a soft limit that would risk too much centralization of the system by making it too large for current technology and allows for the system to rapidly adapt at the time. The fact that most mining is done by pools means that the soft limit can be more fluid.

Ultimately if we let pools set any limit they want would they set limits that would allow bitcoin to thrive? If we assume the majority of pools act in the interest of a growing decentralized system would max block size be needed anymore other than something to prevent a "silly size" block?

Fun watching u two dance.. Get a room already! :p