Re: [Bitcoin-development] Block Size Increase
Any proposal to switch to a new hardcorded value so we have time to *really* figure out later what's next and all implications, is a road to a gigantic issue later when we want to switch to that next. Sure we would have more time to think about, research all implications, simulate, discuss, etc. But the ability then to agree enough on a change to roll it out successfully will be much smaller, because of the economy being built on top of Bitcoin being much larger and the technical specifications of Bitcoin being closer to a complete freeze. What I'm trying to say is that we should look at long term lasting solutions even if it takes more effort and time right now and puts the network into some troubles for a while, because they're short term troubles. (You define troubles, depending on which side you stand at the moment...). I personally believe in adaptive block size mechanisms, because: (i) common sense tells me harcoding is never a solution for a system whose usage is for many aspects unpredictable (ii) we can't rely on human consensus to adapt it (seeing the mess it is already this time). It would have the advantage to place this block size issue entirely as part of the algorithmic contract you agree on when you use Bitcoin, similar to the difficulty adapation or the block reward. Jérémie 2015-05-07 21:37 GMT+02:00 Mike Hearn m...@plan99.net: These statements may even be true, but they're no logical conclusions even if they seem obvious to you. I don't think those claims are strictly true, specially because they involve predictions about what people will do. But if they're true they require some proof or at least some explanation. Thank you for your patience, Jorge. I have written up an explanation of what I think will happen if we run out of capacity: https://medium.com/@octskyward/crash-landing-f5cc19908e32 Now I'm going to go eat some dinner :) -- 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
Re: [Bitcoin-development] Block Size Increase
I have written up an explanation of what I think will happen if we run out of capacity: https://medium.com/@octskyward/crash-landing-f5cc19908e32 Looks like a solid description of what would happen. I fail to see how this description wouldn't be applicable also to a 20MB-network in some time in the future, say ~3 years from now, if Bitcoin keeps taking off. If you agree that it will be harder in the future to change the block limit again, and we switch to hardcoded 20MB, then aren't we just going from an immediate relief to a future larger blockage? Now I'm going to go eat some dinner :) -- 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
Re: [Bitcoin-development] Fwd: death by halving
Answering today's concerns with yesterday's facts is dangerous, especially with bitcoin on a 4 years period. I personally consider all arguments like we went through once, and nothing special. So no disturbance worthy of discussion to expect baseless. Also, starting a topic with mentions of death is not leading to any useful discussion. @Topic starters: don't oversell your topic with that kind of vocabulary hype. death by halving, seriously? @Everybody else: don't focus on the chosen vocabulary, or use it to discard what might be a relevant discussion topic. The fact that a topic was brought up many times since a long time, does not mean it is not relevant. It only means it is a recurring concern. I read no convincing argument against a significant disturbance of the mining market to come. The fact that it is known in advance is no counter argument to me. Environmental conditions will have changed so much, the next halving occurence might have nothing to do with the previous one, and it should be perfectly ok to discuss it instead of putting the whole thing under the carpet. What is most important to the discussion to me: the main difference between the last halving and the one to come is the relative weight of ideology vs. rationality in miners's motivations. Effectively putting us closer to the original bitcoin premises (miners fully rational). Miners were close to being 100% individuals last halving, they are now largely for-profit companies. This isn't a change we can overlook with pure maths or with previous experience. Jeremie DL 2014-10-28 21:36 GMT+01:00 Gregory Maxwell gmaxw...@gmail.com: On Tue, Oct 28, 2014 at 8:17 PM, Ferdinando M. Ametrano ferdinando.ametr...@gmail.com wrote: On Oct 25, 2014 9:19 PM, Gavin Andresen gavinandre...@gmail.com wrote: We had a halving, and it was a non-event. Is there some reason to believe next time will be different? In november 2008 bitcoin was a much younger ecosystem, Or very old, indeed, if you are using unsigned arithmetic. [...] and the halving happened during a quite stable positive price trend Hardly, http://bitcoincharts.com/charts/mtgoxUSD#rg60zczsg2012-10-01zeg2012-12-01ztgSzm1g10zm2g25zv Moreover, halving is not strictly necessary to respect the spirit of Nakamoto's monetary rule It isn't, but many people have performed planning around the current behaviour. The current behaviour has also not shown itself to be problematic (and we've actually experienced its largest effect already without incident), and there are arguable benefits like encouraging investment in mining infrastructure. This thread is, in my opinion, a waste of time. It's yet again another perennial bikeshedding proposal brought up many times since at least 2011, suggesting random changes for non-existing(/not-yet-existing) issues. There is a lot more complexity to the system than the subsidy schedule. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development 2014-10-28 21:57 GMT+01:00 Alex Mizrahi alex.mizr...@gmail.com: This thread is, in my opinion, a waste of time. It's yet again another perennial bikeshedding proposal brought up many times since at least 2011, suggesting random changes for non-existing(/not-yet-existing) issues. There is a lot more complexity to the system than the subsidy schedule. Well, the main question is what makes Bitcoin secure. It is secured by proofs of work which are produced by miners. Miners have economic incentives to play by the rules; in simple terms, that is more profitable than performing attacks. So the question is, why and when it works? It would be nice to know the boundaries, no? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Partial wallet rescan
Hi all, Before starting to implement a patch for a specific need, I would like to be sure that it was not written already and available somewhere. This list is probably my best chance. I would like to add an optional parameter block_heigh to -rescan, from which the rescan would then start. When performing the wallet rescan, everything before the block number block_heigh would be ignored. Thus, it would do pretty much the same thing as the wallet birthday mechanism (which relies on nTimeFirstKey), the difference being that the point in time where to start would be *explicitly* given by the user, at launch time, on the command line. Another possiblity is to provide as parameter a time stamp instead of a block height; the interesting part for me is that anyway that information is explicitly provided by the user. Regards, Jeremie -- Jeremie Dubois-Lacoste, PhD. Belgian Bitcoin Association, Director. Université Libre de Bruxelles, Post-Doctoral Researcher. -- 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] Looking for GREAT C++ developer for exciting opportunity in bitcoin space
Hey, I doubt this list is for this kind of thing. I am following bitcoin-development since a long time but never participated because I believe discussions should be well-focused and I never had anything relevant to say. Evan, I am pretty sure that emails such as yours will cause the true discussions between core-dev (or those closely graviting around) to move elsewhere on a less public channel, where people like me won't be able to follow them anymore. Thus my request: please post this kind of things elsewhere, because you are hijacking a list just to target his audience, but not to contribute relevant content. (A definition usually describing spam). Cheers, Jeremie 2013/12/29 Evan Duffield eduffiel...@gmail.com: Hello, We’re a startup looking for 1 or 2 really good C++ programmer that is familiar with the bitcoin internals to help with a for-profit startup. We will be able to provide more information about the project after signing a non-compete/non-disclosure agreement. Our coin will be one of the truly unique coins that are not just a clone of the original Bitcoin code. In short the project will be a merge-mined altcoin that will provide a very useful service to the whole crypto-coin ecosystem. If you have added any features to Bitcoin or related technologies this is a definite bonus. Please include information about the work you’re done in the space. We have detailed plans on how to implement it and the roles we are looking to fill. If interested please email eduffiel...@gmail.com with a description of your work experience and we’ll vett the applications and share our plans to see if you’re interested. Thanks, Evan Kyle Hawk Financial Group, LLC -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
