Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn m...@plan99.net wrote: Dude, calm down. Well hold on, his concerns are real and he seems perfectly calm to me and others apparently. and Gavin already said long ago he wouldn't just commit something, even though he has the ability to do so. Nobody is worried about Gavin or anyone else making commits to git repositories. You'll notice that this wasn't even mentioned in the original email you were replying to. Instead, the email was talking about commit access, which is a property of GitHub's repositories. So why did I say it? Because it's consistent with what I've always said: (That's not a good reason.) you cannot run a codebase like Wikipedia Wikipedia is a top-down centralized authority-based hierarchy. That's pretty close to what you're proposing. That's what everyone else is disagreeing with. You seem to have switched your position mid-flight...? This is not a radical position. That's how nearly all coding projects work. I have been involved with open source for 15 years and the 'single maintainer who makes decisions' model is normal, even if in some large codebases subsystems have delegated submaintainers. There are a number of reasons why that perspective is broken; throughout our conversations others have repeatedly reminded you (such as in -wizards) that forking an open-source repository is not at all like a hard-fork of the blockchain. Anyone can be glorious leader of any repository they want, that's how open-source works. However, it's critical that bitcoin users are never convinced to trust BDFLs or anything else that can be compromised. Should all bitcoin users suddenly start using software with BDFLs, even multiple implementations with separate BDFLs, then those users can be trivially compromised through their trust in those individuals and projects. The alternative is that every developer and every user is personally responsible for self-validation of the rules, checking for correctness and validity. Happy coincidence that this seems to match the strategy of operating the bitcoin network itself, which is to run a node that sees everything and validates all the transactions. Anyone is able to find an error in logic or flaw in the system rules, and they should make it known as widely as possible so that others may evaluate the evidence and consider which solutions preserve the important properties of the system. This is not a matter of majorities or minorities; these arguments should be true for anyone independent of who or what they are, or what level of unpopularity they may have. Anything other than this is somewhat radical, and I am confused as to why others have been talking about developer consensus. I suspect that the reason why they have been saying developer consensus is because they are talking about the Bitcoin Core project on GitHub at the moment. But the topic switched to contentious hard-forks already, which is not a topic of repositories but a topic of the blockchain and network; and in the context of contentious hard-forks it is clear why everyone individually must evaluate the rules and decide whether they the software is correct, or whether changes can trivially cause catastrophic broken hard-forks. These lines of reasoning should be true for everyone, and not merely true for one person but not another. Users, companies and developers must be aware of this, even though it's different from their usual expectations of how systems operate and are maintained. And it is important to be careful to not misconstrue this to others because it is entirely possible to unintentionally convince others that traditional and centralized models are safely applicable here. I realise some people think this anti-process leads to better decision making. I disagree. It leads to no decision making, which is not the same thing at all. Well, if you're talking about the recent disputes regarding a certain patch to hard-fork the blockchain, a decision to not include such a patch seems like the very definition of a decision. Gavin and I say - there is a process, and that process is a hard fork of the block chain. I doubt that other bitcoin software maintainers would agree with that sort of toxic reasoning; contentious hard-forks are basically a weapon of war that you can use against any other collaborator on any bitcoin project. Why would anyone want to collaborate on such a hostile project? How would they even trust each other? - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scaling Bitcoin with Subchains
On Wed, May 27, 2015 at 9:16 PM, Andrew onelinepr...@gmail.com wrote: You should also keep in mind the big picture when it comes to decentralization. If the hard drives (or tapes) can only be produced by a small number of large companies like Western Digital or Seagate, then you can't really count those for a decentralized system. A truly decentralized system would have the devices needed to participate in (and verify) the system be easily created by a regular user of the system without relying on a central power. So for example, the hard drives needed to store the bitcoin transaction records should be able to be produced at a regular person's home on a 3D printer starting from just the raw materials. I don't know how close we are to this ideal, but just pointing out that it needs to be considered. This is also a reason why I like that Bitcoin uses the simple SHA sum for mining instead of a more complicated function such as scrypt. It makes it easier for small scale entities to understand and to produce the ASIC miners. I am a huge fan of do-it-yourself at-home ASIC manufacturing. The original 4004 and earlier devices are within the scope of what could be accomplished in a home environment. The homecmos project is an interesting glimpse at these possibilities. Relevant-scale mining will most likely never be an option for home manufacturing, but bitcoin wallets and other devices can definitely be etched by hand or using maskless projector lithography. Here's what the homecmos group was up to: https://code.google.com/p/homecmos/ http://homecmos.drawersteak.com/wiki/ http://diyhpl.us/~bryan/papers2/optics/photolithography/DIY%20fabrication%20of%20microstructures%20by%20projection%20photolithography.pdf LCD projection lithography: http://diyhpl.us/~bryan/papers2/optics/photolithography/Cell%20micropatterning%20using%20photopolymerization%20with%20a%20liquid%20crystal%20device%20(LCD)%20commercial%20projector%20-%20Itoga%20-%202003.pdf http://diyhpl.us/~bryan/papers2/optics/photolithography/Development%20of%20microfabrication%20technology%20with%20maskless%20photolithography%20device%20using%20LCD%20projector%20-%20Itoga%20-%202010.pdf http://diyhpl.us/~bryan/papers2/optics/photolithography/Second-generation%20maskless%20photolithography%20device%20for%20surface%20micropatterning%20and%20microfluidic%20channel%20fabrication%20(using%20an%20LCD%20projector).pdf DMD lithography: http://diyhpl.us/~bryan/papers2/optics/photolithography/Maskless%20microscopic%20lithography%20through%20shaping%20ultraviolet%20(UV)%20laser%20with%20digital%20micromirror%20device%20(DMD)%20-%202013.pdf http://diyhpl.us/~bryan/papers2/optics/photolithography/A%20maskless%20photolithographic%20prototyping%20system%20using%20a%20low-cost%20consumer%20projector%20and%20a%20microscope.pdf There's actually a method of doing this with conventional camera roll film: https://groups.google.com/d/msg/diybio/5hpQXZ6hFKY/baGNfY_-Wx8J - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Fri, May 8, 2015 at 2:20 AM, Matt Whitlock b...@mattwhitlock.name wrote: - Perhaps the hard block size limit should be a function of the actual block sizes over some trailing sampling period. For example, take the median block size among the most recent 2016 blocks and multiply it by 1.5. This allows Bitcoin to scale up gradually and organically, rather than having human beings guessing at what is an appropriate limit. Block contents can be grinded much faster than hashgrinding and mining. There is a significant run-away effect there, and it also works in the gradual sense as a miner probabilistically mines large blocks that get averaged into that 2016 median block size computation. At least this proposal would be a slower way of pushing out miners and network participants that can't handle 100 GB blocks immediately.. As the size of the blocks are increased, low-end hardware participants have to fall off the network because they no longer meet the minimum performance requirements. Adjustment might become severely mismatched with general economic trends in data storage device development or availability or even current-market-saturation of said storage devices. With the assistance of transaction stuffing or grinding, that 2016 block median metric can be gamed to increase faster than other participants can keep up with or, perhaps worse, in a way that was unintended by developers yet known to be a failure mode. These are just some issues to keep and mind and consider. - Bryan http://heybryan.org/ 1 512 203 0507 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 7, 2015 at 9:05 AM, Mike Hearn m...@plan99.net wrote: Maybe you dislike that idea. It's so centralised. So let's say Gavin commits his patch, because his authority is equal to all other committers. Someone else rolls it back. Gavin sets up a cron job to keep committing the patch. Game over. You cannot have committers fighting over what goes in and what doesn't. That's madness. There must be a single decision maker for any given codebase. Hmm, git repositories don't quite work like that. Instead, you should imagine everyone having a local copy of the git repository. Each developer synchronizes their git repository with other developers. They merge changes from specific remote branches that they have received. Each developer has their own branch and each developer is the single decision maker for the artifact that they compile. - Bryan http://heybryan.org/ 1 512 203 0507 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Wed, May 6, 2015 at 5:12 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Well, there has been significant public discussion in #bitcoin-wizards on irc.freenode.net which is available in public logs, specifically about why increasing the max block size is kicking the can down the road while possibly compromising blockchain security. There were many excellent objections that were raised that, sadly, I see are not referenced at all in the recent media blitz. Frankly I can't help but feel that if contributions, like those from #bitcoin-wizards, have been ignored in lieu of technical analysis, and the absence of discussion on this mailing list, that I feel perhaps there are other subtle and extremely important technical details that are completely absent from this--and other-- proposals. I have some rather general thoughts to offer. Secured decentralization is the most important and most interesting property of bitcoin. Everything else is rather trivial and could be achieved millions of times more efficiently with conventional technology. Our technical work should be informed by the technical nature of the system we have constructed. I suspect that as bitcoin continues to grow in all dimensions and metrics, that we will see an unending wave of those who are excited by the idea of Something Different in the face of archaic, crumbling software and procedures in the rest of the financial world. Money has found its way into every aspect of human life. There's no doubt in my mind that bitcoin will always see the most extreme campaigns and the most extreme misunderstandings. Like moths to a flame or water in the desert, almost everyone is excited by ANY status quo change whatsoever. This is something that we have to be vigilante about, because their excitement is motivation to do excellent work, not simply any work. For some who are excited about general status quo changes that bitcoin represents, they may not mind if bitcoin decentralization disappears and is replaced with just a handful of centralized nodes. Whereas for development purposes we must hold ourselves to extremely high standards before proposing changes, especially to the public, that have the potential to be unsafe and economically unsafe. We have examples from NASA about how to engineer extremely fault tolerant systems, and we have examples from Linux about how to have high standards in open-source projects. Safety is absolutely critical, even in the face of seemingly irrational excuberance of others who want to scale to trillions of daily coffee transactions individually stored forever in the blockchain. When designing bitcoin or even some other system, an important design target is what the system should be capable of. How many transactions should the system perform? What is the correct number of transactions for a healthy, modern civilization to perform every day? And how fast should that (not) grow? Should we allow for 2 billion trillion coffee transactions every day, or what about 100 trillion transactions per second? I suspect that these sorts of questions are entirely unanswerable and boring. So in the absence of technical targets to reach during the design phase, I suspect that Jeff Garzik was right when he pointed out a few months ago that bitcoin is good at settlement and clearing. There are many potential technical solutions for aggregating millions (trillions?) of transactions into tiny bundles. As a small proof-of-concept, imagine two parties sending transactions back and forth 100 million times. Instead of recording every transaction, you could record the start state and the end state, and end up with two transactions or less. That's a 100 million fold, without modifying max block size and without potentially compromising secured decentralization. The MIT group should listen up and get to work figuring out how to measure decentralization and its security :-). Maybe we should be collectively pestering Andrew Miller to do this, too. No pressure, dude. Getting this measurement right would be really beneficial because we would have a more academic and technical understanding to work with. I would also characterize this as high priority next to the formally verified correctness proofs for Script and libbitcoinconsensus. Also, I think that getting this out in the open on this mailing list is an excellent step forward. - Bryan http://heybryan.org/ 1 512 203 0507 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Re: [Bitcoin-development] Electrum 2.0 has been tagged
On Wed, Mar 11, 2015 at 11:09 PM, Gregory Maxwell gmaxw...@gmail.com wrote: For an emergency transition the user is probably better off with an explicit unstructured mass private key export, and a sweep function; and guaranteeing compatibility with that is much easier; and because it moves funds in one direction there is much less chance of going from secure to insecure. I haven't looked at the existing sweep implementations, but it would be unfortunate if sweep functions were not available that create at least the same number of keys, or possibly more, for the purposes of sweeping. I suppose there are different levels of emergency, where perhaps you want to sweep all at once in a single transaction and lose out on (already nebulous) privacy benefits. I say nebulous because broadcasting a bunch of transactions all at the same time during the sweep can compromise privacy even when the transactions have no common ancestor outputs. - Bryan http://heybryan.org/ 1 512 203 0507 -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
On Sun, Feb 22, 2015 at 8:11 AM, Adam Back a...@cypherspace.org wrote: away from that too) is how about we explore ways to improve practical security of fast confirmation transactions, and if we find something better, then we can help people migrate to that before deprecating the current weaker 0-conf transactions. Scenario: Users are using some system in a way that the system was not intended to be used. Let me also further constrain the scenario and suggest that the function (pretend that means instantaneous confirmed transactions) that the user wants is impossible. So in this scenario, is it your job as some developer to change the system to do something it wasn't designed to do? I mean, you certainly weren't the one telling them they should accept zero confirmation transactions. Also, I make no claims as to whether this scenario maps accurately to the current topic. - Bryan http://heybryan.org/ 1 512 203 0507 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sat, Feb 14, 2015 at 1:04 PM, Adam Back a...@cypherspace.org wrote: That its highly complex to maintain strict consensus between bitcoin versions, does not justify consensus rewrite experiments Correct. However, those maintenance costs absolutely do justify working towards formal proofs of correctness for the existing implementation. These plans are no secret and are publicly discussed, but I think it would be instrumental to outsiders if the correctness plans and ongoing progress could be mentioned whenever a warning is made about unjustified and dangerous Bitcoin consensus rewrite attempts. - Bryan http://heybryan.org/ 1 512 203 0507 -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets
On Thu, Sep 25, 2014 at 8:53 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I've pinged some people privately but also pinging the list… no commentary on this proposal? One possible reason is that non-subscribed users aren't able to access the file through sourceforge. The attachment through their web interface is giving back HTTP 500. see http://sourceforge.net/p/bitcoin/mailman/attachment/53F38542.2000704%40monetas.net/1/ - Bryan http://heybryan.org/ 1 512 203 0507 -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reconsidering github
On Tue, Aug 19, 2014 at 7:02 AM, Jeff Garzik jgar...@bitpay.com wrote: As a first step, one possibility is putting the primary repo on bitcoin.org somewhere, and simply mirroring that to github for each push. Smaller first step would be to mirror the git repository on bitcoin.org, which is necessary anyway before switching primaries. - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
