[Bitcoin-development] IMPORTANT - Bitcoin Dev List Move Tuesday, June 23rd 8pm UTC
This is an important notice to all members of the Bitcoin Dev List. *Tuesday, June 23rd 8pm UTC (1pm PDT) the following will happen.* - The current list at bitcoin-development@lists.sourceforge.net will reject all posts. - The current archives at http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/ will be exported. - The test archives at the new list will be wiped and replaced with an import from the old list. - The new list https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev will be open to posts after the archive import is complete. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Everyone may to subscribe at the new list now. Feel free to make test posts. Anything posted prior to the switchover on Tuesday will be wiped from the archives. *DMARC Status* A current issue with this list is posts from domains that require DKIM signature verification will end up in the spam folder at popular providers like gmail. Initially the new list will have that exact same problem as we will continue to have the subject tag and footer. Within a few weeks LF will upgrade Mailman to do automatic Munge From http://wiki.list.org/DEV/DMARC which will solve this problem. Warren Togami -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mailman incompatibility with DKIM ...
On Thu, Jun 18, 2015 at 11:56 PM, Mike Hearn m...@plan99.net wrote: We already removed the footer because it was incompatible with DKIM signing. Keeping the [Bitcoin-dev] prepend tag in subject is compatible with DKIM header signing only if the poster manually prepends it in their subject header. I still see footers being added to this list by SourceForge? The new list currently has footers removed during testing. I am not pleased with the need to remove the subject tag and footer to be more compatible with DKIM users. Opinions? I've asked Jeff to not use his @bitpay.com account for now. I'm guessing DKIM enforcement is not very common because of issues like this? It seems that Sourceforge silently drops DKIM enforced mail like jgarzik's. LF seems to pass along their mail but mangles the header/body and makes DKIM verification fail, which causes gmail to toss it into the spam folder. I think this behavior is slightly worse than Sourceforge because it makes the poster think their message was successfully sent (it is in the archive), but many subscribers never see it due to the spam binning. I don't see any good solution to this except an auto-reject for DKIM enforced domain postings. Yes this is rather terrible, but the instant rejection is vastly better than Sourceforge silently dropping the post or LF getting stuck in spam filters. We should also auto-reject any other reason for mail getting stuck in the moderation queue like including non-subscribers. I considered auto-rejecting spam too, but that could go horribly wrong as a false From address could make the Mailman server into a spammer itself. We may have no choice but to silently drop spam for that reason. Warren -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Mailman incompatibility with DKIM ...
Both you and jgarzik experienced mail getting tossed into gmail's spam folder thanks to DKIM... I am concerned that DKIM is too fragile and not very compatible with mailing lists. We already removed the footer because it was incompatible with DKIM signing. Keeping the [Bitcoin-dev] prepend tag in subject is compatible with DKIM header signing only if the poster manually prepends it in their subject header. I am already concerned that the lack of the Mailman footer will make it hard to identify where exactly subscribers need to go to unsubscribe or look at archives. Removing the subject tag might make DKIM enforcement work a lot better, but I can easily see our obtuse subscribers as being extra confused by this. Opinions? Warren On Thu, Jun 18, 2015 at 11:38 PM, Arthur art...@powaaa.com wrote: warren | bad_duck: try manually adding [Bitcoin-dev] to the beginning of the subject -- Arthur -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] FYI - Mailing List Move Preparations
After discussions in #bitcoin-dev in the past day we decided it would be a bad idea to link the old and new lists in some way during a transition period. We decided we are better off announcing the switchover very soon, and after that point all posts to the old list will be rejected with a message telling them where to find the new list. The proposed switchover will be on Tuesday, June 23rd, 2015. We will know an exact scheduled time for the move probably tomorrow. At the time of the switchover, the old list will reject all messages, archives will be exported and imported into the new list server, then the new list will be opened. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Please subscribe now and feel free to make test posts. We are testing configuration options to fix some long standing spam filter-related issues. Any posts to the new list prior to the final switchover will be wiped from the archives. If you have opinions on this, please join us in Freenode #bitcoin-dev and talk to warren. Warren Togami -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] FYI - Mailing List Move Preparations
BTW, if you are posting from a less popular mail server your initial post to the new list may be delayed by 5+ minutes due to greylisting. If your sending SMTP server is behaving properly then posts after the first should go through without delay. Warren On Thu, Jun 18, 2015 at 6:57 PM, Warren Togami Jr. wtog...@gmail.com wrote: After discussions in #bitcoin-dev in the past day we decided it would be a bad idea to link the old and new lists in some way during a transition period. We decided we are better off announcing the switchover very soon, and after that point all posts to the old list will be rejected with a message telling them where to find the new list. The proposed switchover will be on Tuesday, June 23rd, 2015. We will know an exact scheduled time for the move probably tomorrow. At the time of the switchover, the old list will reject all messages, archives will be exported and imported into the new list server, then the new list will be opened. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Please subscribe now and feel free to make test posts. We are testing configuration options to fix some long standing spam filter-related issues. Any posts to the new list prior to the final switchover will be wiped from the archives. If you have opinions on this, please join us in Freenode #bitcoin-dev and talk to warren. Warren Togami -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
Discomfort with Sourceforge For a while now people have been expressing concern about Sourceforge's continued hosting of the bitcoin-dev mailing list. Downloads were moved completely to bitcoin.org after the Sept 2014 hacking incident of the SF project account. The company's behavior and perceived stability have been growing to be increasingly questionable. http://www.theregister.co.uk/2013/11/08/gimp_dumps_sourceforge_over_dodgy_ads_and_installer November 2013: GIMP flees SourceForge over dodgy ads and installer https://lwn.net/Articles/646118/ May 28th, 2015: SourceForge replacing GIMP Windows downloads http://seclists.org/nmap-dev/2015/q2/194 June 3rd, 2015: Sourceforge hijacked nmap's old site and downloads. When this topic came up over the past two years, it seemed that most people agreed it would be a good idea to move. Someone always suggests Google Groups as the replacement host. Google is quickly shot down as too controversial in this community, and it becomes an even more difficult question as to who else should host it. Realizing this is not so simple, discussion then dies off until the next time somebody brings it up. http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/1943127.DBnVxmfOIh%401337h4x0r/#msg34192607 Somebody brought it up again this past week. It seems logical that an open discussion list is not a big deal to continue to be hosted on Sourceforge, as there isn’t much they could do to screw it up. I personally think moving it away now would be seen as a gesture that we do not consider their behavior to be acceptable. There are also some benefits in being hosted elsewhere, at an entity able to professionally maintain their infrastructure while also being neutral to the content. Proposal: Move Bitcoin Dev List to a Neutral Competent Entity Bitcoin is a global infrastructure development project where it would be politically awkward for any of the existing Bitcoin companies or orgs to host due to questions it would raise about perceived political control. For example, consider a bizarro parallel universe where MtGox was the inventor of Bitcoin, where they hosted its development infrastructure and dev list under their own name. Even if what they published was 100% technically and ideologically equivalent to the Bitcoin we know in our dimension, most people wouldn't have trusted it merely due to appearances and it would have easily gone nowhere. I had a similar thought process last week when sidechains code was approaching release. Sidechains, like Bitcoin itself, are intended to be a generic piece of infrastructure (like ethernet?) that anyone can build upon and use. We thought about Google Groups or existing orgs that already host various open source infrastructure discussion lists like the IETF or the Linux Foundation. Google is too controversial in this community, and the IETF is seen as possibly too politically fractured. The Linux Foundation hosts a bunch of infrastructure lists https://lists.linuxfoundation.org/mailman/listinfo and it seems that nobody in the Open Source industry considers them to be particularly objectionable. I talked with LF about the idea of hosting generic Bitcoin-related infrastructure development lists. They agreed as OSS infrastructure dev is already within their charter, so early this week sidechains-dev list began hosting there. From the perspective of our community, for bitcoin-dev it seems like a great fit. Why? While they are interested in supporting general open source development, the LF has literally zero stake in this. In addition to neutrality, they seem to be suitable as a competent host. They have full-time sysadmins maintaining their infrastructure including the Mailman server. They are soon upgrading to Mailman 3 http://wiki.list.org/Mailman3, which means mailing lists would benefit from the improved archive browser. I am not personally familiar with HyperKitty, but the point here is they are a stable non-profit entity who will competently maintain and improve things like their Mailman deployment (a huge improvement over the stagnant Sourceforge). It seems that LF would be competent, neutral place to host dev lists for the long-term. To be clear, this proposal is only about hosting the discussion list. The LF would have no control over the Bitcoin Project, as no single entity should. Proposed Action Plan - Discuss this openly within this community. Above is one example of a great neutral and competent host. If the technical leaders here can agree to move to a particular neutral host then we do it. - Migration: The current list admins become the new list admins. We import the entire list archive into the new host's archives for user convenience. - http://sourceforge.net/p/bitcoin/mailman/ Kill bitcoin-list and bitcoin-test. Very few people actually use it. Actually, let's delete the entire Bitcoin Sourceforge project as its continued existence
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
By reversing Mike's language to the reality of the situation I had hoped people would realize how abjectly ignorant and insensitive his statement was. I am sorry to those in the community if they misunderstood my post. I thought it was obvious that it was sarcasm where I do not seriously believe particular participants should be excluded. On Mon, Jun 1, 2015 at 3:06 AM, Thy Shizzle thyshiz...@outlook.com wrote: Doesn't mean you should build something that says fuck you to the companies that have invested in farms of ASICS. To say Oh yea if they can't mine it how we want stuff 'em is naive. I get decentralisation, but don't dis incentivise mining. If miners are telling you that you're going to hurt them, esp. Miners that combined hold 50% hashing power, why would you say too bad so sad? Why not just start stripping bitcoin out of adopters wallets? Same thing. -- From: Warren Togami Jr. wtog...@gmail.com Sent: 1/06/2015 10:30 PM Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements Whilst it would be nice if miners in *outside* China can carry on forever regardless of their internet situation, nobody has any inherent right to mine if they can't do the job - if miners in *outside* China can't get the trivial amounts of bandwidth required through their firewall *TO THE MAJORITY OF THE HASHRATE* and end up being outcompeted then OK, too bad, we'll have to carry on without them. On Mon, Jun 1, 2015 at 12:13 AM, Mike Hearn m...@plan99.net wrote: Whilst it would be nice if miners in China can carry on forever regardless of their internet situation, nobody has any inherent right to mine if they can't do the job - if miners in China can't get the trivial amounts of bandwidth required through their firewall and end up being outcompeted then OK, too bad, we'll have to carry on without them. But I'm not sure why it should be a big deal. They can always run a node on a server in Taiwan and connect the hardware to it via a VPN or so. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core Nightly Builds
https://bitcointalk.org/index.php?topic=571414.0 Thanks to the efforts of Cory Fields, Bitcoin Core now has deterministic builds for MacOS X. The nightly builder now has Windows, Linux and MacOS X test builds available for download. Warren On Wed, Apr 16, 2014 at 3:43 PM, Warren Togami Jr. wtog...@gmail.comwrote: The Bitcoin Core developers have a desire to do a mostly bug-fix, cleanup and translation update release in v0.9.2 a few weeks from now. You do not need to be a developer to help! With these unofficial nightly builds, power users can more easily aid in testing of the master branch which will help to find bugs and polish things up faster. Additionally translators can more easily run the latest code and see what strings need to be translated as we rapidly approach the next stable release. https://bitcointalk.org/index.php?topic=571414.0 Read more details here. Warren Togami -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Regtest Address Version Change Proposal
Hi folks, I propose changing all of the address versions in -regtest mode to be unique so they are no longer identical to testnet. https://en.bitcoin.it/wiki/List_of_address_prefixes For example, regtest pubkey hash addresses could begin with r or R. We need to know if any existing tools would need to be modified to support this change to regtest. Do existing tools outside of pull tester expect regtest to have testnet addresses? If the quantity of tools that currently handle regtest is small then we can modify them to the new address versions. Warren Togami -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Regtest Address Version Change Proposal
bitcore guesses the network from the address version in several places in its code. They don't want to change that. Perhaps it wasn't the wisest approach for them to use. I thought it might be simple to change the address version since its still relatively new and it isn't a real network. Would it be too much work to change? On Tue, May 13, 2014 at 12:30 AM, Mike Hearn m...@plan99.net wrote: Yes, bitcoinj supports and uses regtest mode. It would also have to be changed. You didn't provide a rationale for this. What's the cost of having them be the same? On Tue, May 13, 2014 at 11:45 AM, Warren Togami Jr. wtog...@gmail.comwrote: Hi folks, I propose changing all of the address versions in -regtest mode to be unique so they are no longer identical to testnet. https://en.bitcoin.it/wiki/List_of_address_prefixes For example, regtest pubkey hash addresses could begin with r or R. We need to know if any existing tools would need to be modified to support this change to regtest. Do existing tools outside of pull tester expect regtest to have testnet addresses? If the quantity of tools that currently handle regtest is small then we can modify them to the new address versions. Warren Togami -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 0.9.2 RC postponed for 7 days
The release candidate for 0.9.2 was previously scheduled for May 13th. Yesterday it was decided to postpone this for 7 days due to the Bitcoin 2014 Amsterdam conference. The string freeze is now in effect and it is a very good time to contribute translationshttps://bitcointalk.org/index.php?topic=582345.0during these next 7 days. In Related News ... http://nightly.bitcoin.it now has separate builds for the master and 0.9.2 branch. 0.9.2 is what will soon become the release while master is accepting changes that may not be safe for a near-term release. Read details https://bitcointalk.org/index.php?topic=571414 about deterministic reproducibility of the unofficial nightly builds. Warren Togami -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Translators Needed for Bitcoin Core
https://www.transifex.com/projects/p/bitcoin/ This is a reminder that many languages still require translation coverage. See this page to see the percentage of strings translated into a given language. The 0.9.2 release candidate is currently scheduled for May 13th with translations accepted for the release for at least a week after that. Even if you do not speak other languages, you can help by pointing other people who do at this page. Warren On Wed, Apr 23, 2014 at 7:47 PM, Warren Togami Jr. wtog...@gmail.comwrote: You do not need to be a developer to help in the improvement of Bitcoin. http://sourceforge.net/p/bitcoin/mailman/message/32255092/ Bitcoin Core 0.9.2 feature freeze is May 13th, 2014. Now is the time for native non-English speakers to join Transifex to clean up the translations in all languages. This is important for more than just Bitcoin because Litecoin will use these same translations. *What should volunteer translators do?* https://bitcointalk.org/index.php?topic=571414 Try the nightly builds of Bitcoin Core as it heads toward 0.9.2. Not recommended for your production wallet. https://www.transifex.com/projects/p/bitcoin/ Join Transifex as a translator and add your account to your language. https://groups.google.com/forum/#!forum/bitcoin-translators Join the Translator mailing list to receive announcements when translations are needed for Bitcoin. You will also receive notifications if other Bitcoin Project things in Transifex need translations (likely bitcoin.org). -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2
On Wed, Apr 23, 2014 at 10:02 PM, Wladimir laa...@gmail.com wrote: On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. wtog...@gmail.com wrote: If you are a rare user who needs Bitcoin-Qt on an incompatible system you can at least build it from source. Tails users usually can't really build it from source— talks is a live boot mostly stateless linux distribution for privacy applications. It's really good in general. Aside: But is Bitcoin Core a well-suited application for those uses? I cannot imagine someone running a full node on a stateless system. Anyhow: As this is only one symbol, we can probably get rid of it (as we didn't use it in 0.8.6?), or put it behind some #ifdef COMPATIBILITY_BUILD... Another option: Instead of statically building it'd be easy enough to build against the 4.6 Qt headers instead without even swapping the library. Qt is, after all, forward-compatible - between the 4.x versions. This will lose some GUI features but if compatibility is more important here that's a choice that can be made. Wladimir I now see how it worked with Bitcoin 0.8.6. Lucid has qt-4.6.2. It is more than one symbol. It does not seem to be a wise thing to replace functions beyond the trivial in glibc and libstdc++. I personally think we need to decide upon a cut-off point beyond which it makes no sense to add the risk of increased complexity. RHEL6 had qt-4.6.2 as well and I don't think I've heard a single complaint about bitcoin-qt being broken there given almost nobody uses it as a desktop. Warren -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2
On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas kristovat...@gmail.comwrote: I see that the latest nightly build (thanks for that, Warren) is still not compatible with Tails/Debian Squeeze. Is there still an intention to address this issue? Might it be fixed by 0.9.2? If I understand the situation, bitcoind does work but not bitcoin-qt due to qt-4.6? If that is so, then the official Bitcoin 0.8.6 binaries didn't work on Squeeze either this is not a regression. The priority is for bitcoind to work on as many distributions as reasonably possible as older stable distributions are most often headless. If you are a rare user who needs Bitcoin-Qt on an incompatible system you can at least build it from source. Warren -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Core Nightly Builds
The Bitcoin Core developers have a desire to do a mostly bug-fix, cleanup and translation update release in v0.9.2 a few weeks from now. You do not need to be a developer to help! With these unofficial nightly builds, power users can more easily aid in testing of the master branch which will help to find bugs and polish things up faster. Additionally translators can more easily run the latest code and see what strings need to be translated as we rapidly approach the next stable release. https://bitcointalk.org/index.php?topic=571414.0 Read more details here. Warren Togami -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
On Thu, Feb 27, 2014 at 7:25 PM, Troy Benjegerdes ho...@hozed.org wrote: Either the transaction fees are sufficient to pay the cost for whatever random junk anyone wants to put there, or they are not, and if they are not, then I suggest you re-think the fee structure rather than trying to pre-regulate me putting 80 character pithy quotes in the blockhain. https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d In one way in particular, the transaction fees per kilobyte completely failed to account for the actual cost to the network. If Bitcoin had adopted a common-sense rule like this, I would have had no reason to join Litecoin development last year. This is one of the few economic design flaws that Satoshi overlooked in the original design. As much as I personally hate the idea of data storage in the blockchain, this at least discourages the creation of permanent UTXO. Warren Togami -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
Just a small note of caution for those joining in testing. https://github.com/bitcoin/bitcoin/issues/3529 Currently the master branch has this issue where leveldb renames all of .sst files to .ldb. This makes running the 0.8.x version of Bitcoin think the index is corrupt. Until a fix is included in Bitcoin master, a workaround to allow 0.8.x to work again is to simply rename all the files from .ldb back to .sst. (This workaround worked for me today but failed yesterday. It's possible I made an error yesterday. If it fails for you please report as we really need to know if there are other leveldb incompatibilities.) https://github.com/bitcoin/leveldb/pull/3 The fix for Bitcoin's leveldb is being discussed here. Warren On Wed, Jan 15, 2014 at 11:09 PM, Wladimir laa...@gmail.com wrote: Hello all, It has been way to long since last major release. Many improvements and new features have been added to master since, so we'd like to do a 0.9rc1 release soon. The current aim is next month, February 2014. Of course there are still some open issues that need to be resolved before release https://github.com/bitcoin/bitcoin/issues?milestone=12state=open If there is something else that you're working on and needs to end up in 0.9, or know of some nasty bug in master that should absolutely be solved first, please tell. Wladimir -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Peer Discovery and Overlay
I was concerned about this issue so we sponsored BlueMatt to implement an address database for bitcoinj. In the future it won't be entirely reliant on what DNS tells it. Warren On Tue, Dec 24, 2013 at 6:02 AM, Peter Todd p...@petertodd.org wrote: As for node addresses being a service, that's what the DNS seeds are! bitcoinj clients, for instance, depend very heavily on those seeds and can be easily compromised in a variety of ways by them. -- 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
Re: [Bitcoin-development] 0.8.6 release candidate 1
Our testing of the macos leveldb parts for the past 6 days has had zero complaints of new corruption from OMG and LTC users. I agree it is time to release 0.8.6. On Sun, Dec 8, 2013 at 8:14 PM, Gavin Andresen gavinandre...@gmail.comwrote: On Mon, Dec 9, 2013 at 9:07 AM, Warren Togami Jr. wtog...@gmail.comwrote: I found a tiny error in 0.8.6rc1. The leveldb subtree merge was done incorrectly leaving an errant db/ directory in the base of bitcoin instead of src/leveldb. I see: db/autocompact_test.cc ... which I assume is a leveldb unit test file that should be in src/leveldb/db/ Not a showstopper bug. Given we've had hundreds of downloads and no reports of insanity, I think we should tag v0.8.6 today (same commit as v0.8.6rc1) and ship it. -- -- Gavin Andresen -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Coin Control, Send crash on MacOS X
https://github.com/litecoin-project/bitcoinomg/commits/0.8.5-OMG6 http://download1.rpmfusion.org/~warren/bitcoin-0.8.5-OMG6/ I've been backporting patches from master and Litecoin to make a Bitcoin 0.8 client with more features. It works quite well on Linux and Win32. http://pastebin.com/g8QqheGc Today we discovered a rare crash that can happen on MacOS X. toffoo and coblee reproduced it on MacOS X 10.9 and I reproduced it on 10.6.8. It seems to be some kind of race condition involving SendCoinsEntry::clear(). 1. 11 QtGui 0x00e28141 QWidget::setFocus(Qt::FocusReason) + 289 2. 12 org.bitcoinfoundation.Bitcoin-Qt0x002ca665 SendCoinsEntry::clear() + 101 This build was made with Xcode 3.2.6 on MacOS X with MacPorts qt4-mac qt-4.8.4, roughly meant to approximate Gavin's build environment for the 0.8.x releases. With this unfamiliar build environment I have been unsuccessful at building master so I am unable to confirm if this crash exists there. I am trying qt-4.8.5 next ... but even if I manage to build it, it is exceedingly difficult to reproduce... Warren -- 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=84349351iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bounty: MacOS X Bitcoin Corruption Issue
https://bitcointalk.org/index.php?topic=337294 Since 0.8.x many MacOS X users have been experiencing periodic leveldb data corruption issues. While not fatal, it is very time consuming to recover from this corruption and upsetting that it happens often for some users. There have been three commits in Bitcoin that attempted to fix this, one fsync fix in leveldb, one in util.h, and a leveldb version upgrade to 1.13. My guess is that one of these commits fixed other corruption, but there remains at least one mysterious corruption issue on Mac where leveldb is corrupted after a clean shutdown of Bitcoin-Qt. After 5+ months we still do not know why some users never see corruption while it happens often for others. Gavin has pledged 5 BTC, and Litecoin Dev pledges 200 LTC to start this bounty. This thread has public addresses for Mac users to donate to increase the incentive to fix this issue sooner. To help please contribute detailed bug reports or links to more relevant background information pertaining to this corruption issue. https://bitcointalk.org/index.php?topic=320695.0 For testing purposes, please use either Bitcoin git master or Bitcoin 0.8.5 OMG3, both of which contain all of the relevant leveldb fixes. Testing without those fixes will not be helpful at this point. Warren -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoind stops responding
https://github.com/litecoin-project/litecoin/issues/67 0.8.2 apparently was the first Bitcoin version to support RPC keepalive. With the 4 RPC thread limit, four keepalive connections will exhaust all four and prevent further connections. This issue describes a workaround where you build with more RPC threads. On Mon, Sep 30, 2013 at 10:44 AM, slush sl...@centrum.cz wrote: Hi, during several weeks I'm observing more and more frequent issues with bitcoind. The problem is that bitcoind stops responding to RPC calls, but there's no other suspicious activity in bitcoind log, CPU usage is low, disk I/O is standard etc. I observed this problem with version 0.8.2, but it is still happening with 0.8.5. Originally this happen just one or twice per day. Today my monitoring scripts restarted bitcoind more than 30x, which sounds alarming. This happen on various backends, so it isn't a problem of one specific node. Is there anybody else who's observing similar problem? Thanks, slush -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned people that getwork will be removed in the next major version. Pooler's CPU minerd which supports both sha256d and scrypt recently grew stratum support. Perhaps he could be convinced to add GBT support too, which would help this goal of completely removing the internal miner and getwork. Warren On Mon, Aug 19, 2013 at 10:23 AM, Gregory Maxwell gmaxw...@gmail.comwrote: On Mon, Aug 19, 2013 at 1:16 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I think removing the ability to mine in the stock package would be regrettable, I am naughty and should clarify. I had ass.u.me.d that Jeff's patch also removed the internal CPU miner, because doing so is necessary for actually getting rid of most of the getwork code. It doesn't actually. Though this doesn't change the fact that the internal miner is mostly a pretext for integrated mining. Since it only really works on testnet it also means our testnet testing using it is not a good test of the actual production software. I'd rather remove the internal miner too, getting rid of the extra code and complexity, and package up a GBT miner which would actually be usable on the mainnet. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt *Anti-DoS Low Hanging Fruit: source IP or subnet connection limits* If you disallow the same IP and/or subnet from establishing too many TCP connections with your node, it becomes more expensive for attackers to use a single host exhaust a target node's resources. This iptables firewall based example has almost zero drawbacks, but it is too complicated for most people to deploy. Yes, there is a small chance that you will block legitimate connections, but there are plenty of other nodes for random connections to choose from. Configurable per source IP and source subnet limits with sane defaults enforced by bitcoind itself would be a big improvement over the current situation where one host address can consume limited resources of many target nodes. This doesn't remove the risk of a network-wide connection exhaustion attack by a determined attacker, but it at least makes multiple types of attacks a lot more expensive. This also doesn't do much against the io vulnerability, which would require major redesigns to prevent in Bitcoin. https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d *Want to safely delay the block size limit increase for another year or two? * This patch alone enables that. On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn m...@plan99.net wrote: The only other thing I'd like to see there is the start of a new anti-DoS framework. I think once the outline is in place other people will be able to fill it in appropriately. But the current framework has to be left behind. If I had to choose one thing to evict to make time for that, it'd be the whitepapers. At the moment we still have plenty of headroom in block sizes, even post April. It can probably be safely delayed for a while. On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn m...@plan99.net wrote: Cool. Maybe it's time for another development update on the foundation blog? On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen gavinandre...@gmail.comwrote: Mike asked what non-0.9 code I'm working on; the three things on the top of my list are: 1) Smarter fee handling on the client side, instead of hard-coded fees. I was busy today generating scatter-plots and histograms of transaction fees versus priorities to get some insight into what miner policies look like right now. 2) First double-spend relaying and alerting, to better support low-value in-person transactions. Related: *Have *a *Snack*, Pay with *Bitcoins*http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB block size limit, how we can do it safely, and go through all of the arguments that have been made against it and explain why they're wrong. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
A sane default that better protects users could be... If (plugged into power) (wifi) then non-bloom peers are OK. It would protect those users more than reliance upon on the smaller subset of bloom nodes. Scale back to the less secure behavior when battery and bandwidth matters. Warren On Fri, Aug 16, 2013 at 4:36 AM, Mike Hearn m...@plan99.net wrote: That change was made in response to user complaints. Heck we get complaints about battery life and bandwidth impact even with Bloom filtering. We can't just randomly start using peoples bandwidth for relaying blocks, especially as I guess most SPV nodes are behind NAT. If Gavin is right and the future is dominated by mobiles and tablets, then it will require a change of thinking in how P2P networks work. I think there are plenty of people with private servers who would be willing to run nodes though. I'm not too worried about this. On Fri, Aug 16, 2013 at 4:27 PM, Warren Togami Jr. wtog...@gmail.comwrote: bitcoinj-0.10 release notes: - We now require Bloom-capable (0.8+) peers by default and will disconnect from older nodes. This avoids accidental bandwidth saturation on mobile devices. Given the user-security concern that Peter brings up, reconsideration of this new default behavior in SPV clients may be warranted. On Fri, Aug 16, 2013 at 4:15 AM, Peter Todd p...@petertodd.org wrote: On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote: Doing this also makes it more difficult to sybil the network - for instance right now you can create SPV honeypots that allow incoming connections only from SPV nodes, thus attracting a disproportionate % of the total SPV population given a relatively small number of nodes. You can then use that to harm SPV nodes by, for instance, making a % of transactions be dropped deterministicly, either by the bloom matching code, or when sent. Users unlucky enough to be surrounded by sybil nodes will have their transactions mysteriously fail to arrive in their wallets, or have their transactions mysteriously never confirm. Given how few full nodes there are, it probably won't take very many honeypots to pull off this attack, especially if you combine it with a simultaneous max connections or bloom io attack to degrade the capacity of honest nodes. Oh, here's an even better way to do the tx drop attack: when you drop a transaction, make a fake one that pays the same scriptPubKeys with the same amount, and send it to the SPV peer instead. They'll see the transaction go through and show up in their wallet, but it'll look like it got stuck and never confirmed. They'll soon wind up with a wallet full of useless transactions, effectively locking them out of their money. Here's another question for you Mike: So does bitcoinj have any protections against peers flooding you with useless garbage? It'd be easy to rack up a user's data bill for instance by just creating junk unconfirmed transactions matching the bloom filter. -- 'peter'[:-1]@petertodd.org 0018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55 -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
