- cypherpunks - lists.cpunks.org

Crypto Wars 2.0
by coderman 08 Jul '15

08 Jul '15

"Security Researchers are “the antibodies of the digital immune system” @Infosecjen in Senate Judiciary hearing encouraging more modern CFAA" - https://twitter.com/joshcorman/status/618914661128380416 "we may give you a rash, make you irritated. but it is for your own good, earth humans." longer transcript: https://www.judiciary.senate.gov/meetings/cyber-crime-modernizing-our-legal… best regards,

1 0

Re: Hacking Team has been hacked (hard)
by coderman 08 Jul '15

08 Jul '15

On 7/8/15, Razer <Rayzer(a)riseup.net> wrote: > ... that may be from the day when > people paid by the byte for internet service. Should I post the > entirety? It's kinda long. JYA and me and history prefer verbatim, and long since gone the days when bandwidth bytes begged brevity now, just /s TL;DR or ignore... [ and yes the whole thing :P ] best regards,

1 0

Inquiry re. how to handle Glomar reply to FOIA request
by odinn 08 Jul '15

08 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, A while back (specifically, on 6/01/2015) I sent in a FOIA request to the NSA, requesting, in part, records about myself that "would have been collected by the NSA under programs authorized by Sections 206 and 215 of the USA PATRIOT Act, and Section 6001(a) of the IRTPA, aforementioned programs and sections which are now expired as of the date of this request (June 1, 2015)." In essence, I figured, since the underlying legal authority for the program had lapsed (however briefly), there was no time like that present moment to file a FOIA request. And so, I did, not using USPS mail, but a digital service to ensure it would arrive timely. My request was actually rather lengthy; that was just a small part, and I requested any NSA records collected on my person as a result of use of Sections 206 or 215 of the USA PATRIOT Act, or Section 6001(a) of the IRTPA, from Oct. 26, 2001 to the date of expiration and sunset of those Sections on midnight May 31st 2015. (For those who are trying to remember the timeline of what ended up replacing all that, the USA Freedom Act was signed into law on June 2, 2015.) ~~ The NSA failed to respond within the 20 business days required by federal law and sent back a "Glomar response." Technically, as of today, I only have 49 days left to write and send an appeal (based on the date when they sent me their Glomar reply). So... if you have ever done a SUCCESSful appeal of a Glomar response, please reply back to me and let me know (give me some advice, etc). Thanks in advance. I've copied a portion of the letter they sent below: "As you may also be aware, there has been considerable coverage of two NSA intelligence programs in the press /media. Under Sec. 215 of the USA PATRIOT Act, as authorized by the Foreign Intelligence Surveillance Court NSA may acquire telephone metadata, such as the telephone numbers dialed and length of calls, but not the content of calls or the names of the communicants. Under Sec. 702 of the FISA, with appropriate authorization, NSA may target non-US. persons reasonably believed to be located outside the United States for foreign intelligence purposes. Under the FISC-authorized Sec. 215 authority, NSA cannot review any metadata unless strict requirements are met, the data may be queried only when there is a reasonable suspicion, based on speci?c facts, that a phone number is associated with a foreign terrorist organization. Likewise, under Sec. 702, there are strict controls approved by the FISC to help ensure that no US. person is targeted and FISC-approved minimizations procedures to ensure the protection of any information concerning U.S. persons that may be incidentally acquire d. Although these two programs have been publicly acknowledged, details about them remain classified and /or protected from release by statutes to prevent harm to the national security of the United States. To the extent that your request seeks any information on you in relation to NSA intelligence programs, or in relation to any specific methods or means for conducting the programs, we cannot acknowledge the existence or non-existence of such information. Any positive or negative response on a request-by-request basis would allow our adversaries to accumulate information and draw conclusions about technical capabilities, sources, and methods. Our adversaries are likely to evaluate all public responses related to these programs. Were we to provide positive or negative responses to requests such as yours, our adversaries compilation of the information provided would reasonably be expected to cause exceptionally grave damage to the national security. Therefore, your request is denied because the fact of the existence or non-existence of responsive records is a currently and properly classified matter in accordance with Executive Order 13526, as set forth in Subparagraph of Section 1.4. Thus, your request is denied pursuant to the first exemption of the FOIA, which provides that the FOIA does not apply to matters that are specifically authorized under criteria established by an Executive Order to be kept secret in the interest of national defense or foreign relations and are properly classified pursuant to such Executive Order. Moreover, the third exemption of the FOIA provides for the withholding of information specifically protected from disclosure by statute. Thus, your request is also denied because the fact of the existence or non-existence of the information is exempted from disclosure pursuant to the third exemption. The specific statutes applicable in this case are: Title 18 US. Code 798; Title 50 US. Code 3024(i); and Section 6, Public Law 86?36 (50 US. Code 3605). (....) Paragraph 3.6(a) of Executive Order 13526 specifically authorizes this type of response, also known as a Glomar response, to a request made under the FOIA, PA, or the mandatory review provisions of this Order. The statutes cited above under the third exemption of the FOIA would also apply to the denial of the fact of the existence or non-existence of the information if sought under the PA. The Initial Denial Authority for NSA information is the Associate Director for Policy and Records, David J. Sherman. As your request is being denied, you are hereby advised of this Agency's appeal procedures. Any person denied access to information may file an appeal to the CSS Freedom of Information Act/ Privacy Act Appeal Authority. The appeal must be postmarked no later than 60 calendar days of the date of the initial denial letter. The appeal shall be in writing addressed to the (...) - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVnIYlAAoJEGxwq/inSG8CQQQH/iLwr11gjbrHrAWaeiJ3Qllr zH+cNwUMLciht/2RhSaY/D5bNYczTUTyBUlKA4I4mhMYBjQPhBgHDI/E1QY0swJG CLLvDPkXunLg++lri5lnvlI+jSTakBIFyRdBsP8CcoHSpNOJhEtThqlsAoRog/Br 7CPIAF2t6XCESiSILAhmo791U5w1m2OmWCqO92JLjee6LP/2QK7QkYRvuJ9TzSnA B3aMY8pCDdjweJAueKq24ONL7lZuXZ38mZVjFPnUJsUCVQ7qlzjC5WAlB+So0lXu ifJTOP46CH4xV4YuObMb7Xi++O9fQSsM1ApM49uN9GIiHbXnjGm1NVzXfelZ0mc= =JyE1 -----END PGP SIGNATURE-----

3 2

Re: [from offlist] "Google is to surveillance capitalism what GM was to managerial capitalism"
by Razer 08 Jul '15

08 Jul '15

The pdf doesn't let you mail it? Try the attached. It mailed for me. If it works for you note that all I did was save a renamed copy from inside Linux Viewer RR On 07/08/2015 03:03 AM, Cari Machet wrote: > > Thanks for posting it i cannot fucking cut and paste it to my friend > in prison ... the downloaded pdf doesnt let you and the online one > fucks up the formatting ... i will be able to at least send him this > > Pdf hatred > > On Jul 7, 2015 11:36 PM, "Razer" <Rayzer(a)riseup.net > <mailto:Rayzer@riseup.net>> wrote: > > > > Big Other: Surveillance Capitalism and the Prospects of an > Information > > Civilization > > > > Shoshana Zuboff, Berkman Center for Internet & Society; Harvard > > Business School > > > > April 4, 2015 >

1 0

Re: [cryptome] Re: FOIPA adventures
by John Young 08 Jul '15

08 Jul '15

Quite nice compilation of sources configured to evade FOIA. Ever finer feigning requires ever finer seining. Paraphrasing Charles Murray, "US's ever more manipulable legal system and ever increasing government regulations are essentally lawless. When governments transgress citizens' rights, revolution is not treason but the people's duty." At 07:32 AM 7/8/2015, coderman wrote: >for all of you driving vehicles with hundreds of global variables >around weird machines radio linked to strange networks, > >the following new FOIAs: > >https://www.muckrock.com/foi/united-states-of-america-10/badaccel-19510/ >@FBI >Use of Sudden unintended acceleration (SUA) or Unintended acceleration >in the commission of a crime, including premeditated offenses of any >kind. Please include suspicion of Sudden unintended acceleration (SUA) >or suspicion of Unintended acceleration within the scope of this >request, even if alternate cause determined. This search is to include >any and all records, including cross-references and indirect mentions, >including records outside the investigation main file. This is to >include a search of each of the following record stores and >interfaces: the Central Records System (CRS), the Automated Case >Support system ("ACS") Investigative Case Management system ("ICM"), >the Automated Case Support system ("ACS") Electronic Case File >("ECF"), and the Automated Case Support system ("ACS") Universal Index >("UNI"). Please include processing notes, even if request is denied in >part. Please identify individuals responsible for any aspect of FOIA >processing in the processing notes, along with explanation of their >involvement if not typically assigned FOIA responsibilities for the >record systems above. > > >@DoT >https://www.muckrock.com/foi/united-states-of-america-10/badaccel-19509/ > > >best regards,

1 0

Re: Bitcoin philosophical musings and pressures 7 years in [drifted from: txrate, forking, etc]
by Softy 08 Jul '15

08 Jul '15

> From: Lodewijk andré de la porte <l(a)odewijk.nl> > To: Sean Lynch <seanl(a)literati.org> > Cc: "cypherpunks(a)cpunks.org" <cypherpunks(a)cpunks.org> > > > his documents are genuine. I see no reason for the NSA to be > substantially > > more competent than, say, the OPM. > > > There's absolutely no reason to think the NSA doesn't have a > layered/multi-cell operation wherein a mere contractor is not given access > to nation-essential secrets. If there's a foreign spy you want him to > They do have such a layer system. The problem is the fluidity of the people. Soldiers become Contractors become Government Employees become Contractors ad-infinitum. Once cleared, the system has not managed to remain opaque from within. In times past it was -- and that successful model was condemned as having "not prevented" the Sept 2001 bombing. Thus the stovepipe security model was banished; "war effort" requires exorbitant high staffing increases which led to inevitable, and predictable lowering of tactics, techniques and procedures. That trend has since reversed (I would argue pre-Snowden) and the beast is once again slowly shrouding itself within and increasingly outward. As with any good Corporate makeover, with a kinder gentler face. [[ my removal of your excellent government employee summary is not because of any disagreement - whether military or civilian employee, the vast majority are of a mind you described. But, as has been eloquently stated Power Corrupts Absolutely. ]] > shows a certain amount of rot in NSA_Public. The recent Trident leak shows > > 'NSA_Public' is an excellent characterization. That which we know of the Agency will forever be shadowed by it's hidden complexities. Having exposed a portion of one small stovepipe, the tubing now changes and reworks itself hiding the un-discerned exposed parts, and more closely guarding the vast un-exposed bulk. I use my description of "small" completely intentional. The scale of the "Snowden Topics" is minor compared to the remaining unknowns. Carefully protected within the 'NSA_Closed'. Not only by the regrowing stovepipes, but as well by the people you aptly described as genuinely, legitimately, and correctly striving to maintain the integrity of the beast. Just as they don't understand the oppositions claims aptly describing the illegitimacy of the beast, neither will the opposition. Sadly the two are closer in philosophical agreement than either realize. And probably won't without the benefit of hindsight, whatever sort of post-empirical change allows for the creation of a commonly agreed on framework of reference.

1 0

Jim Bell vindicated
by Seth 08 Jul '15

08 Jul '15

Reposted from http://morelibertynow.com/nypd-strike/ NYPD STRIKE SUGGESTS IT’S TIME FOR ASSASSINATION MARKETS IF WE WON'T ORGANIZE FOR NONVIOLENCE, WE'LL HAVE TO ORGANIZE FOR VIOLENCE We should use political violence (preemptive and generalized violence against a class of likely aggressors) against police. That’s what some libertarians have been saying for years. I continue to reject this idea but I have to give these folks their due – it worked in New York City. A gunman’s assassination of two NYC police officers while they sat in their cruiser on December 20 has led to chaos in the NYC government. Almost immediately: citations for traffic violations fell by 94 percent; summonses for low-level offenses dropped by 94 percent; parking violations were down by 92 percent; drug arrests by the NY Police Department (NYPD) Organized Crime Control Bureau plummeted 84 percent; cops received orders to only work in pairs and not even take breaks alone; police union officials told fellow officers to not make arrests “unless absolutely necessary” – thus calling into question the legitimacy of their normal arresting habits – and claimed they were on wartime footing; cops from across the country traveled to NYC to attend the funeral, evidence of the wide psychological impact of the assassinations; infighting between the NYPD and the NYC mayor escalated, damaging the effectiveness of the NYC government. THE DROP IN ARRESTS The overall drop in arrests, at 66 percent, in the week following the assassinations is nothing short of jaw-dropping. How is it that the NYPD could effectively go on strike and yet the city is not tearing itself apart? One reason may be that the general public is also horrified by the violence and people are behaving themselves better out of deference to the cops. Another is that people are on better behavior because they are afraid of overreaction on the part of paranoid police. Every cop out there may be ready to issue beatings and bullets for even the lowliest of infractions (as if they weren’t already). But I think the reality is actually that most of these arrests are for penny-ante, mostly-victimless crimes. They’re about making NYC a more pleasant place to live and visit for tourists and those who are well-off. The crimes people were being cited and caged for represent no real threat to the peace. Those minor infractions are also about filling the coffers of the NYC government revenue machine through fines and fees. INTRA-GOVERNMENTAL STRIFE John Robb’s first rule of open source warfare is to break networks. This lone gunman inadvertently did that by leading the NYPD and the mayor into greater confrontation, so much so that the cops turned their backs en masse on their boss, the mayor, in a public gathering that made headlines. What’s more, the gunman did this without any conscious attempt to maximize such damage and with the meager investment of a pistol, ammunition and transportation to NYC. Who knows how much the executions and their aftermath have cost the city of New York and police across the nation, but the return on investment (ROI) for this execution must be high. If the gunman spent $2,000 to carry this attack out, and the cost in financial outlays, loss of government revenue (due to reduced ticketing), police peace of mind and other intangibles is $20 million, that’s a 10,000 percent ROI. A LIBERTARIAN ANALYSIS In the short term, libertarians may feel the urge to cheer the gunman. But you shouldn’t. Executing members of a group for the perceived crimes of the whole, or of certain members of the group, is rank collectivism. It stinks. Libertarianism is individualism. Collectivism is the opposite of our philosophy. This kind of collectivist anti-cop vigilantism could easily get out of hand. Careless, suicidal vigilantes could shoot innocent bystanders. Paranoid cops could overreact even more than they already do and kill even more people than they already do. Then what? Civil war on the streets? Nobody wants that. DANGEROUS PRECEDENT FOR PUBLIC ORDER Even in a libertarian society, stateless or not, you need law and order. People need to know that those who break the rules will be stopped and made to pay for their destructive actions. Without that, society doesn’t work. The lawless cause more disturbances and the lawful look for other solutions or other places to go. Random murders and police going on strike or engaging in work slowdowns is a recipe for societal breakdown. Libertarians are wise to condemn both equally, while demanding the continued reduction in harassment of people accused of committing victimless crimes. WHAT ABOUT IN A STATELESS SOCIETY? In a stateless libertarian society, there are multiple police, or private defense, agencies in operation in a city the size of New York. If an employee of one agency is assassinated, it’s likely that employees of all of the agencies would engage in acts of solidarity with the fallen employee. But it’s unlikely that all of the agencies would go on strike, at least not all at the same time. Unlike the NYPD, which is centrally controlled by its commissioner and the mayor above him, private defense agencies are each independent and free from coercive outside control. Different agencies would likely make different decisions on the question of whether to strike or not. It’s possible that all of the individual employees of all of these agencies would be members of the same union, or a tight group of unions. That union could go on strike and force a work stoppage or slowdown similar to what is taking place in NYC. But, in a stateless society, the private defense agencies could just as easily fire or furlough their current employees and hire new ones who recognized the need to keep working, or just needed the work. These new ones could be experienced security agents from out of town or recently-retired former employees. The NYPD doesn’t enjoy that kind of flexibility. It is owned and controlled by the local government, the same entity that promulgates the laws that make it difficult, if not impossible to fire government employees for striking. Even without these troublesome laws, politicians dare not act definitively against a striking police union because the cops, their friends, family and supporters will vote against them in an upcoming election. Private defense agencies don’t have that concern, though they would have to worry about losing customers who disapproved of their mass firing or furloughing of their employees. It’s also likely that there would not be just one, massive police union, or tightly-coordinated group of unions. With multiple private defense agencies, the need for a unified negotiating position would likely be reduced. The bottom line is that a legal police monopoly – the NYPD – makes the residents of NYC more vulnerable to crime. This one organization can go on strike, or a slowdown, and it threatens the security of the entire city because there is no competition to pick up the slack – that competition is legally banned. In a stateless society, however, if one private defense agency shuts down, there is a strong incentive for the others to ramp up their operations, in order to collect the customers of the agency that shut down. This analysis doesn’t even take into account the fact that competitive private defense agencies will not enjoy de facto immunity from accountability for their crimes. Without that special privilege, bad cops will be held accountable for their actions. Societal rage against bad cops will be assuaged by removing this special protection and the motivation for collectivist vigilantism against cops will be removed. LESSONS FOR LIBERTARIANS The aftermath of the assassinations is a clear sign that assassination is an effective tool, at least in the short term, in the fight to control police abuse. Police activity is down, cops are scared and the cops and mayor are at war. I take no pleasure in saying that because it appears to validate the strategy of fellow libertarian activist Christopher Cantwell – not one of my favorite people. Given that cops across the country have shown themselves, time and time again, to be unaccountable killers, it makes no sense to take this kind of abuse lying down. It’s only reasonable to take steps to protect oneself from police abuse and fraud. I choose the nonviolent route because I am certain that the violent one will backfire. Already, family and friends of cops are organizing in support of police officers across the country. Violence is a polarizing tactic that you don’t come back from. But I believe in organization. If folks are going to advocate for political violence against police, then at least get the damned thing organized so it has a chance of success. Assassination Politics is essential reading in this area. In fact, an assassination marketplace already exists behind Tor on the Darknet. So, if people like Cantwell are serious about killing cops, why don’t they actively promote assassination marketplaces? Why don’t they create more marketplaces, add more targets and run marketing campaigns for them? Why the gratuitous chatter and the lack of sustained efforts toward their stated goal? It’s likely that at least a small amount of targeted violence will be required to take down governments, so that a more liberty-centric order can supplant them. If we accept that, as distasteful as it is, then assassination marketplaces become attractive. Unlike a traditional war, assassination marketplaces don’t require that you kill tens of thousands of cops, politicians and soldiers. In order for assassination marketplaces to end the age of the state, only a few targeted individuals need be killed. For the rest, active and well-funded threats may be sufficient to intimidate aggressors into remaining peaceful while an organized resistance takes voluntary civil institutions to the next level. This idea of keeping cops in check by placing bounties on their heads is nothing new. Pablo Escobar used it in Medellín to great effect. The IRA used it in Ireland. States are masters at this tactic, both against accused criminals and against insurgencies, such as Alvaro Uribe’s bounties on FARC members in Colombia in the last decade. It works. If the libertarian communities can ever get our collective acts together, someday we may be negotiating with police unions. We will want them to stop enforcing victimless crimes and to cooperate with the liberalization of their sector by accepting competition – the end to their monopoly. When negotiating with armed and dangerous paramilitary forces, it’s wise to operate from a position of strength. Assassination markets are one vector for gaining that kind of negotiating position. We would be wise to explore our options in that area. Violence is distasteful. But death and ignominious caging are worse. Libertarians have to be realistic. We can never secure our desired libertarian future from a position of weakness and disorganization. If we’re unable or unwilling to organize for nonviolent action, then we will have to organize for violent action. The alternative to either of these options, a wait-and-see, hemming-hawing, pacifistic apathy, is even more repugnant than violence. A PERSONAL NOTE It’s tasteless to rejoice in the death of other people, no matter the evil of their actions while alive. Every human life is precious, even those spent in misguided pursuits like being a US Marshal, a congressperson, bureaucrat or a NYC cop because any of those lives can be redeemed at any moment and put to great use. See, for example, retired Philadelphia police captain Ray Lewis. I am sympathetic to the families of the assassinated officers. No one wants to lose a loved one like that. No one wants to die like that, without even a chance to defend themselves. But such feelings must never get in the way of speaking the truth.

15 48

"Google is to surveillance capitalism what GM was to managerial capitalism"
by Razer 07 Jul '15

07 Jul '15

> Big Other: Surveillance Capitalism and the Prospects of an Information > Civilization > > Shoshana Zuboff, Berkman Center for Internet & Society; Harvard > Business School > > April 4, 2015 > > Abstract: > This article describes an emergent logic of accumulation in the > networked sphere, ‘surveillance capitalism,’ and considers its > implications for ‘information civilization.’ Google is to surveillance > capitalism what General Motors was to managerial capitalism. Therefore > the institutionalizing practices and operational assumptions of Google > Inc. are the primary lens for this analysis as they are rendered in > two recent articles authored by Google Chief Economist Hal Varian. > > Varian asserts four uses that follow from computer-mediated > transactions: ‘data extraction and analysis,’ ‘new contractual forms > due to better monitoring,’ ‘personalization and customization,’ and > ‘continuous experiments.’ > > An examination of the nature and consequences of these uses sheds > light on the implicit logic of surveillance capitalism and the global > architecture of computer mediation upon which it depends. This > architecture produces a distributed and largely uncontested new > expression of power that I christen: ‘Big Other.’ It is constituted by > unexpected and often illegible mechanisms of extraction, > commodification, and control that effectively exile persons from their > own behavior while producing new markets of behavioral prediction and > modification. Surveillance capitalism challenges democratic norms and > departs in key ways from the centuries long evolution of market > capitalism. > > Number of Pages in PDF File: 15 > > Keywords: surveillance capitalism, big data, Google, information > society, privacy, internet of everything http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2594754

1 0

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
by Eugen Leitl 07 Jul '15

07 Jul '15

----- Forwarded message from Adam Back <adam(a)cypherspace.org> ----- Date: Mon, 15 Jun 2015 20:03:25 +0200 From: Adam Back <adam(a)cypherspace.org> To: Mike Hearn <mike(a)plan99.net> Cc: Bitcoin Dev <bitcoin-development(a)lists.sourceforge.net> Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Message-ID: <CALqxMTFC7zBN9GvHAZLQj4SbXjzkCAM9meSErd3qn7uCoON98Q(a)mail.gmail.com> Hi Mike Well thank you for replying openly on this topic, its helpful. I apologise in advance if this gets quite to the point and at times blunt, but transparency is important, and we owe it to the users who see Bitcoin as the start of a new future and the$3b of invested funds and $600m of VC funds invested in companies, we owe it to them that we be open and transparent here. I would really prefer on a personal nor professional basis to be having this conversation period, never mind in public, but Mike - your and Gavin's decision to promote a unilateral hard-fork and code fork are extremely high risk for bitcoin and so there remains little choice. So I apologise again that we have to have this kind of conversation on a technical discussion list. This whole thing is hugely stressful and worrying for developers, companies and investors. I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor (without accusing you of any of those - I understand you personally just want to scale bitcoin, but are inclined to knock heads and try to force an issue you see, rather than work collaboratively). For you (and everyone) - Should there be a summit of some kind, that is open attendance, and video recorded so that people who are unable to attend can participate too, so that people can present the technical proposals and risks in an unbiased way? (It is not theoretical question, I may have a sponsor and host - not Blockstream, an independent, its a question for everyone, developers, users, CTOs, CEOs.) So here I come back to more frank questions: Governance The rest of the developers are wise to realise that they do not want exclusive control, to avoid governance centralising into the hands of one person, and this is why they have shared it with a consensus process over the last 4 years. No offence but I dont think you personally are thinking far enough ahead to think you want personal control of this industry. Maybe some factions dont trust your motives, or they dont mind, but feel more assured if a dozen other people are closely reviewing and have collective review authority. - Do you understand that attempting to break this process by unilateral hard-fork is extremely weakening of Bitcoin's change governance model? - Do you understand that change governance is important, and that it is important that there be multiple reviewers and sign-off to avoid someone being blackmailed or influenced by an external party - which could potentially result in massive theft of funds if something were missed? - Secondarily do you understand that even if you succeed in a unilateral fork (and the level of lost coins and market cap and damage to confidence is recoverable), that it sets a precedent that others may try to follow in the future to introduce coercive features that break the assurances of bitcoin, like fungibility reducing features say (topically I hear you once proposed on a private forum the concept of red-lists, other such proposals have been made and quickly abandoned), or ultimately if there is a political process to obtain unpopular changes by unilateral threat, the sky is the limit - rewrite the social contract at that point without consensus, but by calculation that people will value Bitcoin enough that they will follow a lead to avoid risk to the system? Security As you probably know some extremely subtle bugs in Bitcoin have at times slipped past even the most rigorous testings, often with innocuous but unexpected behaviours, but some security issues Some extremely intricate and time-sensitive security defect and incident response happens from time to time which is not necessarily publicly disclosed until after the issue has been rolled out and fixed, which can take some time due to the nature of protocol upgrades, work-arounds, software upgrade via contacting key miners etc. We could take an example of the openSSL bug. - How do you plan to deal with security & incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control? - Are you a member of the bitcoin security reporting list? On 15 June 2015 at 11:56, Mike Hearn <mike(a)plan99.net> wrote: > I will review both and mostly delegate to Gavin's good taste around the > details, unless there is some very strong disagreement. But that seems > unlikely. > ... > Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests > aren't scored in any way. The final decision rests with the maintainer as in > ~all open source projects. As you know the people who have written 95% of the code (and reviewed, and tested, and formally proved segments etc) are strenuously advising not to push any consensus code into public use without listening to and addressing review questions which span beyond rigorous code & automated guided fuzz testers, simulation and sometimes formal proofs, but also economics, game-theory and critically very subtle determinism/consensus safety that they have collectively 4-5 years experience of each. - Will you pause your release plans if all of the other developers insist that the code or algorithm is defective? - Please don't take this the wrong way, and I know your bitcoinj work was a significant engineering project which required porting bitcoin logic. But If the answer to the above question is no, as you seemed to indicate in your response, as you not have not written much bitcoin core code yourself (I think 3 PRs in total), do you find yourself more qualified than the combination of peer review of the group of people who have written 95% of it, and maintained it and refactored most of it over the last 4-5 years? I presume from your security background you are quite familiar with the need for review of crypto protocol changes & rigorous code review. That is even more the case with Bitcoin given the consensus criticality. >> - On the idea of a non-consensus hard-fork at all, I think we can >> assume you will get a row of NACKs. Can you explain your rationale >> for going ahead anyway? The risks are well understood and enormous. > > If Bitcoin runs out of capacity it will break and many of our users will > leave. That is not an acceptable outcome for myself or the many other > wallet, service and merchant developers who have worked for years to build > an ecosystem around this protocol. That you are frustrated, is not a sufficient answer as to why you are proposing to go ahead with a universally acknowledged extreme network divergence danger unilateral hard-fork, lacking wide-spread consensus. People are quite concerned about this. Patience, caution and prudence is necessary in a software system with such high assurance requirements. So I ask again: - On the idea of a non-consensus hard-fork at all, I think we can assume you will get a row of NACKs. Can you explain your rationale for going ahead anyway? The risks are well understood and enormous. Note the key point is that you are working on a unilateral hard-fork, where there is a clear 4 year established process for proposing improvements and an extremely well thought out and important change management governance process. While there has been much discussion, you nor Gavin, have not actually posted a BIP for review. Nor actually was much of the discussion even conducted in the open: it was only when Matt felt the need to clear the air and steer this conversation into the open that discussion arose here. During that period of private discussion you and Gavin were largely unknown to most of us lobbying companies with your representation of a method that concerns everyone of the Bitcoin users. Now that the technical community aware aware they are strenuously discouraging you on the basis of risks. Openness - Do you agree that bitcoin technical discussions should happen in the open? - As this is a FOSS project, do you agree that companies should also be open, about their requirements and trade-offs they would prefer? - Can you disclose the list of companies you have lobbied in private whether they have spoken publicly or not, and whether they have indicated approval or not? - Did you share a specific plan, like a BIP or white paper with these companies, and if so can we see it? - If you didnt submit a plan, could you summarise what you asked them and what you proposed, and if you discussed also the risks? (If you asked them if they would like Bitcoin to scale, I expect almost everyone does, including every member of the technical community, so that for example would not fairly indicate approval for a unilateral hard-fork) I and others will be happy to talk with the CTO and CEOs of companies you have lobbied in private, for balance to assure ourselves and the rest of the community that their support was given - and with full understanding of the risks of doing it unilaterally, without peer review, benefit of maintenance and security inidence management, and what exactly they are being quoting as having signed up for. (This maybe more efficiently and openly achieved by the open process, on a mailing list, maybe a different one even special purpose to this topic, with additional option of the open public meeting I proposed at the top). - Do you agree that it would be appropriate, that companies be aware of both the scaling opportunities (of course, great everyone wants scalability) as well as the technical limits and risks with various approaches? And that these be presented by parties from a range of views to ensure balance? - Do you consider your expression of issues to hold true to the ideal of representing balanced nuanced view of all sides of a technical debate, even when under pressure or feeling impatient about the process? You may want to review the opening few minutes of your epicenter 82 bitcoin for example where you claimed and I quote "[the rest of the technical community] dont want capacity to ever increase and want it to stay where it is and when it fills up people move to other systems". - Do you think that is an accurate depiction of the complex trade-offs we have been discussing on this list? (For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time.) - Were you similarly balanced in your explanations when talking to companies in private discussions? - Do you understand that if we do not work from balanced technical discussion, that we may end up with some biased criteria? Authority Neither you nor Gavin have any particular authority here to speak on behalf of Bitcoin (eg you acknowledge in your podcast that Wladimir is dev lead, and you and Gavin are both well aware of the 4 year established change management consensus decision making model where all of the technical reviewers have to come to agreement before changes go in for security reasons explained above). I know Gavin has a "Chief Scientist" title from the Bitcoin Foundation, but sadly that organisation is not held in as much regard as it once was, due to various irregularities and controversies, and as I understand it no longer employs any developers, due to lack of funds. Gavin is now employed by MIT's DCI project as a researcher in some capacity. As you know Wladimir is doing the development lead role now, and it seems part of your personal frustration you said was because he did not agree with your views. Neither you nor Gavin have been particularly involved in bitcoin lately, even Gavin, for 1.5 years or so. - Do you agree that if you presume to speak where you do not have authority you may confuse companies? > If Bitcoin runs out of capacity it will break and many of our users will > leave. That is not an acceptable outcome for myself or the many other > wallet, service and merchant developers who have worked for years to build > an ecosystem around this protocol. But I think this is a false dichotomy. As I said in previous mail I understand people are frustrated that it has taken so long, but it is not the case that no progress has been made on scalability. I itemised a long list of scalability work which you acknowledged as impressive work (CPU, memory, network bandwidth/latency) and RBF, CPFP fee work, fee-estimation, and so on, which you acknowledged and are aware of. There are multiple proposals and BIPs under consideration on the list right now. - what is the reason that you (or Gavin) would not post your BIP along side the others to see if it would win based on technical merit? - why would you feel uniquely qualified to override the expert opinion of the rest of the technical community if your proposal were not considered to have most technical merit? (Given that this is not a simple market competition thing where multiple hard-forks can be considered - it is a one only decision, and if it is done in a divisive unilateral way there are extreme risks of the ledger diverging.) Network Divergence Risk >> - How do you propose to deal with the extra risks that come from >> non-consensus hard-forks? Hard-forks themselves are quite risky, but >> non-consensus ones are extremely dangerous for consensus. > > The approach is the same for other forks. Voting via block versions and then > when there's been >X% for Y time units the 1mb limit is lifted/replaced. But this is not a soft-fork, it is a hard-fork. Miner voting is only peripherally related. Even if in the extremis 75% of miners tried a unilateral hard-fork but 100% of the users stayed on the maintained original code, no change would occur other than those miners losing reward (mining fork-coins with no resale value) and the difficulty would adjust. The miners who made an error in choice would lose money and go out of business or rejoin the chain. However if something in that direction happens with actual users and companies on both sides of it users will lose money, the ledger will diverge as soon as a single double-spend happens, and never share a block again, companies will go instantly insolvent, and chaos will break out. This is the dangerous scenario we are concerned about. So the same question again: - How do you propose to deal with the extra risks that come from non-consensus hard-forks? Hard-forks themselves are quite risky, but non-consensus ones are extremely dangerous for consensus. Being sensitive to alarming the market It is something akin to Greece or Portugal or Italy exiting the euro currency in a disorderly way. Economists and central bank policy makers are extremely worried about such an eventuality and talk about related factors in careful, measured terms, watch Mario Draghi when he speaks. Imagine that bitcoin is 10x or 100x bigger. Bitcoin cant have people taking unilateral actions such as you have been proposing. It is not following the consensus governance process, and not good policy and it is probably affecting bitcoin confidence and price at this moment. >> - Do you have contingency plans for what to do if the non-consensus >> hard-fork goes wrong and $3B is lost as a result? > > Where did you get the $3B figure from? The fork either doesn't happen, or it > happens after quite a long period of people knowing it's going to happen - > for example because their full node is printing "You need to upgrade" > messages due to seeing the larger block version, or because they read the > news, or because they heard about it via some other mechanisms. This is not a soft-fork, and the community will not want to take the risks once they understand them, and they have months in which to understand them and at this point you've motivated and wasted 100s of developer man hours such that we will feel impelled to make sure that no one opts into a unilateral hard-fork without understanding the risks. It would be negligent to allow people to do that. Before this gets very far FAQs will be on bitcoin.org etc explaining this risk I would imagine. Its just starting not finished. What makes you think the rest of the community may not instead prefer Jeff Garzik's BIP after revisions that he is making now with review comments from others? Or another proposal. Taken together with a deployment plan that sees work on decentralisation tying into that plan. - If you persisted anyway, what makes you think bitcoin could not make code changes defensively relating to your unilateral fork? (I am sure creative minds can find some ways to harden bitcoin against a unilateral fork, with a soft-fork or non-consensus update can be deployed much faster than a hard-fork). I tried to warn Gavin privately that I thought he was under-estimating the risk of failure to his fork proposal due to it being unilateral. Ie as you both seem sincere in your wish to have your proposal succeed, then obviously the best way to do that is to release a BIP in the open collaborative process and submit it to review like everyone else. Doing it unilaterally only increases its chance of failure. The only sensible thing to do here is submit a BIP and stop the unilateral fork threat. Scalability Plans > Let me flip the question around. Do you have a contingency plan if Bitcoin > runs out of capacity and significant user disruption occurs that results in > exodus, followed by fall in BTC price? The only one I've seen is "we can > perform an emergency hard fork in a few weeks"! Yes people have proposed other plans. Bryan Bishop posted a list of them. Jeff Garzik has a proposal, BIP-100 which seems already better than Gavin's having benefit of peer review which he has been incorporating. I proposed several soft-fork models which can be deployed safely and immediately, which do not have ledger risk. I have another proposal relating to simplified soft-fork one-way pegs which I'll write up in a bit. I think there are still issues in Jeff's proposal but he is very open and collaborating and there maybe related but different proposals presently. >> As you can probably tell I think a unilateral fork without wide-scale >> consensus from the technical and business communities is a deeply >> inadvisable. > > Gavin and I have been polling many key players in the ecosystem. The > consensus you seek does exist. All wallet developers (except Lawrence), all > the major exchanges, all the major payment processors and many of the major > mining pools want to see the limit lifted (I haven't been talking to pools, > Gavin has). It does not seem to me that you understand the issue. Of course they want to increase the scalability of bitcoin. So does everyone else on this mailing list. That they would support that is obvious. If you presented your unilateral action plan without explaining the risks too. I think I covered this further above. If you would like to share the company list, or we can invite them to the proposed public physical meeting, I think it would be useful for them to have a balanced view of the ledger divergence risks, and alternative in-consensus proposals underway, as well as the governance risks, maintenance risks, security incident risks. Note that other people talk to companies too, as part of their day to day jobs, or from contacts from being in the industry. You have no special authority or unique ability to talk with business people. Its just that the technical community did not know you were busy doing that. I can not believe that any company that would listen to their CTO, CSO or failing that board would be ok with the risks implied by what you are proposing on full examination. > This notion that the change has no consensus is based on you polling the > people directly around you and people who like to spend all day on this > mailing list. It's not an accurate reflection of the wider Bitcoin community > and that is one of the leading reasons there is going to be a fork. A small > number of people have been flatly ignoring LOTS of highly technical and > passionate developers who have written vast amounts of code, built up the > Bitcoin user base, designed hardware and software, and yes built companies. I know you want scale bitcoin, as I said everyone here does. I think what you're experiencing is that you've had more luck explaining your pragmatic unilateral plan to non-technical people without peer review, and so not experienced the kind of huge pushback you are getting from the technical community. The whole of bitcoin is immensely complicated such that it takes an uber-geek CS genius years to catchup, this is not a slight of any of the business people who are working hard to deploy Bitcoin into the world, its just complicated and therefore not easy to understand the game-theory, security, governance and distributed system thinking. I have a comp sci PhD in distributed systems, implemented p2p network systems and have 2 decades of applied crypto experience with a major interest in electronic cash crypto protocols, and it took me a several years to catchup and even I have a few hazy spots on low-level details, and I addictively into read everything I could find. Realistically all of us are still learning, as bitcoin combines so many fields that it opens new possibilities. What I am expecting that yourself and Gavin are thinking is that you'll knock heads and force the issue and get to consensus. However I think you have seriously misjudged the risks and have not adequately explained them to companies you are talking with. Indeed you do not fully seem to acknowledge the risks, nor to have a well thought out plan here of how you would actually manage it, nor the moral hazards of having a lone developer in hugely divisive circumstances in sole control of bitcoins running code. Those are exactly the reasons for the code change governance process! Even though you are trying to help, the full result is you are not helping achieve anything by changing a constant and starting a unilateral hard-fork (not to trivialise the work of making a patch to do that). The work to even make the constant change be feasible was a result of 1000s of hours of work by others in the development community, that is emphatically and unilaterally telling you that hard-forks are hugely inadvisable. You are trying to break the code change governance security procedure that were put in place for good reason for the security of $3b of other peoples money, even if you have a pragmatic intent to help, this is flat out unacceptable. There are also security implications to what you are proposing, which I have heard you attempting to trivialise, that are core to Bitcoins security and core functionality. > the overwhelming impression I get from a few > others here is that no, they don't want to scale Bitcoin. They already > decided it's a technological dead end. I think this is a significant mischaracterisation, and I think almost everybody is on board with a combination plan: 1. work to improve decentralisation (specific technical work already underway, and education) 2. create a plan to increase block-size in a slow fashion to not cause system shocks (eg like Jeff is proposing or some better variant) 3. work on actual algorithmic scaling In this way we can have throughput needed for scalability and security work to continue. As I said you can not scale a O(n^2) broadcast network by changing constants, you need algorithmic improvements. People are working on them already. All of those 3 things are being actively worked on RIGHT NOW, and in the case of algorithmic scaling and improve decentralisation have been worked on for months. You may have done one useful thing which is to remind people that blocks are only 3x-4x below capacity such that we should look at it. But we can not work under duress of haste, nor unilateral ultimatums, this is the realm of human action that leads to moral hazard, and ironically reminds us of why Satoshi put the quote in the genesis block. Bitcoin is too complex a system with too much at stake to be making political hasty decisions, it would be negligent to act in such a way. Again please consider that you did your job, caused people to pay attention, but return to the process, submit a BIP, retract the unilateral hard-fork which is so dangerous and lets have things be calm, civil and collaborative in the technical zone of Bitcoin and not further alarm companies and investors. Adam ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ----- End forwarded message -----

12 29

NSA liquid cooled computing
by grarpamp 07 Jul '15

07 Jul '15

http://www.grcooling.com/wp-content/uploads/2015/06/NSA-The-Next-Wave.pdf

1 0