Gold collapsing. Bitcoin UP.

[iCEBREAKER]

Gavin's strength is his maturity and calm demeanor, imo.  he'll win if it comes down to a battle.

Nope.  Szatoshi will back Back and Maxwell.  The cypherpunks will stick together (or hang separately).

You should change your handle to 'FrappuccinoDoc.'   

[1713532977]

1713532977

[1713532977]

1713532977

[1713532977]

1713532977

[1713532977]

1713532977

[cypherdoc]

Against rewriting an entire codebase
http://www.joelonsoftware.com/articles/fog0000000069.html

On the importance of having a spec
http://www.joelonsoftware.com/articles/fog0000000036.html
http://www.joelonsoftware.com/articles/fog0000000035.html

that was a great read. thanx.

i had suspected as much.  not being a coder but watching dozens of coders here and on reddit criticize bitterly not only Bitcoin's code but other code as well, i always got the feeling that it is just a given that everyone criticizes everyone elses code either out of envy or just trying to appear smarter than everyone else.  it's not like anyone can really tell or hold them accountable.  Peter Todd fell right into that trap yesterday on LTB with that stupid remark that Satoshi made a mistake.  just who the hell is Peter Todd?  answer: just an armchair critic who hasn't done anything significant with his life.  Satoshi was the best thing that ever happened to him; he provided himself as a target that can't defend himself from the likes of Peter.

[marcus_of_augustus]

Gavin's strength is his maturity and calm demeanor, imo.  he'll win if it comes down to a battle.

Nope.  Szatoshi will back Back and Maxwell.  The cypherpunks will stick together (or hang separately).

You should change your handle to 'FrappuccinoDoc.'  

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it or them. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

[cypherdoc]

Gavin's strength is his maturity and calm demeanor, imo.  he'll win if it comes down to a battle.

Nope.  Szatoshi will back Back and Maxwell.  The cypherpunks will stick together (or hang separately).

You should change your handle to 'FrappuccinoDoc.'  

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

both versions are on github.  Hearn's claims there is only 2 functional differences.

how hard would it to run a diff?  shouldn't be.  have you?

[79b79aa8d5047da6d3XX]

I'm working for Nick Szabo.

Szatoshi will back Back and Maxwell.

enough with the hints, spill the beans please.

[Patel]

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

wish there was a thanks button on BCT

[sickpig]

I singled out the first posts by 2 core Devs. to get a taste for there personality in the wild - early days when everyone was working nicely.  (note if you read it, many other devs. are quite encouraging.)
https://bitcointalk.org/index.php?topic=122013.msg1331489#msg1331489
https://bitcointalk.org/index.php?topic=122013.msg1389749#msg1389749

Sorry need to quote the first one explicitly:

All rules I found are enforced. I am eager to learn any outstanding.
The biggest deliverable is serious testing.
I would love to get this production ready this year, but since I only work on this on my spare time and my family has other plans with me around Christmas, I can not commit.

Okay. You're missing at least one important rule, but I don't know what else is missing that I missed in review.

Unless you object, I'm contemplating keeping this missing rule to myself for now so that it can function as a test of the testing. E.g. if the test don't find it, they're incomplete.  Obviously I don't want to withhold information which could undermine the network, but absent better testing the software shouldn't be in production use anyways... and there are scarcely few good ways of testing the tests.   Does this sound reasonable to you?

My english vocabulary is not wide enough to define how presumptuous gmaxwell's reply was. Thanks for the pointer Adrian, very informative.

[solex]

...
There are issues among such a group of people that we probably can't hope to understand. The politics, the interpersonal clashes, the miscommunications, the lingering grudges tinting things. Again, I think your implication may be right, this may be more a social issue than a technical one.

Interesting. I decided to read all Greg's recent posts and found one which makes his position much clearer.

There is a soft blocksize limit in addition to the hard one. Originally it wasn't easy to adjust. We ran into the soft limit, and were pushing into it for months at a time back at the end of 2012 and beginning of 2013. Transactions slowed down and there was some complaining, but the wheels did not fall off and Bitcoin's adoption grew substantially during that time. A lot of technical innovation happened then-- in particular replace-by-fee was invented and child-pays-for-parent was deployed. After the soft limits were increased, development on these improvements went fallow, sadly (e.g. CFPF was never merged, or matured to a merge ready state, in Bitcoin Core).
The experience we have says there will not likely be a dire emergency. We also have reason to believe, from the prior accidental quasi-hardfork, that the mining portion of the network can be updated within a day or two during an actual emergency. A straight-forward blocksize bump also has the benefit of being completely compatible with existing SPV clients (they can't see the blocksize). If there really were a dire situation where it was larger blocks or doom-- I'm confident that larger blocks could be deployed quickly without much trouble; and in that kind of situation: consensus would be easy. No matter how concerned people are about larger sizes, if the choice is really larger or a useless network, the former is preferable to everyone. There is also plenty of room for other creativity, as we saw before in 2013, should the need arise, but it can be hard to predict in advance.

He doesn't really want to engage in the mechanics of a block size increase right now, because his opinion is that the limit can be safely maxed out. I wish he had said this a couple of years ago in BCT because then the pros-and-cons of letting the limit be hit could have been hammered out before the question of how to change the limit needed addressing (which is the case now). Maybe he didn't say this two years ago because it wasn't his position then?

Compromise is very difficult when one side does not recognize that an urgent problem, or even just that a problem, exists.

He is looking at it from a very technical level. Advantages of hitting the limit is speeding the development of some software components, work in adversity etc, the downside is non-technical: a PR disaster, collapsing price, loss of VC enthusiasm, academics noting that a decentralized community cannot be trusted to manage a global currency. IMHO, these downsides far outweigh the technical, software benefits. It is simply playing with fire.

He also forgets that not all mining pools obeyed the soft-limits in 2013. A few didn't. e.g. when the soft-limit was 250KB Eligius was mining 500, when the soft-limit was 500 Eligius mined 750. There was always some level of extra capacity which does not exist at 1MB.

He repeatedly says that he is worried about centralization, loss of nodes. Well, the fact is the fastest way to kill^*off the most nodes at once is to quickly deploy a hard-fork. A hard-fork needs as much time as possible to be as smooth as possible, maintaining the network intact.

^*Nodes left on an old fork are not guaranteed to upgrade, some will just switch off.

[hdbuck]

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

wish there was a thanks button on BCT

ah but you can always unintentionally "kudos" gavin's blog posts.



edit: ninjakudos! ^^

[Zangelbert Bingledack]

He doesn't really want to engage in the mechanics of a block size increase right now, because his opinion is that the limit can be safely maxed out. I wish he had said this a couple of years ago in BCT because then the pros-and-cons of letting the limit be hit could have been hammered out before the question of how to change the limit needed addressing (which is the case now). Maybe he didn't say this two years ago because it wasn't his position then?

Compromise is very difficult when one side does not recognize that an urgent problem, or even just that a problem, exists.

Exactly. There's this weird mismatch in that he should be saying this *first* whenever the debate comes up. I didn't see him even comment on Mike Hearn's "Crash Landing" post, which is nevertheless the one everyone remembers and has in the back of their mind and directly opposes this position.

It's almost like he somehow wants to remain in his pessimistic curmudgeonly state, like he has a vested interest in it (not financial, but emotional/social). He has a way of not addressing the most key issues while looking like he is and looking like he's being the reasonable one. Now that I've read the Press Center thing I can see some parallels.

One classic Gmax thing is to make every statement interpretable in a safe way. For example, today's reddit post where someone was accusing Peter Todd of being biased against an increase because of his affiliation with Viacoin. I don't think there is much merit to the accusation (though that doesn't excuse Todd's sensationalism), but in Greg's reply he said, "Welcome to Reddit, 'Viacoin66'!"

He will say something that looks safe and unantagonizing (just the standard Reddit welcome), but his real purpose is to point out that the account was bran new and imply that it was obviously created to troll Viacoin/Todd. He's probably right about that, but nevertheless it's an example of what I mean where he'll say whatever serves any sort of low-blow purpose in a debate as long as it can be interpreted as not being that. I guess with his security testing mindset he has become Mr. Plausible Deniability.

OK, it's true that a lot of people do things similar to this in debate, but he has it down to an art. It has the effect of making him look blameless unless you know all the context and read between the lines. Again, I suspect this is part of core dev culture, where there is a lot of pressure not to appear inflammatory. Remember Gavin talking about "poisonous people" ruining projects (though he was talking about Luke)?

[Zangelbert Bingledack]

For completeness, here's Jeff Garzik's view, emphasis mine:

I have a lot more written down, a WIP; here are the highlights.

- The 1MB limit is an ancient anti-spam limit, and needs to go.

- The 1MB limit is economically entrenched at this point, and cannot be
removed at a whim.

- This is a major change to the economics of a $3.2B system.  This change
picks winners and losers.  There is attendant moral hazard.

- The core dev team is not and should not be an FOMC.

- The bar for "major economic change to a $3.2B system" should necessarily
be high.  In the more boring world of investments, this would accompanied
by Due Diligence including but not limited to projections for success,
failure scenarios, upside risks and downside risks.  Projections and
fact-based simulations.

- There are significant disruption risks on the pro (change it) and con
(keep 1MB) sides of the debate.

- People are privately lobbying Gavin for this.  That is the wrong way to
go.   I have pushed for a more public debate, and public endorsements (or
condemnations) from major miners, merchants, payment processors,
stackholders, ...   It is unfair to criticize Gavin to doing this.

Matt Corallo is "rather strongly against any commitment to a block increase in the near future [without more testing]," but seems like he'd go definitely along with at least some increase on Gavin's time frame (if testing panned out), because when asked by Mike Hearn whether he had a specific, credible alternative to Gavin's plan, he said:

Yes, doing more research into this and developing software around supporting larger block sizes so people feel comfortable
doing it in six months.

Wladimir van der Laan, who seems to be Gavin's appointed lead for the project now, is "weakly against in the near future" because the solution seems to delay better ones. Seems he'd go along if it came down to a fork:

I understand the advantages of scaling, I do not doubt a block size increase will *work* Although there may be unforseen issues, I'm confident they'll be resolved. However, it may well make Bitcoin less useful for what sets it apart from other systems in the first place: the possibility for people to run their own own "bank" without special investment in connectivity and computing hardware.

I really don't think we are far from consensus at all, especially for 4-8MB after "more testing" (and especially when there is more urgency). Gmax seems the only real holdout, and even he is for 50% increases repeatedly. Adam Back is still pinning hopes on alternative solutions but I think would go along if it came down to the wire. As for Peter Todd, I'm not sure how much count to give him as he's a little too drama-queenish - if attention moves to XT we know where he'll be

[solex]

All good points. And yes, Greg's posts are full of clever sub-texts.

He did reply in the dev & tech on Mike's article, but only to hand-wave it away:
https://bitcointalk.org/index.php?topic=1054181.msg11318788#msg11318788

It remains curious to me that such a strongly written article was largely ignored by the dev & tech contributors, who sometimes debate the minutiae of an obscure software topic. There was no attempt to determine whether Mike is broadly right or not, and maybe Greg's reply "put-off" other people echoing the concerns.

Those quotes are nice to see in one place. Some evidence of flexibility overall.

Yes, Luke was tagged "poisonous". He runs Eligius which I mentioned earlier, never played ball when the soft-limits were being tested, though Greg omits this fact, and any criticism of Luke for it.

[Zangelbert Bingledack]

He did reply in the dev & tech on Mike's article, but only to hand-wave it away:
https://bitcointalk.org/index.php?topic=1054181.msg11318788#msg11318788

It remains curious to me that such a strongly written article was largely ignored by the dev & tech contributors, who sometimes debate the minutiae of an obscure software topic. There was no attempt to determine whether Mike is broadly right or not, and maybe Greg's reply "put-off" other people echoing the concerns.

I did feel that Mike was pushing his points a little unfairly at times in the article, but then it should be relatively easy to bat them down. Greg's response was decent, especially his first point, but it seems like something that will come down to technical points I wouldn't know enough about to judge.  I went ahead and bumped the thread in hopes of getting more responses.

The fact that Greg neglected to point out the Elegius pool's ruining the "test" at the soft limits shows his propensity to grasp at whatever straws look plausibly available as long as it will advance the stance he wants to defend. (Again an unfortunately common debating practice, even in Mike's article and this thread, but once again Greg has it down to an art. Mike it's easy to tell he's doing it; Greg not so much.)

I also note that Matt Corallo actually pointed out that the lack of discussion on some points and seemed to find it odd as well. Sounds again like something interpersonal.

[justusranvier]

but there is truth to the fact that those embedded bugs and general messiness somehow "contribute" to the behavior of how the system works in unknowable but apparently predictable and stable ways which seem to work.  by changing those bugs or trying to clean up the mess, someone somewhere along the line will disrupt the predictability to where how the code operates may become unstable or unpredictable.  that would be bad.

The problem is that there are two very different things in play here:

• How humans think the Bitcoin protocol behaves
• What Bitcoin Core actually does

There is no case where a divergence between these two things is good. It means that despite years of effort Bitcoin Core is in some ways still a black box capable of surprising behaviour instead of predictable behaviour.

We have no guarantee that Bitcoin Core is self-consistent (like it wasn't in March 2013). Due to the way that code was written, it's likely that we never will have such a guarantee.

The only way out of this mess is to deprecate Bitcoin Core in favour of more-specifiable implementations as rapidly as possible.

If Bitcoin Core (and derivatives) were a minority of the nodes in the network, then the next time one of Bitcoin Core's surprises manifested it would be a problem that a minority of the network would need to fix instead of newly-discovered behaviour that the entire network would need to implement.

it would take someone or some group truly exceptional to be able to rewrite the entire code and have it function exactly like it does today.  and with billions on the line, that would be a tremendous responsibility for a volunteer, would it not?

That work has already been done by the authors of btcd (btcsuite).

They do have some truly exceptional developers, particularly davec.

That he receives snubbing, derision, and personal attack for his efforts is a major example of how toxic and dysfunctional the Bitcoin development culture has become.

Nope.  Szatoshi will back Back and Maxwell.  The cypherpunks will stick together (or hang separately).

Some cypherpunks would do well to engage in soul searching regarding the question of so many of their flagship efforts (PGP) have been market failures.

Knowledge of cryptography doesn't automatically translate into understanding business, economics, engineering, or interface design.

[sickpig]

We have no guarantee that Bitcoin Core is self-consistent (like it wasn't in March 2013). Due to the way that code was written, it's likely that we never will have such a guarantee.

If memory serves 2013 hardfork was more a "dependency" bug imho. Client with ver <= 0.8.0 cant's store block bigger than 512KB due to a Berkeley db default misconfiguration. It could have happened with any other external tool used by the client.

That said I fully agree that we need to decouple the protocol definition from bitcoin core.

In that regard what do you think about the plan to isolate the consensus code in a separete library?

[justusranvier]

If memory serves 2013 hardfork was more a "dependency" bug imho. Client with ver <= 0.8.0 cant's store block bigger than 512KB due to a Berkeley db default misconfiguration. It could have happened with any other external tool used by the client.

The bug wasn't nearly so deterministic. Whether or not a particular block would trigger the bug depended on the runtime history of a particular node (when they started downloading blocks, how many orphans they had observed, etc) meaning that binary-identical versions of Bitcoin Core running on machines with identical hardware could exhibit divergent behaviour based on them connecting to different peers at different times.

In that regard what do you think about the plan to isolate the consensus code in a separete library?

Would have been a good idea to do from the beginning. I'm not sure if the existing code can be cleaned up well enough to make a meaningful difference.

[Natalia_AnatolioPAMM]

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

wish there was a thanks button on BCT

same with me

[cypherdoc]

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

wish there was a thanks button on BCT

same with me

he posts the same BS over on Reddit.

[cypherdoc]

Wladimir van der Laan, who seems to be Gavin's appointed lead for the project now, is "weakly against in the near future" because the solution seems to delay better ones. Seems he'd go along if it came down to a fork:

I understand the advantages of scaling, I do not doubt a block size increase will *work* Although there may be unforseen issues, I'm confident they'll be resolved. However, it may well make Bitcoin less useful for what sets it apart from other systems in the first place: the possibility for people to run their own own "bank" without special investment in connectivity and computing hardware.

see, this is where i think the devs understandably relate to the wrong fundamental unit of the system; the full node as opposed to the user.

no, the individuals bank is not the full node, it's the user and his wallet.  yes, to a degree, the security of that wallet depends on full nodes and miners but fundamentally it's the user and his wallet and why so much emphasis is placed on it via security R&D and specialized wallet implementations.  MetCalfe's Law applies to the user base.  that base will only grow via access to easy, cheap, reliable tx's.

[Adrian-x]

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

wish there was a thanks button on BCT

same with me

It's not that black and white, I think everyone has learned more since the bad idea of "green" listing and being able to use money to track child porn.

Those stupid ideas are not death sentences, they are warning signals they are examples of why we need to constantly pay attention to maintain Bitcoin.

Gavin and Mike have moved on it seems and so long as I'm not the benevolent dictator Mike H would like I'm happy to see debate and the majority direct Bitcoin.

My understand is flexible and I won't hesitate to drop XT if it's moving in the direction of adding tracking features and educate the majority.