Re: [Bitcoin-development] Block Size Increase
I am more fazed by PR 5288 and PR 5925 not getting merged in, than by this thread. So, casting my ballot in favor of the block size increase. Clearly, we're still rehearsing proper discourse, and that ain't gonna get fixed here and now. On Thu, May 7, 2015 at 9:29 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: On 05/07/15 19:34, Mike Hearn wrote: The appropriate method of doing any fork, that we seem to have been following for a long time, is to get consensus here and on IRC and on github and *then* go pitch to the general public So your concern is just about the ordering and process of things, and not about the change itself? No, I'm very concerned about both. I have witnessed many arguments in IRC about block sizes over the years. There was another one just a few weeks ago. Pieter left the channel for his own sanity. IRC is not a good medium for arriving at decisions on things - many people can't afford to sit on IRC all day and conversations can be hard to follow. Additionally, they tend to go circular. I agree, thats why this mailing list was created in the first place (well, also because bitcointalk is too full of spam, but close enought :)) That said, I don't know if you can draw a line between the ins and outs like that. The general public is watching, commenting and deciding no matter what. Might as well deal with that and debate in a format more accessible to all. Its true, just like its true the general public can opt to run any version of software they want. That said, the greater software development community has to update /all/ the software across the entire ecosystem, and thus provide what amounts to a strong recommendation of which course to take. Additionally, though there are issues (eg if there was a push to remove the total coin limit) which are purely political, and thus which should be up to the greater public to decide, the blocksize increase is not that. It is intricately tied to Bitcoin's delicate incentive structure, which many of the development community are far more farmiliar with than the general Bitcoin public. If there were a listserv that was comprised primarily of people on #bitcoin-wizards, I might have suggested a discussion there, first, but there isnt (as far as I know?). If, instead, there had been an intro on the list as I think we should do the blocksize increase soon, what do people think? There have been many such discussions over time. On bitcointalk. On reddit. On IRC. At developer conferences. Gavin already knew what many of the objections would be, which is why he started answering them. But alright. Let's say he should have started a thread. Thanks for starting it for him. Now, can we get this specific list of things we should do before we're prepared? YesI'm gonna split the topic since this is already far off course for that :). A specific credible alternative to what? Committing to blocksize increases tomorrow? Yes, doing more research into this and developing software around supporting larger block sizes so people feel comfortable doing it in six months. Do you have a specific research suggestion? Gavin has run simulations across the internet with modified full nodes that use 20mb blocks, using real data from the block chain. They seem to suggest it works OK. What software do you have in mind? Let me answer that in a new thread :). -- 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 -- 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
[Bitcoin-development] Why Bitcoin is and isn't like the Internet
This is a response to a wonderfully insightful recent post by Joichi Ito, the Director of the MIT Media Lab. In it, Dr. Ito, notably a former Board Member of ICANN, offered his thoughts on Why Bitcoin is and isn't like the Internet and asked a most pertinent question: Whether there is an ICANN equivalent needed for Bitcoin. As suggested in recent posts to the mailing list, I believe there might be, but for a reason that may not seem obvious at first. Alan Reiner expressed the need this way: I think one of the biggest issues facing Bitcoin right now is not the lack of a 'killer app.' It is lack of insurance options. Early adopters would like to believe that the majority of users will hold their own Bitcoin, but I believe that is not a realistic option when life-changing quantities of Bitcoin are involved. We should not trust Grandma to secure her own retirement savings via complicated computer maneuvers. More to the point, she should not trust herself or anyone else (sic!) to hold it unless there is a strong protection against loss events. Right now the solution is for Grandma to avoid keeping her money in Bitcoin. Bitcoin needs a strong backbone of insured storage options so that Grandma can confidently participate in this new technology. This is certainly an observation to take heed of coming from the founder of Armory Technologies. The protection against loss events ought to be understood in the broadest sense. What is needed is a disaster recovery mechanism. Andreas Antonopoulos remarks expressed this candidly last year: Bitcoin doesn't have a middle of the road mediocre growth model. It basically either dies, because of a fundamental flaw in the Bitcoin system. Not an external factor, an internal factor: We blow it up by accident. And that could happen... Bitcoin will play out in the next three years. In the next three years we're going to see Bitcoin arrive on the global stage and make a substantial impact, both in financial terms and in political terms. It will happen. Or it will die. Either way. I'm not sure. In which case we'll reboot another currency. A body, not entirely unlike ICANN, can manage the nexus to the physical world, and help address Bitcoin's catastrophic failure modes. Bitcoin's coin ownership protocol would thus join the ranks of its payment protocol, coin issuance protocol, consensus mechanism and inflation control that pose no lethal threat to the ecosystem. In addition to their coin-agnostic nature, I suspect the high valuation of large Bitcoin hubs relative to Bitcoin's market cap at this stage in its lifecycle is partly reflective of the sneaking suspicion that a custodial bitcoin (a bitcoin attached to an identity) may be worth more than a non-custodial one. With this in mind, I'll pitch in for the ticket should Dr. Ito decide to join the next month's DevCore Boston conference aimed at supporting the future development of Bitcoin. It's an hour's walk from MIT after all. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A look back and a look forward
I think the observation about Target vs Bitcoin exchanges is a sharp one, but I'm not sure how your proposal helps. You say it's an optional identity layer, but obviously any thief is going to opt out of being identified. Let me translate it to this year's vocabulary. Think of BCIs as a sidechain: let the legacy financial system migrate, to the extent desired, to a more heavily regulated pegged sidechain with a stronger identity layer. Let protocol-level rules regulate this nexus between the custodial (sidechain) and non-custodial address spaces (blockchain). This isn't entirely unlike the rules currently governing coin issuance i.e. coinbase transactions. Let the market forces play it out. Iterate as needed. I suspect that in retrospect it'll seem obvious. Many moons from now the balance might shift between the two, but it won't matter much. The system will have means to recover from catastrophic failure modes. To help internalize such an evolution, please consider the layers the Bitcoin protocol builds on top of: segment 52:32 (The Internet is being upgraded) of the BBC documentary Inside The Dark Web ( https://www.youtube.com/watch?v=qXajND7BQzk#t=3152). Kaspersky's comments a few minutes earlier (50:06) aren't entirely out of context here either. Clearly, the need is acute for Bitcoin to become institutional i.e. for billions of dollars of human value to flow through it, as one Money 20/20 participant put it. On Fri, Jan 9, 2015 at 2:00 PM, Mike Hearn m...@plan99.net wrote: This needn't be so, once an optional identity layer, modeled after the Internet itself, is provided, as proposed in late August of last year on this mailing list I think the observation about Target vs Bitcoin exchanges is a sharp one, but I'm not sure how your proposal helps. You say it's an optional identity layer, but obviously any thief is going to opt out of being identified. For things like the Bitstamp hack, it's not clear how identity can help, because they were already doing KYC for all their customers. To take that further at the protocol level would require* all* transactions to have attached identity info, and that isn't going to happen - it wouldn't be Bitcoin, at that point. I think that long term, it's probably possible to defend private keys adequately, even for large sums of money (maybe not bitstamp-large but we'll see). You can have very minimalist secure hardware that would have some additional policies on top, like refusing to sign transactions without an identity proof of who controls the target address. Very tight hot wallets that risk analyse the instructions they're receiving have been proposed years ago. No such hardware presently exists, but that's mostly because implementations always lag behind a long way behind ideas rather than any fundamental technical bottleneck. Perhaps the Bitstamp event will finally spur development of such things forward. -- 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
[Bitcoin-development] A look back and a look forward
Alex Daley recently stated that one of the problems with Bitcoin is that it takes us backwards in the transaction chain. Suddenly, you're dealing with something that's much more cash-like. If Target had been hacked, and instead of using credit-cards, what was stolen from them were actually bitcoins, that they have been storing Bitcoin addresses in their systems and those systems were compromised, Target wouldn't just have a PR nightmare in their hands. They would be out of business. Of course, it needn't be Target. The scenario has played out with a number of exchanges, and is a sword of Damocles hanging over the cryptocurrency space. The recent Winklevoss Bitcoin Trust SEC filing warns that the Trust’s bitcoins may be subject to loss, damage, theft or restriction on access. There is a risk that part or all of the Trust’s bitcoins could be lost, stolen or destroyed. The Sponsor believes that the Trust’s bitcoins held in the Trust Custody Account will be an appealing target to hackers or malware distributors seeking to destroy, damage or steal the Trust’s bitcoins. Although the Security System’s design includes various elements, such as redundancy, segregation and cold storage, to minimize the risk of loss, damage and theft, neither the Custodian nor the Sponsor can guarantee that the Security System will prevent such loss, damage or theft... This needn't be so, once an optional identity layer, modeled after the Internet itself, is provided, as proposed in late August of last year on this mailing list: http://sourceforge.net/p/bitcoin/mailman/message/32737796/ http://sourceforge.net/p/bitcoin/mailman/message/32742809/ I hope it is apparent that this is the killer app folks have been searching for in vain. Like its Internet analogues, BCIs will not be created overnight and without collaboration - and TNABC is as good a place as any for it. -- 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] Open development processes and reddit charms
I'll pick up where you left off, Jeff. The thought process behind the Bitcoin Core threading model, platform support, libification, dependency management, core data structures, DoS mitigation, script evolution, scalability roadmap... just to scratch the surface, is likely never going to be apparent entirely from the source code itself, and will not, in its current form, be easily understood before digesting repository docs, repo issues, pull requests, IRC logs, mailing list archives (open and closed), forum posts, wiki articles, historical repositories, the foundation's technical blog, whitepapers, to name a few. I'd rather not guess how many have got a grip on it. If any, across the entire spectrum. It may be the bottleneck to address. I encourage everyone to take a look at the C# Language Design Notes* on codeplex. We'll know we've met the challenge when folks are no longer digging up gmaxwell's IRC comments to understand the rationale on nScriptCheckThreads, nor having to refer to sipa's stackexchange to figure out chainstate blockindex key/value pairs. * https://roslyn.codeplex.com/wikipage?title=CSharp%20Language%20Design%20NotesreferringTitle=Documentation On Tue, Dec 16, 2014 at 5:59 PM, Jeff Garzik jgar...@bitpay.com wrote: It can be useful to review open source development processes from time to time. This reddit thread[1] serves use both as a case study, and also a moment of OSS process introduction for newbies. [1] http://www.reddit.com/r/Bitcoin/comments/2pd0zy/peter_todd_is_saying_shoddy_development_on_v010/ *Dirty Laundry* When building businesses or commercial software projects, outsiders typically hear little about the internals of project development. The public only hears what the companies release, which is prepped and polished. Internal disagreements, schedule slips, engineer fistfights are all unseen. Open source development is the opposite. The goal is radical transparency. Inevitably there is private chatter (0day bugs etc.), but the default is openness. This means that is it normal practice to air dirty laundry in public. Engineers will disagree, sometimes quietly, sometimes loudly, sometimes rudely and with ad hominem attacks. On the Internet, there is a pile-on effect, where informed and uninformed supporters add their 0.02 BTC. Competing interests cloud the issues further. Engineers are typically employed by an organization, as a technology matures. Those organizations have different strategies and motivations. These organizations will sponsor work they find beneficial. Sometimes those orgs are non-profit foundations, sometimes for-profit corporations. Sometimes that work is maintenance (keep it running), sometimes that work is developing new, competitive features that company feels will give it a better market position. In a transparent development environment, all parties are hyperaware of these competing interests. Internet natterers painstakingly document and repeat every conspiracy theory about Bitcoin Foundation, Blockstream, BitPay, various altcoin developers, and more as a result of these competing interests. Bitcoin and altcoin development adds an interesting new dimension. Sometimes engineers have a more direct conflict of interest, in that the technology they are developing is also potentially their road to instant $millions. Investors, amateur and professional, have direct stakes in a certain coin or coin technology. Engineers also have an emotional stake in technology they design and nurture. This results in incentives where supporters of a non-bitcoin technology work very hard to thump bitcoin. And vice versa. Even inside bitcoin, you see tree chains vs. side chains threads of a similar stripe. This can lead to a very skewed debate. That should not distract from the engineering discussion. Starting from first principles, Assume Good Faith[2]. Most engineers in open source tend to mean what they say. Typically they speak for themselves first, and their employers value that engineer's freedom of opinion. Pay attention to the engineers actually working on the technology, and less attention to the noise bubbling around the Internet like the kindergarten game of grapevine. [2] http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith Being open and transparent means engineering disagreements happen in public. This is normal. Open source engineers live an aquarium life[3]. [3] https://www.youtube.com/watch?v=QKe-aO44R7k *What the fork?* In this case, a tweet suggests consensus bug risks, which reddit account treeorsidechains hyperbolizes into a dramatic headline[1]. However, the headline would seem to be the opposite of the truth. Several changes were merged during 0.10 development which move snippets of source code into new files and new sub-directories. The general direction of this work is creating a libconsensus library that carefully encapsulates consensus code in
Re: [Bitcoin-development] Request for review/testing: headers-first synchronization in Bitcoin Core
When forgoing bootstrapping due to disk space constraints, you, and the network, are likely better off -reindex-ing from current blk000??.dat files. Which brings up an interesting point: The improvements related to the headers first approach are likely to increase, how ever marginally, the percentage of block exchange-related traffic, as it is less painful now to be catching up. It'd be interesting to see the statistics, not from a single node perspective, but from the viewpoint of an Internet backbone provider, say through the cables coming ashore in Cornwall. For the incurred bandwidth expense would invariably trickle down to transaction fees in an equilibrium model. There is an opportunity somewhere in this. On Sun, Oct 12, 2014 at 7:13 PM, Jameson Lopp jameson.l...@gmail.com wrote: Great work, Pieter. I've been spooling up several nodes per week lately and can testify that stalled downloads during initial syncing are a pain. I usually forgo bootstrapping on VPSes because I don't want to have to adjust the disk space allocation. With headers-first I'm saturating my home cable connection with download rates of 4 MB/s until block 295,000 at which point CPU becomes the bottleneck and it settles down in the 1 MB/s range. It took 6 minutes for my node to sync to block height 100,000 22 minutes to reach height 200,000 62 minutes to reach height 250,000 125 minutes to reach height 295,000 144 minutes to reach height 300,000 248 minutes to reach height 325,000 - Jameson On 10/11/2014 07:34 PM, Pieter Wuille wrote: Hi all, I believe that a large change that I've been working on for Bitcoin Core is ready for review and testing: headers-first synchronization. In short, it changes the way the best chain is discovered, downloaded and verified, with several advantages: * Parallel block downloading (much faster sync on typical network connections). * No more stalled downloads. * Much more robust against unresponsive or slow peers. * Removes a class of DoS attacks related to peers feeding you low-difficulty valid large blocks on a side branch. * Reduces the need for checkpoints in the code. * No orphan blocks stored in memory anymore (reducing memory usage during sync). * A major step step towards an SPV mode using the reference codebase. Historically, this mode of operation has been known for years (Greg Maxwell wrote up a description of a very similar method in https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync in early 2012, but it was known before that), but it took a long time to refactor these code enough to support it. Technically, it works by replacing the single-peer blocks download by a single-peer headers download (which typically takes seconds/minutes) and verification, and simultaneously fetching blocks along the best known headers chain from all peers that are known to have the relevant blocks. Downloading is constrained to a moving window to avoid unbounded unordering of blocks on disk (which would interfere with pruning later). At the protocol level, it increases the minimally supported version for peers to 31800 (corresponding to bitcoin v3.18, released in december 2010), as earlier versions did not support the getheaders P2P message. So, the code is available as a github pull request (https://github.com/bitcoin/bitcoin/pull/4468), or packaged on http://bitcoin.sipa.be/builds/headersfirst, where you can also find binaries to test with. Known issues: * At the very start of the sync, especially before all headers are processed, downloading is very slow due to a limited number of blocks that are requested per peer simultaneously. The policies around this will need some experimentation can certainly be improved. * Blocks will be stored on disk out of order (in the order they are received, really), which makes it incompatible with some tools or other programs. Reindexing using earlier versions will also not work anymore as a result of this. * The block index database will now hold headers for which no block is stored on disk, which earlier versions won't support. If you are fully synced, it may still be possible to go back to an earlier version. Unknown issues: * Who knows, maybe it will replace your familiy pictures with Nyan Cat? Use at your own risk. TL;DR: Review/test https://github.com/bitcoin/bitcoin/pull/4468 or http://bitcoin.sipa.be/builds/headersfirst. -- 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://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list
Re: [Bitcoin-development] BIP: Custodial Identities
Thank you for your feedback regarding Custodial Identities. I will address it to the mailing list for transparency. Think of it as a 1-of-2 multisig edge case where Custodian Identities are actively managed by the Bitcoin Assigned Custodial Identities Authority/Regional Bitcoin Custodial Identity Registries. Once the optional identity layer is integrated, there are so many applications beyond dispute resolution, if you could effortlessly inject Custodian Identities into the blockchain itself as easily as providing 1-of-2 public keys. Bitcoin Custodial Identities can be applied to coinbase transactions as well, in any or all jurisdictions, thus providing further incentive to keep nodes honest, or enabling a recovery mechanism in catastrophic failure events, such as a break in SHA-256. Custodians provide account addresses out of unused address space further alleviating address collisions as a psychological barrier to adoption. Custodial to non-custodial transactions could behave much like the UTXO of a coinbase transaction, which has the special condition that it cannot be spent (used as an input) for at least 100 blocks. It's based on open market competition, and there will probably always be users willing to live outside of the BCI address space. On Tue, Aug 19, 2014 at 10:23 PM, 21E14 21x...@gmail.com wrote: As suggested before submitting a BIP, I am sending this to the mailing list. Bitcoin is often described as “the currency of the Internet”, “the TCP/IP of money”, or simply “the Internet of Money”. What is needed is an optional identity layer — a Bitcoin Assigned Custodial Identities Authority, much like the Internet Assigned Numbers Authority, to oversee global Custodial Identity allocation. Such an authority delegates Custodial Identity Spaces to Regional Bitcoin Custodial Identity Registries, much like the RIRs (Regional Internet Registries) managing the allocation of Internet number resources. A Bitcoin Custodial Identity (BCI) account address would consist of a Custodial Identifier allocated by the BACIA/RBCIRs (much like a bank’s routing number), and an account address (much like an account number). Bitcoin Custodial Identities allow dispute resolution in the legal system for transactions in the BCI address space. Free market would drive and determine the demand for custodial accounts. P2PKH users not affected. Feedback is appreciated. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
