I wouldn't put all the emphasis on this. And you're not really covered -- you'll probably find that most people that get scammed in this context don't pursue the matter in court.

Just something to consider. First and foremost, reputation is paramount.

The point I am making is this: Can an escrow be tied to a legitimate business, a physical address, a web site? Do other trusted members claim to know this person's identity outside of the forum? Are they doxxable? Or is it someone who only transacts in areas where they can remain fully anonymous (digital goods trades, or with P.O. boxes for physical trades)? If the latter, regarding someone who has gained a significant reputation over a short period (trust farming), red flags go off. That tells me someone may be planning a long con, and their complete anonymity is further incentive to exploit the high level of trust they have.

It's just a base-level incentive analysis. If you're going to scam, are you likely to use contact information/websites/services/businesses that can be tied to your real identity? It's not about stating who you are; it's about whether or not we can analyze your past business dealings to verify who you are. Scammers make efforts to cover their tracks the best they can. The sloppy ones aren't careful early on (when they weren't intent on scamming). The smarter ones know what they are doing from the start, and never release any information that can tie them to a real identity.

And thank goodness for that. I commend the community for recognizing that his behavior was very untrustworthy, and deserving of the inability to provide escrow services.


Simply having alt accounts isn't the issue.

Escrowing deals as one of the interested parties under the pretense of being a disinterested third party is deceptive and fraudulent. And at the least, the other party involved was swindled out of the escrow fee in each instance.

Further, QS was caught using alt accounts to shill, farm trust and otherwise abuse the trust system (e.g. using multiple accounts to neg trust people). Is this how a trustworthy person acts?

On that subject, John K's feedback says it best. He was "engaging in self-collusion by the means of using alt accounts in order present a facade of trust in his business dealings." Now, why would one want to do that?

There was a reason QS was so intent on maintaining his own anonymity (a point to consider when choosing an escrow). I'll just leave this here.

"Peter R: Bigger Blocks = Higher Prices"

This dubious correlation is the crux of the issue (as much as "big blockers" might deny it). The mooners want moon today, and the block size limit should have been lifted yesterday to enable that. Unfortunately, merely increasing capacity (and simultaneously opening Pandora's box for attack vectors that exploit block propagation delays) does not create organic adoption.

Why can't people wait until adoption and overcapacity actually warrant increasing block size? In the meantime, we need to address the lack of disincentives for spam/dust transactions that needlessly increase throughput requirements on the system.

Bigger blocks would require a good deal of adoption, which has yet to happen. Whether you want the limit raised or not.

Hearn is like the JaMarcus Russell of bitcoin. Great things expected, followed by great disappointment and shame. A rookie phenom that completely flopped.... and is on his way out the door.

Why would people put alts on their trust list?

Unless you were on DT... and wanted to farm trust.

Seems to me that it's just compiling information that is already available.

I give Garzik some credit for making a clear effort to find middle ground and put emphasis on consensus, rather than pandering to the outright alarmism of BIP101. I actually think that if we are going to raise the block size limit, that it should take similar form to Garzik's BIP102 -- a simple doubling, a minimal incremental approach. Although it probably makes sense to wait until demand actually warrants doing so.


Thanks, I appreciate that. Indeed, it's frustrating debating with people that take a dishonest and disingenuous approach. I put up with it for a bit, but at some point, you can only call it what it is.

@VeritasSapere

This kindergarten shit is a complete waste of my time. Repackaging the same arguments you've repeatedly made, which are backed by nothing but opinion -- this is not worth responding to. I hate to pat myself on the back, but I've completely ripped everything you've said to shreds. You're still quoting everything I said and merely responding with variations of "no, I don't think so" repeatedly without evidence. Often it seems that you are happy to produce endless meaningless fluff just to be able to say that you responded.

And for someone that endlessly complains about the governance structure, all you can say when asked to define an optimal governance structure is "the economic majority decides by choosing between alternative implementations of Bitcoin?" Seriously? That is not an adequate response to the question of how to amend the BIP process and improve decision-making. Apply those standards to XT as well as Core -- how do you expect decisions to be made? What is the formal process? Stop complaining until you at least have a proposal. (Then see if anyone actually supports it, or if you are still just speaking to yourself.)

Repeating "economic majority" like a buzz word doesn't accomplish what you think it does. It's a cheap excuse to redefine the consensus mechanism. Nobody is falling for that.


Please reconcile this with bitcoin's historical hard forks. I'm waiting.

I am not on your side. I couldn't be further from it. You emphasize "increasing block size limit" above all else (including other methods of scaling) -- consensus, decentralization, security. You've stated yourself that achieving this on political grounds is more important than any technical considerations. I couldn't imagine a position that is less logical, or less concerned with retaining value in bitcoin. You would fracture bitcoin many times over to get your political way. That's disgusting.

It's so obvious in these threads who has real money on the line here, and who doesn't.

Sad state of affairs. Even the venerated Gleb Gamow has been outed as a scammer.

I don't think that's an accurate representation. If the decision-making rules are insufficient, what do you propose -- exactly? Has anyone actually attempted to amend the BIP process and bring the question to the Core devs?

@VeritasSapere

As I've told you before, your responses are by and large insufficient. In most cases, you are merely saying "I disagree..." or "I think that..." or "I don't think that..." I cannot refute an opinion if you provide nothing to support it. Your discussion of orphaned blocks is completely absent of facts or proof; it is just tortured logic. When your arguments repeatedly boil down to mere opinion rather than logic based in facts, there is little point in arguing. My points still stand.

And seriously, I just explained how spam is already defined by the Core software and how it can be individually set. And still it's impossible to identify spam? This isn't about fees; it's about blockchain and UTXO bloat and maximizing efficiency/minimizing unnecessary throughput. You think it's more important to forego other methods of scaling so that we have to subsidize people who want to send cents, fractions of cents? Subsidize spam like Coinwallet? Not interested. You need to lose this one-track mindset.

And political commentary, by definition, cannot address technical flaws, nor the issue of ignoring engineering standards. The premise that politics can override technical knowledge and expertise is absolutely unacceptable. If that is the case, then by definition, breaking the protocol is acceptable for political reasons. WTF is the point of supporting bitcoin, then, if its procotol is constantly at the whims of a political majority? Why do you think "consensus" was established as a principle in the first place?

Your arguments about governance, again, fall on deaf ears. It's meaningless hot air. Show me alternative implementations with widespread support. No go? Build them yourself. I don't see anything here to talk about. Again, you say you think the BIP process is a problem? Then provide your primer on what the governance model is supposed to look like. Bring it to the devs, see if anyone supports anything you are saying. Because if the only major code contributors on your side are Gavin and Hearn, you've already lost. What I see from you is all complaints, no action.


On a fundamental level, I completely disagree with the first four statements. (The last is a technical point which you have not sufficiently proven.) You believe bitcoin is a democracy, and that 51% (aka a 51% attack through argument) is sufficient to hard fork. I believe your position is at odds with the ideas of "valid blocks" and the "consensus mechanism" stated in the whitepaper.

You've basically conceded that a civil war with multiple surviving blockchains is not only acceptable -- but it almost seems as if you think it's an optimal solution. If you think bitcoin is worth fracturing along the lines of something so insignificant as block size, this is another fundamental impasse.

And re XT being buggy? Yes, it is. That's what happens with little to no peer review. Irresponsible to release the code as such. One recent example:

https://www.reddit.com/r/Bitcoin/comments/3kenp1/stress_test_commence_as_of_now_were_seeing_23/cuwxvbz

More importantly, though, BIP101 breaks the consensus mechanism and introduces a scaling regime with completely unknown conditions.

Why are people so worried about Bitpay and Circle being frustrated? Hell, Bitpay has got much bigger fish to fry than the block size debate. The blocks aren't full -- now bitcoin will die because the limit hasn't been increased?

Come on, now....

I want them. And I'll pay 60% if we are bidding here.

That's not the point. I'm saying it became a question (particularly for miners) of whether or not to run the code. That isn't exactly within the scope of "it is the developers that should be discussing the block size issue." That's not up to developers.

Whether or not it's been discussed for years, the approach (especially lowering consensus to 75%) was reckless. Nick Szabo wasn't bullshitting about contentious hard forks and civil war.

I agree with this to an extent. But Gavin and Hearn also skipped that discussion by releasing a BIP101-coded client. So there's that.

How long did it take for the Copper ETF to be approved? 2-3 years? Bitcoin should double or triple that, easy. New asset class and all. The SEC isn't known for being a fast mover.

Well, suppose that bitcoin is, in fact, growing and being adopted as we speak. While I'm obviously not too bothered by the idea of a fee market, I still think a fee market is less desirable than no fee market. So, if we have already maximized efficiency/minimized spam (we have not), I think addressing throughput directly is the next logical answer.

So, to the extent that we can increase the block size limit without foregoing or jeopardizing key tenets of bitcoin (consensus, decentralization, network security), I think we should do that. But that necessarily entails a very conservative approach where we can achieve testable conditions (i.e. roughly in line with actual demand).

8MB, exponential scaling = straight up reckless.

When you say "in the business of" what do you mean, exactly? What is the business model here, and where does the profit come in? In any case, we're talking about volunteers here, so I'm not sure it's even fair to say that devs on an open source project can't have bitcoin-related interests. Let's assume that some devs do have some conflict of interest that would cause them to stonewall attempts increase the block size limit. Even so, don't we have to assess any proposal to increase the limit on its own merits (vs. accepting it on the basis that it is an alternative to Blockstream)? The code has to be taken on its own merit. Whether its Core or XT. I am not here arguing against Gavin, the person (whatever his conflicts of interest may be).

And like I said, there's nothing wrong with forking the code if Core devs are indeed "compromised." But if the code is not technically sound or is opposed on a philosophical level by most devs, miners and users, it simply won't be adopted. The best chance for a limit increase is to take a much more conservative approach than BIP101, which actually has a chance at reaching consensus. The bolder the scaling regime, the less chance it has. It's as simple as that.

There's this bizarre idea that we have to determine the block size limit (if any) forever, today, partly because people are terrified of the idea of forks down the road. The fact is: of course there will be hard forks in the future. There will be debates about protocol changes in the future that will make this issue pale in comparison. Get used to it, people. I actually believe quite the opposite of most XT supporters on this question -- I think if we conservatively and incrementally increased the limit (to say 2MB) and did not experience serious detriments to security, that it would be unquestionably easier to fork the limit up the second and third times around.

This is how consensus works -- it's messy, painful and takes time, but it's the best damn thing we have. A democracy for bitcoin is the death of bitcoin -- it will simply be co-opted as all governments have been.


Since you are not a Core developer, nor do you read the bitcoin dev list, you would not know. Thus, it sounds like you would not budge regardless of his behavior, or impediment on development. That's not a reasonable position -- it means you give Mike Hearn a free pass no matter what. Ignorance is not an excuse for that.

How would you approach a child endlessly screaming in a classroom -- disrupting all the other children's capability to learn? Let him stay and endlessly disrupt, to the detriment of progress?

I urge you to do your own research and actually read the past several months of threads on the bitcoin dev list. Endlessly flailing around like a child and making threats to have commit privileges pulled is not constructive. Whether you want to take the word of several devs other than Mike Hearn is up to you. But again, you are taking a completely one-sided position.


Of course, people should question everything. I'm a skeptic. But there is a significant difference between that and turning every technical discussion into a political one, and refusing to cede any ground in any argument. At some point, no one will be willing to work with you. That's just a practical reality. Hearn simply cries louder and louder when people reject his ideas, and tries to leverage allegations of character assassination and censorship to rally the user base against those who oppose him. Unfortunately for him, crying might work for babies, but it doesn't work for adults.

You want to change the governance model? Go ahead and propose changes to the BIP model. Do it. And if your ideas are well-reasoned and achievable, you may gain some ground. If not, you can fork the code. That's how this works. Endlessly crying about changing the governance model or the need for alternative implementations will achieve precisely nothing. Take action or don't. Don't complain to me about it. If no one supports your ideas, you're just irrelevant.

Remember, bitcoin already exists, and is chugging along just fine. So until you -- and others that are so disgusted by Core -- come up with alternatives with widespread support, this is a non-issue.


Why do you constantly ignore everything I say? I said "time is irrelevant without technically sound code to run." Inventing this sense of urgency (yeah, blocks are less than half full, and no, a temporary fee market is not the end of the world) doesn't justify running technically unsound code. Again, feel free to respond to my technical arguments made here: https://bitcointalk.org/index.php?topic=1163319.msg12332549#msg12332549

Produce a workable alternative, and we can talk. Implementing code that a) threatens network security and b) threatens a political civil war that may fracture bitcoin's user base forever, is not a workable alternative. Most people intelligent enough to use bitcoin simply won't fall for that kind of idiocy, no matter how much false urgency you attach to it (and that was made apparent by XT's demise).

Regarding b), you do realize that's what Nick Szabo was getting at re: "civil war," right? Because if the consensus threshold is lowered to an extent that it is a "democratic" decision (majority rules, like 75%), one must have a very elementary understanding of market incentives (and a lack of understanding of game theory) to assume that only one blockchain will survive. Consider that a fork is achieved with 65% of hashing power + a lucky streak. Post-fork, hashing power is split 65-35. Now -- if a miner believes that the Core chain will prevail, then by remaining on the Core chain, he will increase his relative hashing power (and share of mining rewards) by nearly 300%. That is a huge incentive not to cede to the mining majority. Then you have miners who will support one chain or the other purely out of political beliefs. Then you have miners who will do just that, up to a point where economic disincentive (or rather, fear of economic disincentive) becomes too great. Then you have potential attacks (like NotXT) which would make miner support even more opaque leading up to a hard fork. In such a situation, multiple surviving blockchains (and not necessarily just two) is a very real possibility. And if that goes on for long, too much money will have changed hands to ever turn back the clock. Bitcoin will be forever broken into multiple blockchains.


Actually, I'd rather just refute you here. I stopped responding to you in that thread because you repeatedly ignored nearly every argument I made, and continually repeated arguments that I had already addressed. This is the "Mike Hearn" approach. At some point, I'm not going to keep talking to a brick wall. I can't waste my time on that shit.


Regarding "Since most pools today are already run in high bandwidth data centers which would not be severely effected by increased block propagation times due to an increased blocksize" I ask that you provide evidence. I won't accept that at face value. What is your definition of "high bandwidth data center" and you assign this label to what percentage of miners? What proportion of Chinese miners vs. others, and does it matter to you whether Chinese miners are disproportionately affected? (Of course, that point will determine whether you have miner support for any fork ) Should the rest of the miners be written off (they should create their own altcoin, as Hearn says)? No increase in orphaned blocks -- at 8MB? 32MB? 1GB? Show me numbers. Show me proof that bandwidth capabilities will keep up with the limit -- hint: you can't. And I highly doubt they will, considering the scaling regime is based on Moore's Law, whose obituary is being written as we speak. We are talking about seconds among multiple peers here. Not minutes. Conservative is the only acceptable approach.

That "you don't think something will happen" isn't an argument. It's quite obvious you are not a developer or engineer. It's pretty well understood from an engineering perspective that conditions at drastically different scales are not similar (thus, not predictable). So much of your understanding of technical issues seems to be little more than "nothing bad can possibly happen." Quite the opposite: the saying goes "everything that can go wrong, will go wrong."

Regarding 1MB -- I'm not arguing for a permanent 1MB limit. But implementing a limit that is unrelated to demand is essentially limitless, and therefore very dangerous. Keep it in line with demand and we can likely simulate the conditions and prevent attack vectors before people lose many millions of dollars over unnecessary recklessness. In the thread I linked above, I laid out one possible attack vector that, with sufficient hashing power, might enable a miner to use spam attacks to increase block size (up to say, 8x or 16x the current limit, whatever the case may be), and subsequently force high-latency miners to SPV mine. With enough hashing power, he could then exploit SPV miners by selfish mining. This is very relevant to the bandwidth capability of Chinese miners.


No, that's a fundamental misunderstanding of consensus. You have it backwards. Time does not run out, and bitcoin remains. Robust as fuck, that bitcoin! The lesser of two evils is the protocol that achieves consensus. Anything less is not bitcoin. So if your alternative doesn't cut the mustard.... sorry. Then the status quo prevails until something better comes along. (Shrug)


Not at all, it's quite simply, really. And it's not a consensus issue, so it's an easy fix. The default Core settings already define outputs < 546 satoshis as spam. Now, it's possible for smaller outputs to be relayed, but only if node operators alter the conf files. In practice, rarely do smaller outputs get relayed. Personally, I don't view the ability to send outputs of fractions of a cent on the main blockchain to be important, and would be quite happy to see such spammers penalized for bloating the chain. As it stands, the cost of their bloat is being socialized among all bitcoin users transacting on the blockchain. We could raise the dust threshold and/or have the default Core settings require additional fees based on dust outputs to disincentivize spam.

https://bitcointalk.org/index.php?topic=1171182.msg12331532#msg12331532


Again, this isn't how engineering and software development work..... If you were preparing a new release of a major, acclaimed video game, would you release it as buggy, scarcely-audited code? Or would you do it right? Indeed, actions speak louder than words.

I've got too much goddamn money on the line to fall for that bullshit.

And now that I've wasted probably 2 hours of my life writing this book -- don't take it as a victory if I don't respond to your next post. I've wasted too much time already, and I think this forum likely by now is less prone to fall for these "sky is falling" and "Core is evil" arguments.

Forestalling? I don't think that's an accurate representation. Most of the Core developers just don't see the same level of urgency that Gavin and Hearn do. I agree with them on that. Core developers have made several proposals regarding how to increase the block size limit (or otherwise address insufficient capacity). Analyzing, discussing, auditing, testing the code takes time and should not be rushed.

I haven't seen any compelling arguments as to this supposed conflict-of-interest with Blockstream, to be honest. I won't deny the possibility, but I just don't see the evidence. Regardless, [temp?] banning Hearn from a discussion is not covering anything up. The issues are out in the open.

http://sourceforge.net/p/bitcoin/mailman/message/34220923/

http://sourceforge.net/p/bitcoin/mailman/message/34220953/

You completely missed the point. There can be no progress on the code when "every pull [Hearn] touches turns into a cesspool." Bitcoin is a collaborative project. If he refuses to collaborate with the other devs and continues to try to force unpopular opinions in the face of significant criticism, collaboration is impossible. Hence why he forked the code.

Go ahead and continue to ignore other developers' opinions in favor of your own unbacked opinions. But your ignorance of the context of the mailing lists is not compelling.

Here's a few more tidbits on why Hearn has been ostracized:
https://www.reddit.com/r/Bitcoin/comments/3n18en/mike_hearn_banned_from_bitcoindev_sept29/cvk0ko7
https://www.reddit.com/r/Bitcoin/comments/3n18en/mike_hearn_banned_from_bitcoindev_sept29/cvjxbb5
https://www.reddit.com/r/Bitcoin/comments/3n18en/mike_hearn_banned_from_bitcoindev_sept29/cvl1yae
https://www.reddit.com/r/Bitcoin/comments/3n18en/mike_hearn_banned_from_bitcoindev_sept29/cvk1cpx
https://www.reddit.com/r/Bitcoin/comments/3mvq61/scaling_bitcoin_092915/cvj8zf3