Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This kind of thing always happens as projects become larger and more diverse. Something that was once a small group turns into a big group of diverse stakeholders. When it gets too big for the informal processes then some people get upset and defensive. Happens all the time but it is not really a good excuse to keep doing things in an inefficient manner. The old ways just don't scale and if you ever worked on massive projects then you know these formal processes work better. So then: make a proposal for a better process, post it to this list. In practice there has been zero interest in improving the BIP process. E.g. the BIP process was adapted from the Python Enhancement Proposals by Amir Taaki (in 2009 or so?). It hasn't really changed since then, apart from some spelling and grammar corrections. It is not specifically adapted to Bitcoin, and doesn't make a distinction between for example, consensus changes and non-consensus changes. So that's up to someone to do. You seem to be enthousiastic about it, so go ahead. Wladimir -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVgufFAAoJEHSBCwEjRsmmAmYIAI9ndrMoqEuoaP5t+7W42UuH sh5qR7hojCCoZZl1N+rQ63UXcPBO/V4NUkUG97S3qpEFDzuoYSbOX2Eh+TRfK+s+ U+BpLhWteSexJ3N9aiFuR0q5jgesAzLZ9wtq1gCPI/Zu5/fgYBP4AVTiQGdXCZtv m6ZDKCf+aB/fW/59/AiY44NkMDjVQieEVRiT1IPFJULWesOOdtv7UoqIpz0vDa/5 Jplm41j8IpTPioJKSwUi5qzSDrF7O39PC9LMXNRx/0FIuYfwqJpvF0Frc+vtPpjQ llKE7945uMXz3FLSV0Orx26XPal/MuF5AYOPNk6pJfwYw7q91AUvQxVFepBa9vw= =dMO9 -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 06:05:58PM +0200, Mike Hearn wrote: Once a draft BIP has been submitted to bitcoin-development for consideration, the Bitcoin Core maintainer will deliver a preliminary yes/no verdict within three weeks. This verdict may be informed by the debate that has taken part in the previous three weeks. If more time is required, the maintainer is required to request an extension from the BIP author, who may then elect to force an immediate decision (risking a no), or choosing to allow more time. Again, for the last time: Bitcoin Core maintainer does not decide about protocol or consensus level changes. This is not a role for me. Find someone else, if you think you need an arbiter. There was an idea about a Bitcoin Standards Body once, but as far as I know that's not actively being worked on. BTW: for more exposure a proposal is better posted as a new thread, not as a deep reply to an existing topic. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?
On Wed, Jun 10, 2015 at 09:36:23PM +0300, s7r wrote: The mail list is public, so it's not like the data on it is somehow sensitive. Sourcefoge is fine, it has a nice web UI where you can browse the message and sort/order them as you want, etc. Why would you want to move to a paid solution? And why would you want users to have to pay per message? This is the worst idea ever from my point of view. We want to encourage people to join the community, run full nodes, ask questions, come with solutions, ideas for improvements and so on. Everyone should read and write and contribute as much as possible with ideas in debates. You never know who can have bright ideas in some contexts. Bottom line is so far sourceforge handles the mail lists just fine. I don't see a single advantage another mail list provider / system could offer, except some headache and extra work for migration. The software distribution via sourcefoge was cancelled for obvious reasons which I fully understand and agree to, but it has nothing to do with the mail lists. We have way more important things to brainstorm about. I completely agree here. I'm not against migration if a much better option comes along, but e.g. paying for another provider sounds like nonsense when sourceforge does this for free (with some minor annoyances - other providers will have their own). Paying per message is far-fetched, something that could work in economic theory with perfectly spherical people in their perfectly efficient market. In practice the likely result would be a mailing list only used for advertisement and promotion, and technical discussion and release announcements would disappear. BTW for people that *don't* like sourceforge's web archive UI there are some other options via gmane: http://dir.gmane.org/gmane.comp.bitcoin.devel Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?
On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote: http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/ All our downloads (even old ones) have recently been deleted from sourceforge, for this reason. They haven't been mentioned in Bitcon Core release announcements for a long time. No opinion on the mailing list. Though I think it's less urgent. The issue of moving the mailinglist has come up before a few times and people can't agree where to move to. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote: Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... But in that case (unconstrained) randomization can't be used either. This is posed as an alternative to randomization. So in that regard, the proposal still makes sense. I think this move to verifyable, deterministic methods where possible is good. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin core 0.11.0 release candidate 1 available
Hello, I've just uploaded Bitcoin Core 0.11.0rc1 executables to: https://bitcoin.org/bin/bitcoin-core-0.11.0/test/ The source code can be found in the source tarball or in git under the tag 'v0.11.0rc1' Preliminary release notes can be found here: https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md Thanks to everyone that participated in development or in the gitian build process, Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Core 0.9.5 released
Bitcoin Core version 0.9.5 is now available from: https://bitcoin.org/bin/0.9.5/ This is a new minor version release, with the goal of backporting BIP66. There are also a few bug fixes and updated translations. Upgrading to this release is recommended. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues How to Upgrade === If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). Notable changes Mining and relay policy enhancements Bitcoin Core's block templates are now for version 3 blocks only, and any mining software relying on its `getblocktemplate` must be updated in parallel to use libblkmaker either version 0.4.2 or any version from 0.5.1 onward. If you are solo mining, this will affect you the moment you upgrade Bitcoin Core, which must be done prior to BIP66 achieving its 951/1001 status. If you are mining with the stratum mining protocol: this does not affect you. If you are mining with the getblocktemplate protocol to a pool: this will affect you at the pool operator's discretion, which must be no later than BIP66 achieving its 951/1001 status. 0.9.5 changelog - `74f29c2` Check pindexBestForkBase for null - `9cd1dd9` Fix priority calculation in CreateTransaction - `6b4163b` Sanitize command strings before logging them. - `3230b32` Raise version of created blocks, and enforce DERSIG in mempool - `989d499` Backport of some of BIP66's tests - `ab03660` Implement BIP 66 validation rules and switchover logic - `8438074` build: fix dynamic boost check when --with-boost= is used Credits Thanks to who contributed to this release, at least: - 21E14 - Alex Morcos - Cory Fields - Gregory Maxwell - Pieter Wuille - Wladimir J. van der Laan As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). -- 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] Bitcoin Core 0.9.5 release candidate 1 tagged
Hello, I've just tagged release candidate 1 for 0.9.5 (tag `v0.9.5rc1`). The reason for this backport release is to make BIP66 available on the 0.9 branch. This has been requested by a few users, mostly miners. Full (preliminary) release notes can be found at: https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-notes.md In contrast to 0.10.x releases it is unclear whether there will be enough gitian signatures for a binary release, any help with building is welcome. See https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-process.md (many steps have changed since then, so the release process for 0.10 or master will not work) Wladimir -- 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] Bitcoin Core 0.10.2 released
-- 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] Bitcoin Core 0.10.2 released
Bitcoin Core version 0.10.2 is now available from: https://bitcoin.org/bin/bitcoin-core-0.10.2/ The distribution is also available as torrent: https://bitcoin.org/bin/bitcoin-core-0.10.2/bitcoin-0.10.2.torrent magnet:?xt=urn:btih:746a616aa8de97856c207e7a899c7ee315e8c44ddn=bitcoin-core-0.10.2tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969tr=udp%3A%2F%2Fopen.demonii.com%3A1337ws=https%3A%2F%2Fbitcoin.org%2Fbin%2 The source code can be found in git under the tag `v0.10.2`, or in `bitcoin-0.10.2.tar.gz` in the distribution. This is a new minor version release, bringing minor bug fixes and translation updates. It is only necessary to upgrade to this version when unable to start the application on Windows with 0.10.1. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues Upgrading and downgrading = How to Upgrade -- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). Downgrade warning -- Because release 0.10.0 and later makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software: * 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 want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex. This does not affect wallet forward or backward compatibility. Notable changes === This fixes a serious problem on Windows with data directories that have non-ASCII characters (https://github.com/bitcoin/bitcoin/issues/6078). For other platforms there are no notable changes. For the notable changes in 0.10, refer to the release notes at https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md 0.10.2 Change log = Detailed release notes follow. This overview includes changes that affect external behavior, not code moves, refactors or string updates. Wallet: - `824c011` fix boost::get usage with boost 1.58 Miscellaneous: - `da65606` Avoid crash on start in TestBlockValidity with gen=1. - `424ae66` don't imbue boost::filesystem::path with locale C on windows (fixes #6078) Credits === Thanks to everyone who directly contributed to this release: - Cory Fields - Gregory Maxwell - Jonas Schnelli - Wladimir J. van der Laan And all those who contributed additional code review and/or security research: - dexX7 - Pieter Wuille - vayvanne As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). On Tue, May 19, 2015 at 1:44 PM, Wladimir J. van der Laan laa...@gmail.com wrote: -- 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] Bitcoin Core 0.10.2 release candidate 1 available
The subject should obviously be Bitcoin Core 0.10.2 release candidate 1 available, not the other way around, -- 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] Bitcoin Core 0.10.1 release candidate 2 available
Binaries for bitcoin Core version 0.10.2rc1 are now available from: https://bitcoin.org/bin/0.10.2/test Source code can be found on github under the signed tag https://github.com/bitcoin/bitcoin/tree/v0.10.2rc1 This is a release candidate for a minor version release, with mainly a fix for a bug that affected Windows users with non-ASCII characters in the data directory. The release also contains translation updates. If you experienced no issues with 0.10.1, there is no need to upgrade. Preliminary release notes for the 0.10.2 release can be found here: https://github.com/bitcoin/bitcoin/blob/v0.10.2rc1/doc/release-notes.md Release candidates are test runs for releases, when no critical problems are found this release candidate will be tagged as 0.10.2. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues -- 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] Bitcoin core 0.11 planning
A reminder - feature freeze and string freeze is coming up this Friday the 15th. Let me know if your pull request is ready to be merged before then, Wladimir On Tue, Apr 28, 2015 at 7:44 AM, Wladimir J. van der Laan laa...@gmail.com wrote: Hello all, The release window for 0.11 is nearing, I'd propose the following schedule: 2015-05-01 Soft translation string freeze Open Transifex translations for 0.11 Finalize and close translation for 0.9 2015-05-15 Feature freeze, string freeze 2015-06-01 Split off 0.11 branch Tag and release 0.11.0rc1 Start merging for 0.12 on master branch 2015-07-01 Release 0.11.0 final (aim) In contrast to former releases, which were protracted for months, let's try to be more strict about the dates. Of course it is always possible for last-minute critical issues to interfere with the planning. The release will not be held up for features, though, and anything that will not make it to 0.11 will be postponed to next release scheduled for end of the year. Wladimir -- 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] Fwd: Bitcoin core 0.11 planning
On Tue, Apr 28, 2015 at 11:01 AM, Pieter Wuille pieter.wui...@gmail.com wrote: As softforks almost certainly require backports to older releases and other software anyway, I don't think they should necessarily be bound to Bitcoin Core major releases. If they don't require large code changes, we can easily do them in minor releases too. Agree here - there is no need to time consensus changes with a major release, as they need to be ported back to older releases anyhow. (I don't really classify them as software features, but properties of the underlying system that we need to adopt to) Wladimir -- 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
is guided by not only fee pressure, but also other reasons such as speed of confirmation, which is unreliable on-chain. This eases objection 3b. Whew, this grew longer than I expected. To conclude, I understand the advantages of scaling, I do not doubt a block size increase will *work* Although there may be unforseen issues, I'm confident they'll be resolved. However, it may well make Bitcoin less useful for what sets it apart from other systems in the first place: the possibility for people to run their own own bank without special investment in connectivity and computing hardware. Also the politics aspect (at some point it becomes a question of who decides for who? who is excluded? all those human decisions...) of this I don't like in the least. Possibly unavoidable at some point, but that's something *I*'d like to kick down the road. Wladimir -- 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] Bitcoin core 0.11 planning
Hello all, The release window for 0.11 is nearing, I'd propose the following schedule: 2015-05-01 Soft translation string freeze Open Transifex translations for 0.11 Finalize and close translation for 0.9 2015-05-15 Feature freeze, string freeze 2015-06-01 Split off 0.11 branch Tag and release 0.11.0rc1 Start merging for 0.12 on master branch 2015-07-01 Release 0.11.0 final (aim) In contrast to former releases, which were protracted for months, let's try to be more strict about the dates. Of course it is always possible for last-minute critical issues to interfere with the planning. The release will not be held up for features, though, and anything that will not make it to 0.11 will be postponed to next release scheduled for end of the year. Wladimir -- 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] Bitcoin Core 0.10.1 released
` Initialization: set fallback locale as environment variable Credits === Thanks to everyone who directly contributed to this release: - Alex Morcos - Cory Fields - dexX7 - fsb4000 - Gavin Andresen - Gregory Maxwell - Ivan Pustogarov - Jonas Schnelli - Matt Corallo - mrbandrews - Pieter Wuille - Ruben de Vries - Suhas Daftuar - Wladimir J. van der Laan And all those who contributed additional code review and/or security research: - 21E14 - Alison Kendler - Aviv Zohar - Ethan Heilman - Evil-Knievel - fanquake - Jeff Garzik - Jonas Nick - Luke Dashjr - Patrick Strateman - Philip Kaufmann - Sergio Demian Lerner - Sharon Goldberg As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). -- 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] Bitcoin Core 0.10.1 release candidate 3 available
I've just uploaded Bitcoin Core 0.10.1rc3 executables to: https://bitcoin.org/bin/bitcoin-core-0.10.1/test/ The source code can be found in git under the tag 'v0.10.1rc3' on the `0.10` branch. New in this RC is another batch of bug fixes, - `eae305f` Fix missing lock in submitblock - `57d1f46` Fix CheckBlockIndex for reindex - `bac6fca` Set nSequenceId when a block is fully linked - `139cd81` Cap nAttempts penalty at 8 and switch to pow instead of a division loop - `323de27` `7494e09` `df45564` Various initialization setup environment locale fixes Full (preliminary) release notes for 0.10.1 can be found at https://github.com/bitcoin/bitcoin/blob/v0.10.1rc3/doc/release-notes.md Thanks to everyone that participated in development or in the gitian build process. I sincerely hope that this can be the final release candidate for 0.10.1, Wladimir -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Core 0.10.1 release candidate 1 available
Binaries for bitcoin Core version 0.10.1rc1 are now available from: https://bitcoin.org/bin/0.10.1/test Source code can be found in github under the tag https://github.com/bitcoin/bitcoin/tree/v0.10.1rc1 This is a release candidate for a minor version release, bringing bug fixes and translation updates. Release candidates are test runs for releases, when no critical problems are found the release candidate will be tagged as 0.10.1. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues Upgrading and downgrading = How to Upgrade -- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). Downgrade warning -- Because release 0.10.0 and later makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software: * 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 want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex. This does not affect wallet forward or backward compatibility. Notable changes === This is a minor release and hence there are no notable changes. For the notable changes in 0.10 refer to the release notes for the 0.10.0 release at https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md 0.10.1 Change log = Detailed release notes follow. This overview includes changes that affect external behavior, not code moves, refactors or string updates. RPC: - `7f502be` fix crash: createmultisig and addmultisigaddress Block (database) and transaction handling: - `1d2cdd2` Fix InvalidateBlock to add chainActive.Tip to setBlockIndexCandidates - `c91c660` fix InvalidateBlock to repopulate setBlockIndexCandidates - `002c8a2` fix possible block db breakage during re-index - `a1f425b` Add (optional) consistency check for the block chain data structures P2P protocol and network code: - `78f64ef` don't trickle for whitelisted nodes - `ca301bf` Reduce fingerprinting through timestamps in 'addr' messages. - `200f293` Ignore getaddr messages on Outbound connections. - `d5d8998` Limit message sizes before transfer - `aeb9279` Better fingerprinting protection for non-main-chain getdatas. - `cf0218f` Make addrman's bucket placement deterministic (countermeasure 1 against eclipse attacks, see http://cs-people.bu.edu/heilman/eclipse/) - `0c6f334` Always use a 50% chance to choose between tried and new entries (countermeasure 2 against eclipse attacks) - `214154e` Do not bias outgoing connections towards fresh addresses (countermeasure 2 against eclipse attacks) - `aa587d4` Scale up addrman (countermeasure 6 against eclipse attacks) Validation: - `d148f62` Acquire CCheckQueue's lock to avoid race condition Build system: - `8752b5c` 0.10 fix for crashes on OSX 10.6 Wallet: - N/A GUI: - `2c08406` some mac specifiy cleanup (memory handling, unnecessary code) - `81145a6` fix OSX dock icon window reopening - `786cf72` fix a issue where command line options-action overwrite Preference-action (on OSX) Tests: - `1117378` add RPC test for InvalidateBlock Miscellaneous: - `c9e022b` Initialization: set Boost path locale in main thread - `23126a0` Sanitize command strings before logging them. Credits === Thanks to everyone who contributed to this release: - Alex Morcos - Cory Fields - dexX7 - fsb4000 - Gregory Maxwell - Ivan Pustogarov - Jonas Schnelli - Pieter Wuille - Ruben de Vries - Suhas Daftuar - Wladimir J. van der Laan As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). -- 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
Re: [Bitcoin-development] bloom filtering, privacy
Hello Adam, On Fri, 20 Feb 2015, Adam Back wrote: So I was wondering what about changing to committing a bloom filter of the addresses in the block. Its seems surprising no one thought of it that way before (as it seems obvious when you hear it) but that seems to address the privacy issues as the user can fetch the block bloom filters and then scan it in complete privacy. (Someone appeared on bitcoin wizards IRC a while back and made this observation.) I have heard this idea of inverting the bloom filter before (possibly in #bitcoin-wizards), and as I see it it would indeed improve the privacy. Apart from privacy it would also lower the burden for nodes. A block scan with bloom filter is effectively a cheap DoS on a node. In addition to that it will also avoid the 'transaction withholding attack' that is possible with the current bloom filtering, at least if the filter is e.g. committed to in the block header. The drawback would be overhead - the bloom filter per block will have a significant size (to avoid false positives), and the client would have to fetch entire blocks that have its transactions in it. I don't think that is so bad in practice, after all the % of blocks that will have transactions for a given wallet will generally be low, so the block size is amortized in a way. Of course, if the block size would be increased this would become worse. Wladimir -- 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
[Bitcoin-development] Bitcoin Core 0.10.0 final was tagged
Hello, I've just tagged 0.10.0rc4 as final (with a small packaging change to avoid tar nastiness). The tag is 'v0.10.0'. Start your gitian builders! For a guide on how to do gitian builds see https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md Please wait with a release announcement until there are 3 builders and the binaries have been uploaded. Cheers, Wladimir -- 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] Bitcoin Core 0.10.0rc4 tagged
On Thu, Feb 5, 2015 at 12:33 PM, Wladimir laa...@gmail.com wrote: FYI, I've just tagged v0.10rc4, and pushed my signatures to the gitian.sigs repository. Please start your gitian builders! Thanks to the extremely quick response (a whopping 9 gitian builders already!), the executables and tarball for rc4 have been uploaded to the usual place: https://bitcoin.org/bin/0.10.0/test/ Wladimir -- 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] determining change addresses using the least significant digits
On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner cryptocurrenc...@quidecco.de wrote: A possible approach to handle this issue would be to add a randomized offset amount to the payment amount. This offset amount can be small in comparison to the payment amount. Any thoughts? Adding/subtracting a randomized offset amount is one way, but there have also been more sophisticated ideas to obfuscate the amount, e.g. by adding multiple change outputs or even distributing over multiple transactions (potentially coinjoined for further privacy). Mike Hearn had some ideas regarding obfuscation of payment amounts, which still make sense, and he wrote about them here: https://medium.com/@octskyward/merge-avoidance-7f95a386692f Wladimir -- 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] Bitcoin Core 0.10.0rc4 tagged
FYI, I've just tagged v0.10rc4, and pushed my signatures to the gitian.sigs repository. Please start your gitian builders! Changes relative to rc3: - 1eb14af Increase block download timeout base from 10 to 20 minutes. - 3916a81 Increase coverage of DERSIG edge cases - 6da2028 Add RPC test for DERSIG BIP switchover logic - 773c30d BIP66 changeover logic - 18695f0 Example unit tests from BIP66 - abfbeaf Change IsDERSignature to BIP66 implementation - b6347bf Fix priority calculation in CreateTransaction - 2448d34 Avoid storing a reference passed to SignatureChecker constructors - 1bbad80 Use separate SignatureChecker for CMutableTransaction - 6a02ef8 [Qt] don't allow amount changes when AmountSpinBox is read-only - b61940b Change Coin Control first column label - c5044bc sleep-wait on genesis block during init with -reindex - b24ff47 Make empty byte arrays pass CheckSignatureEncoding() - ed4206a fix crash: CoinControl space bug - 58259ad qt: fix broken unicode chars on osx 10.10 - aaf55d2 186a517 Add a -rpckeepalive option to disable RPC use of HTTP persistent connections. Hopefully this will be the last release candidate before the 0.10 final release. Wladimir -- 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] [softfork proposal] Strict DER signatures
One way to do that is to just - right now - add a patch to 0.10 to make those non-standard. This requires another validation flag, with a bunch of switching logic. The much simpler alternative is just adding this to BIP66's DERSIG right now, which is a one-line change that's obviously softforking. Is anyone opposed to doing so at this stage? Not opposed, but is kind of late for 0.10, I had hoped to tag rc4 today. Wladimir -- 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] Export format for xpub
On Mon, 2 Feb 2015, Levin Keller wrote: Hello everyone, I think this is my first email to this mailinglist so I will shortly introduce myself: I am Levin and the CEO of Coyno (www.coyno.com). Based in Berlin, mathematician. Bitcoiner since 2011. And now the reason for this email: Andreas (Schildbach) just released a new update of his wallet. It now provides an export functionality for the m/0' key in order to run read only copies on other devices. We already support the format on our website. Of course we would love for this to become standard. I also updated the Wiki article for Andreas' Wallet: https://en.bitcoin.it/wiki/Bitcoin_Wallet Yes, standardizing on a format could be useful. How do you like it? How does this format get standard? Shall I try to get a pull request to BIP32 passed? Just administrative trivia: this would be a new BIP, and not an amandment to BIP32. Excluding small language errors and clarifications in examples, BIPs are not changed after the fact. Wladimir-- 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] var_int ambiguous serialization consequences
On Sun, 1 Feb 2015, Tamas Blummer wrote: I wonder of consequences if var_int is used in its longer than necessary forms (e.g encoding 1 as 0xfd0100 instead of 0x01) In serialize.h lingo you are talking about CompactSize, not VarInt. CompactSizes indeed have redundancy in their representation, i.e. the same number can be represented as up to four different byte sequences. VARINTs have a different format that (AFAIK) isn't used anywhere in the block chain. See WriteVarInt / ReadVarInt. These were designed to not have any redundancy in their representation. This is already of interest if applying size limit to a block, since transaction count is var_int but is not part of the hashed header or the merkle tree. Are you sure that this is a current concern? Non-canonical CompactSizes are forbidden - in serialize.h this is flagged in ReadCompactSize. Wladimir -- 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] Bitcoin Core 0.9.4 not on bitcoin.org?
On Sun, 1 Feb 2015, xor wrote: Why is that? v0.9.4 is not really a release, just a tag in git. It contains merely a workaround for a change in OpenSSL which caused problems - see Gregory Maxwell's post. As the releases are statically built against OpenSSL, it is not necessary to upgrade if you use releases from bitcoin.org. Hence no change on the site. (but it can be used by people building from source, or distributions packages such as the Ubuntu PPA, which unwisely dynamically link OpenSSL) Also, is it correct that there wasn't a release candidate before the release? Sounds dangerous to me. Again, there hasn't been any 0.9.4 release, neither a release candidate or anything else. Testing and such should be focused on the 0.10 release candidates. Wladimir -- 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] Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today?
On Fri, 30 Jan 2015, Nick Simpson wrote: This has been discussed before. I believe most people don't expect Bitcoin to replace all of the various methods of payment. Scalability is always a concern, just not to the level of Alipay this year (or the next or the next for that matter.) Yes, that about summarizes it. The block chain is a single channel broadcasted over the entire world, and I don't believe it will ever be possible nor desirable to broadcast all the world's transactions over one channel. The everyone-validates-everything approach doesn't scale. It is however useful to settle larger transactions in an irreversible, zero-trust way. That's what makes the bitcoin system, as it is now, valuable. But it is absurd for the whole world to have to validate every purchase of a cup of coffee or a bus ticket by six billion others. Naively scaling up the block size will get some leeway in the short term, but I believe a future scalable payment system based on bitcoin will be mostly based on off-blockchain transactions (in some form) or that there will be a hierarchical or subdivided system (e.g. temporary or per-locale sidechains). Wladimir-- 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] BIP70: why Google Protocol Buffers for encoding?
On Wed, 28 Jan 2015, Nicolas DORIER wrote: I agree that the use protocol buffer and x509 by BIP70 is a poor choice. Well x509 is an international standard in common use, you can't do much better with regard to portability. Your suggestion about HTTPS makes little sense, you do know what TLS uses x509 internally as well? Re: protocol buffers, I don't know if it's the best possible one, but one serialization method had to be picked. If it weren't, we could still have still been discussing which one to use by now. Just like for JSON there are bindings for many languages. Though JSON parsers are much more diverse, which people using Bitcoin Core's RPC have bumped into e.g. some have some problems handling large numbers. Something you wouldn't expect using a straightforward binary format. There's no obvious best choice. Wladimir -- 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] [softfork proposal] Strict DER signatures
On Mon, 26 Jan 2015, Gregory Maxwell wrote: On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille pieter.wui...@gmail.com wrote: On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I therefore propose a softfork to make non-DER signatures illegal (they've been non-standard since v0.8.0). A draft BIP text can be found on: https://gist.github.com/sipa/5d12c343746dad376c80 I'd like to request a BIP number for this. Sure. BIP0066. There was also some feedback on Bitcointalk, which I think you've addressed Progress information for the list: there is now a pull request implementing the strict DER verification behavior, as well as the deployment specified in BIP66 for Bitcoin Core. It needs your review and testing: https://github.com/bitcoin/bitcoin/pull/5713 Wladimir -- 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] [ANN] 0.10.0rc3 has been tagged
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, Jan 12, 2015 at 3:28 PM, Wladimir laa...@gmail.com wrote: On Mon, Jan 12, 2015 at 11:31 AM, Wladimir laa...@gmail.com wrote: If you build from source, and have already built rc2, there is no reason to build rc3. 0.10.0rc3 executables have been uploaded to https://bitcoin.org/bin/0.10.0/test Wladimir -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJUtYo5AAoJEHSBCwEjRsmmGZkH/j51NRB/qJpIFuqz8fQo+ojI 3ZX3Njgcs8mwGcJrOqURJTuLYkj/FVCIsgvIrfCDAkWssxSh320vdktSj6vfBL4T t0IlOHZI+vCXEB6OW+guIF9huae5OHMnuxzxcVye8dJEMrQ76Zm9CmubyOTsvZCn eSDHIqjdu9ygbrPdGXiVQAZ1YVVV2KtHTU+AVGLPkw6EfclefXgVPm3Sp+78LJl7 ZBwgr+NpZQesOh+bIafeJLeEbMfqjOHGzZrh66dTgxhw7Eyd7QpnsRehmRozKGtg g7FPepeDRC1tRElJlzaHn1+V61YHEj6dADCLrZ57gSXPljlnXCWo4YfAF5D6IfQ= =yml9 -END PGP SIGNATURE- -- 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] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.
On Sat, Jan 10, 2015 at 12:18 PM, Ivan Jelincic para...@archlinux.info wrote: Is openssl1.0.1j unaffected? Yes. It concerns CVE-2014-8275. Which in https://www.openssl.org/news/openssl-1.0.1-notes.html is under: Major changes between OpenSSL 1.0.1j and OpenSSL 1.0.1k [8 Jan 2015] Wladimir -- 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. vanity: www.gigenet.com ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [ANN] 0.10.0rc2 has been tagged
I've just tagged 0.10.0rc2 in git. To fetch, build, and test (see also doc/build-*.md): ``` git clone -b v0.10.0rc2 https://github.com/bitcoin/bitcoin.git bitcoin-0.10 cd bitcoin-0.10 ./autogen.sh ./configure make make check ``` Note: This includes the changes required for interoperability with OpenSSL 1.0.1k. Notable changes relative to v0.10.0rc1: - 4e7c219 Catch UTXO set read errors and shutdown - a3a7317 Introduce 10 minute block download timeout - 12b7c44 Improve robustness of DER recoding code - 76ce5c8 fail immediately on an empty signature - 2d375fe depends: bump openssl to 1.0.1k - ace39db consensus: guard against openssl's new strict DER checks - 263b65e tests: run sanity checks in tests too - e2677d7 Fix smartfees test for change to relay policy - b7a4ecc Build: Only check for boost when building code that requires it - 867c600 Catch LevelDB errors during flush - 008138c Bugfix: only track UTXO modification after lookup - 3022e7d Require sufficent priority for relay of free transactions - 06fdf32 bitcoin-tx: Fix JSON validation of prevtxs - 58fda4d Update seed IPs, based on bitcoin.sipa.be crawler data - 94b362d On close of splashscreen interrupt verifyDB - 1eadfd9 Bugfix: prioritisetransaction: Do some basic sanity checking on txid - 18021d0 Remove bitnodes.io from dnsseeds. - b790d13 English translation update - 8543b0d Correct tooltip on address book page - 87d43a3 rpcserver: attempt to fix uncaught exception. - 06ca065 Fix CScriptID(const CScript in) in empty script case Wladmir -- 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. vanity: www.gigenet.com ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.
On Sat, Jan 10, 2015 at 4:26 AM, Gregory Maxwell gmaxw...@gmail.com wrote: https://github.com/bitcoin/bitcoin/commit/488ed32f2ada1d1dd108fc245d025c4d5f252783 (versions of this will be backported to other stable branches soon) For those that build from source, patches to cope with the new OpenSSL versions are now available on stable branches 0.8, 0.9 and rc branch 0.10: 0.8 branch (on top of 0.8.6) https://github.com/bitcoin/bitcoin/tree/0.8 https://github.com/bitcoin/bitcoin/commits/0.8 To fetch, build, and test: ``` git clone -b 0.8 https://github.com/bitcoin/bitcoin.git bitcoin-0.8 cd bitcoin-0.8/src make -f makefile.unix make -f makefile.unix check ``` 0.9 branch (on top of 0.9.3+) https://github.com/bitcoin/bitcoin/tree/0.9 https://github.com/bitcoin/bitcoin/commits/0.9 To fetch, build, and test: ``` git clone -b 0.9 https://github.com/bitcoin/bitcoin.git bitcoin-0.9 cd bitcoin-0.9/src ./autogen.sh ./configure make make check ``` 0.10 branch (on top of 0.10.0rc1+) https://github.com/bitcoin/bitcoin/tree/0.10 https://github.com/bitcoin/bitcoin/commits/0.10 ``` git clone -b 0.10 https://github.com/bitcoin/bitcoin.git bitcoin-0.10 cd bitcoin-0.10/src ./autogen.sh ./configure make make check ``` Wladimir -- 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] Bitcoin 0.10.0c1 available for download
Signed executables are available for 0.10.0 release candidate 1, at https://bitcoin.org/bin/0.10.0/test/ Preliminary release notes for the 0.10 release can be found here: https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues Cheers, Wladimir -- 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 don't care which tabbing style or column width you pick, but **pick one**, and enforce it across the entire codebase. See https://github.com/bitcoin/bitcoin/pull/5387 Wladimir -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged
While it would be nice to have a library encapsulating the consensus code, this shouldn't come at the cost of safety, especially when the actual users of that library or their needs is still uncertain. While I agree that it shouldn't come at unreasonable risk, my whole reason for prioritizing the consensus library is that it is the first step toward the goal of isolating the consensus code completely. As soon as it exists in a repository by itself, it is easier to enforce a different regime of change control there, or even freeze it completely over time. To keep track of consensus changes one'd only have to follow that repository, instead of filter it between tons of GUI, RPC or utility commits. IMO having the consensus isolated into a portable self-contained library is the most important goal of Bitcoin Core project at this point. I've tried to keep the amount of unnecessary refactoring down, but some is unfortunately unavoidable. I'm sure we can find a way to rebase CHECKLOCKTIMEVERIFY so that it can land in 0.11. Wladimir -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ACK NACK utACK Concept ACK
On Wed, Dec 10, 2014 at 6:47 AM, Wladimir laa...@gmail.com wrote: Abbreviations: Concept ACK - agree with the idea and overall direction, but haven't reviewed the code changes nor tested it utACK - reviewed the code changes, but did not put it through any testing Tested ACK - reviewed the code changes and verified the functionality/bug fix And there is also NACK, that's an aspecific 'I wouldn't like this merged'. I always explain why in the text. A document on this would be welcome, as it may look like Martian to outsiders. That's been brought up many times before, but no one ever created it. Wladimir -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ACK NACK utACK Concept ACK
Abbreviations: Concept ACK - agree with the idea and overall direction, but haven't reviewed the code changes nor tested it utACK - reviewed the code changes, but did not put it through any testing Tested ACK - reviewed the code changes and verified the functionality/bug fix I tend to only use bare ACK if there is nothing to test in the first place, for example for documentation changes. Wladimir On Tue, Dec 9, 2014 at 9:30 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: Also utACK (untested ack) and tested ack when people are being explicit. On 12/09/14 21:14, Sergio Lerner wrote: Is that the full terminology or are there more acronyms? Is this documented somewhere? Best regards, Sergio. -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
On Thu, Nov 27, 2014 at 2:22 AM, Gregory Maxwell gmaxw...@gmail.com wrote: Since this attack vector has been discussed, I started making some measurements on how effective it is to connect to Bitcoin using Tor, and I found that the number of connections dropping to near-zero is a situation which occurs rather frequently, which suggests that there is still room to improve on the DoS handling. I'm confused by this, I run quite a few nodes exclusively on tor and chart their connectivity and have seen no such connection dropping behaviour. In my experience the problem has always been getting bootstrapped. Most nodes hardly give any hidden service nodes in their getaddr. (this has been improved in master by including a set of hidden service seed nodes) But this assumes -onlynet=tor. Tor with exit nodes should be less problematic, unless someone managed to DoSban all the exit nodes as described in the paper (but I've never seen such an attack myself). Can you tell me more about how you measured this? [As an aside I agree that there are lots of things to improve here, but the fact that users can in theory be forced off of tor via DOS attacks is not immediately concerning to me because its a conscious choice users would make to abandon their privacy (and the behaviour of the system here is known and intentional). There are other mechanisms available for people to relay their transactions than connecting directly to the bitcoin network; so their choice isn't just abandon privacy or don't use bitcoin at all.] Right, there's something to be said for splitting your own transaction submission from normal P2P networking and transaction relay. (esp for non-SPV wallets which don't inherently leak any information about their addresses) There was a pull request about this for Bitcoin Core one, maybe I closed it unfairly https://github.com/bitcoin/bitcoin/issues/4564 . Wladimir -- 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=157005751iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
On Sun, Nov 16, 2014 at 5:21 PM, Flavien Charlon flavien.char...@coinprism.com wrote: Hi, The data that can be embedded as part of an OP_RETURN output is currently limited to 40 bytes. It was initially supposed to be 80 bytes, but got reduced to 40 before the 0.9 release to err on the side of caution. After 9 months, it seems OP_RETURN did not lead to a blockchain catastrophe, Agreed. I'm in favor of increasing OP_RETURN size as well. Don't care about the actual size. (rationale: pruning is going to land soonish, and everything is better than UTXO-polluting methods that encode everything into addresses such as now used by cryptograffiti) Wladimir -- 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=157005751iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [ann] Live Bitcoin Core commits on #bitcoin-commits
All, As of now you can join #bitcoin-commits on freenode to be notified of commits to the bitcoin/bitcoin repository. Thanks to Luke-Jr for telling me how to set this up. Regards, Wladimir -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
On Fri, Nov 7, 2014 at 12:30 PM, Clément Elbaz clem...@gmail.com wrote: Thinking out loud here : would it make sense to separate the consensus code into some kind of Bitcoin Kernel (similar to the Linux Kernel) project that could be used by anyone ? Yes, we're moving in that direction. First with a script verification library in 0.10, which will be extended to other parts of the consensus by 0.11 and after that. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bug in genbuild.sh ?
On Mon, Nov 3, 2014 at 10:16 AM, Francis GASCHET f...@numlog.fr wrote: Hello, I just compiled bitCoin core on Debian 7. I got an error message too many arguments when executing genuid.sh I fixed it as shown hereafter and it worked fine. pcfg:~/bitcoinCore diff -u shareOLD/genbuild.sh share/genbuild.sh --- shareOLD/genbuild.sh2014-11-03 08:32:08.950708258 +0100 +++ share/genbuild.sh 2014-11-03 08:38:44.626698114 +0100 @@ -16,7 +16,7 @@ DESC= SUFFIX= LAST_COMMIT_DATE= -if [ -e $(which git 2/dev/null) -a $(git rev-parse --is-inside-work-tree 2/dev/null) = true ]; then +if [ -e $(which git 2/dev/null) -a $(git rev-parse --is-inside-work-tree 2/dev/null) = true ]; then # clean 'dirty' status of touched files that haven't been modified git diff /dev/null 2/dev/null ACK FYI there's an issue for this on github: https://github.com/bitcoin/bitcoin/pull/5141 , but Rebroad's solution contains a new error. Will merge your patch. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule
On Sun, Oct 26, 2014 at 9:53 AM, Luke Dashjr l...@dashjr.org wrote: On Sunday, October 26, 2014 7:57:12 AM Wladimir wrote: Let me know if there is anything else you think is ready (and not too risky) to be in 0.10. At the very least, we need: #5106 Bugfix: submitblock: Use a temporary CValidationState to determine ... #5103 CreateNewBlock and miner_tests: Also check generated template is ... #5078 Bugfix: CreateNewBlock: Check that active chain has a valid tip ... (or at least some conclusion for the problem discussed therein) OK Harmless/No reason not to have: #3727 RPC: submitblock: Support for returning specific rejection reasons #1816 Support for BIP 23 block proposal #5144 Qt: Elaborate on signverify message dialog warning #5071 Introduce CNodePolicy for putting isolated node policy code and ... (futher commits exist that should ideally get in after this is merged) ACK on the UI change, I think it would be best to let the full-blown miner policy class wait for 0.11. Debatable (but harmless, and miners seem to want it): #5077 Enable customising node policy for datacarrier data size with a ... OK, that's a low-risk change, it just makes what is now a constant configurable. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule
On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho melvincarva...@gmail.com wrote: Firstly, apologies in coming in late to the conversation. As I am also working on a REST API for electronic coins. Some questions: 1. Is there a BIP, or some other doc (e.g. gist), outlining the REST output e.g. the response format and MIME types. Or just compile from source? See the opening post from @jgarzik, it has some documentation on how to use the API. It would be nice to have some write-up about the current functionality in the release notes, but there currently is none. It's a RPC-side change, not a P2P-side change so it doesn't require a BIP. 2. How set in stone is v1 of the the going forward? PS I support @maaku's comments re: /api/v1/ -- tho I guess it is too late for that now. 3. Would there be any support to develop this interface into something that would be W3C standards compliant, or reviewed by the REST community. So for example a context can be provided to self document the terms (something I've almost completed) and would allow standardization of block explorer and bitcoind outputs. Right now every explorer seems to have a different JSON output. It's not too late, it's not been merged yet. Though a W3C standard takes a long time to pan out, and it may be more useful to have this available rather than wait for the API to be standardized (which means this will need to be postponed at least one version). As you say, a new interface be added later under another URI. Note that we're only interested in exposing read-only, public data which is already available in Bitcoin Core's internals. We're not aiming to add a fully-fledged block explorer with (say) address indexes. Although that could be part of the standard if it allows implementations to support just a subset. Anyhow - please coordinate this with Jeff Garzik, it's better to work together here. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Core 0.10 release schedule
Now that headers-first is merged it would be good to do a 0.10 release soon. Not *too* soon as a major code change like that takes some time to pan out, but I'd like to propose the following: - November 18: split off 0.10 branch, translation message and feature freeze - December 1: release 10.0rc1, start Release Candidate cycle That leaves three weeks until the freeze. After the release and branch split-off, the RC cycle will run until no critical problems are found. For major releases this is usually more painful than for stable releases, but if we can keep to these dates I'd expect the final release no later than January 2015. Let's aim to have any pending development for 0.10 merged before November 18. Major work that I'm aware of is: - BIP62 (#5134, #5065) - Verification library (#5086, #5118, #5119) - Gitian descriptors overhaul, so that Gitian depends = Travis depends (#4727) - Autoprune (#4701) - Add warmup mode for RPC server (#5007) - Add unauthenticated HTTP REST interface (#2844) Let me know if there is anything else you think is ready (and not too risky) to be in 0.10. You can help along the development process by participating in testing and reviewing of the mentioned pull requests, or just by testing master and reporting bugs and regressions. Note: I intended the 0.10 release to be much sooner. The reason that this didn't pan out is that I insisted on including headers-first, and this took longer than expected. There seems to be a preference to switch to a fixed (instead of feature-based) 6-month major release schedule, ie - July 2015: 0.11.0 (or whatever N+1 release is called) - January 2016: 0.12.0 (or whatever N+2 release is called) - July 2016: 0.13.0 (or whatever N+3 release is called) Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About watch-only addresses
On Fri, Oct 17, 2014 at 10:36 PM, Flavien Charlon flavien.char...@coinprism.com wrote: Hi, What is the status of watch-only addresses in Bitcoin Core? Is it merged in master and usable? Is there documentation on how to add a watch-only address through RPC. It has been merged. There is the importaddress RPC call, which works the same as importprivkey except that you a pass it an address. Also, I believe that is going towards the 0.10 release, is there a rough ETA for a release candidate? Yes - aim is in a few months, probably by the end of the year. AFAIK there are no nightly builds at this moment. Warren Togami was building them for a while (at http://nightly.bitcoin.it/) but he stopped some time around June. It's not recommended to use master without at least a little bit of development/debugging experience of yourself (to trace down problems when they appear), so it's best to build it yourself if you're going to test day-to-day development versions. Wladimir -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP status changes
Shouldn't we be doing this in a GitHub PR rather than spamming up the ML? Not really. BIP changes should be discussed on the mailing list, that's the way to get community consensus (as specified in BIP1). Wladimir -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP process
Hello, I'm trying to create a bit of process around the https://github.com/bitcoin/bips repository. A) Currently a lot of pulls are open for various BIPs and it is not clear who should comment on them, or who decides on changes to be merged. Currently all BIP changes have to go through the Bitcoin Core team, which is a narrow bottleneck and makes little sense when you think about it. But I don't want to go back to the wiki state in which everyone can make arbitrary changes to any BIP - we need to distribute the process somehow. I'd like to propose to make the author (or someone they delegate to) the primary contact for each BIP. They should comment on changes, and either accept or reject them. If they accept them, the change will be merged. Of course this means that there is a responsibility for the author to adhere to BIP 1. For example if your BIP is final, don't allow any technical changes. To do small clarifications, spelling or adding implementations or examples is OK, but changing or adding to a protocol is not - this needs a new BIP. Changing your BIP status without community consensus is also not OK. B) I also think it makes sense to move the BIP discussion (both about the BIP process and individual BIPs) to a separate mailing list. bitcoin-development currently has a dual function: discussion of Bitcoin Core implementation concerns, as well as global changes to Bitcoin (in the form of BIPs). This makes the list too busy for some people, but it is critical that everyone writing a Bitcoin node or client is up-to-date with proposals and can comment on them. Wladimir -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposed BIP status changes
These BIPs should go to Final state - they are implemented all over the place, and are thus entirely fixed in place now. Any changes would require a new BIP as amandment: - BIP 14 (BIP Protocol Version and User Agent) - BIP 21 (URI Scheme) - BIP 22 (getblocktemplate - Fundamentals) - BIP 31 (Pong Message) - BIP 34 (Block v2, Height in coinbase) - BIP 35 (mempool message) - BIP 37 (Bloom filtering) Let me know if you (don't) agree. Wladimir -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
This all makes a lot of sense to me, and would help a lot with the workflow. Unfortunately github pulls and issues really have nothing to faciltate a multistage workflow... e.g. where something can go through several steps. Indeed, pull requests don't have a status. It would be possible to (ab)use labels for this. The drawback of labels is that only the repository team can set these, there is no way to delegate. But I suppose it'd be possible to build something on top of the github API that handles this. We're also having problems with people failing to comment on things, not even I looked at this and have no opinion, which is really obstructing things. Well - the only way to avoid that is to set a reasonable deadline, after which there is a default decision. You'd hope this would motivate people to get involved in time. Wladimir -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleable booleans
On Tue, Oct 14, 2014 at 9:27 AM, Thomas Zander tho...@thomaszander.se wrote:
On Tuesday 14. October 2014 04.34.16 Pieter Wuille wrote:
This means that scripts that use booleans as inputs will be inherently
malleable.
I've ran into this issue in C++ often enough,
a funny example is assigning 2 to a native c++ bool and then you can do a
if (myBool == true)
else if (myBool == false)
and neither of them will hit.
Off topic nit: I think you're confused with custom BOOL typedefs in C?
C++ booleans are protected against this (C++ standard §4.7/4 according
to Google).:
```
#include stdio.h
int main()
{
bool myBool;
myBool = 2;
if (myBool == true)
printf(It is true!\n);
else if (myBool == false)
printf(It is false!\n);
else
printf(It is something else!\n);
}
```
Prints 'It is true'. You can also use bool(something) as equivalent of
`x != 0`; as in `assert(bool(2) == true);`.
Wladimir
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request for review/testing: headers-first synchronization in Bitcoin Core
On Sun, Oct 12, 2014 at 10:41 AM, Geir Harald Hansen opera...@bitminter.com wrote: On 12.10.2014 01:34, Pieter Wuille wrote: * No orphan blocks stored in memory anymore (reducing memory usage during sync). Will this slow down reorgs after a fork, compared to today? Why would you think so? Orphan blocks are blocks whose parent is not known. In the case of a reorganization the client 'jumps' to a new best chain, for this to happen the original tip and the new best tip and all their parents must be already known. Wladimir -- 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 Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn m...@plan99.net wrote: That is easy to change; I'll submit a pull request. That's certainly a useful improvement. It won't help the existing userbase though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. The next minor release (0.9.4) could have Gavin's change already. I don't think CHECKLOCKTIMEVERIFY will make it into the next major release though. Once headers-first and pruning is merged (which is expected to be a matter of weeks). I'd like to split off the 0.10 branch and give it some time to stabilize with a feature freeze, then do a release before the end of the year. So 0.11, in say 6 months, would be soonest. Wladimir -- 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] bitcoinj 0.12
On Fri, Oct 3, 2014 at 2:49 PM, Mike Hearn m...@plan99.net wrote: I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most popular Bitcoin libraries. It is used by at least four Android wallets, three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp, Lighthouse, BlueMatt’s relay network, bitpos, countless alt coin wallets, for academic research projects and much more. Congrats on the release! Wladimir -- 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
[Bitcoin-development] [ann] Bitcoin Core 0.9.3 has been released
Bitcoin Core version 0.9.3 is now available from: https://bitcoin.org/bin/0.9.3/ This is a new minor version release, bringing only bug fixes and updated translations. Upgrading to this release is recommended. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues Upgrading and downgrading == How to Upgrade -- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). If you are upgrading from version 0.7.2 or earlier, the first time you run 0.9.3 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine. Downgrading warnings The 'chainstate' for this release is not always compatible with previous releases, so if you run 0.9.x and then decide to switch back to a 0.8.x release you might get a blockchain validation error when starting the old release (due to 'pruned outputs' being omitted from the index of unspent transaction outputs). Running the old release with the -reindex option will rebuild the chainstate data structures and correct the problem. Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan the blockchain for missing spent coins, which will take a long time (tens of minutes on a typical machine). 0.9.3 Release notes === RPC: - Avoid a segfault on getblock if it can't read a block from disk - Add paranoid return value checks in base58 Protocol and network code: - Don't poll showmyip.com, it doesn't exist anymore - Add a way to limit deserialized string lengths and use it - Add a new checkpoint at block 295,000 - Increase IsStandard() scriptSig length - Avoid querying DNS seeds, if we have open connections - Remove a useless millisleep in socket handler - Stricter memory limits on CNode - Better orphan transaction handling - Add `-maxorphantx=n` and `-maxorphanblocks=n` options for control over the maximum orphan transactions and blocks Wallet: - Check redeemScript size does not exceed 520 byte limit - Ignore (and warn about) too-long redeemScripts while loading wallet GUI: - fix 'opens in testnet mode when presented with a BIP-72 link with no fallback' - AvailableCoins: acquire cs_main mutex - Fix unicode character display on MacOSX Miscellaneous: - key.cpp: fail with a friendlier message on missing ssl EC support - Remove bignum dependency for scripts - Upgrade OpenSSL to 1.0.1i (see https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no critical issues for Bitcoin Core) - Upgrade miniupnpc to 1.9.20140701 - Fix boost detection in build system on some platforms Credits Thanks to everyone who contributed to this release: - Andrew Poelstra - Cory Fields - Gavin Andresen - Jeff Garzik - Johnathan Corgan - Julian Haight - Michael Ford - Pavel Vasin - Peter Todd - phantomcircuit - Pieter Wuille - Rose Toomey - Ruben Dario Ponticelli - shshshsh - Trevin Hofmann - Warren Togami - Wladimir J. van der Laan - Zak Wilcox As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). -- 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] [ann] Bitcoin Core 0.9.3 rc2 is available for download
FYI rc2 has been uploaded last weekend to https://bitcoin.org/bin/0.9.3/test/, with some further fixes in network and memory behaviour - Remove a useless millisleep in socket handler - Stricter memory limits on CNode - Better orphan transaction handling - Add `-maxorphantx=n` and `-maxorphanblocks=n` options for control over the maximum orphan counts Wladimir -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On Fri, Sep 12, 2014 at 10:59 PM, Mark van Cuijk m...@coinqy.com wrote: If you do so, please make sure the length of the hash is included in the PaymentDetails/PaymentRequest. If someone parses the URI and doesn’t have an authenticated way of knowing the expected length of the hash, a MITM attacker can just truncate the hash to lower security. But if they can truncate they can just as well pass a completely different hash that matches their payment request. If an attacker can change the bitcoin: URI, this scheme is broken. The point of the proposal is to make sure that the payment request matches the URI. So *if* you communicate the URI by secure means, this authenticates the associated payment request as well, even if fetched by insecure means (such as http:...) itself. Wladimir -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On Fri, Sep 12, 2014 at 11:29 AM, Andreas Schildbach andr...@schildbach.de wrote: This is the discussion post corresponding to this PR: https://github.com/bitcoin/bips/pull/106 Amend BIP72 by an h parameter, which contains a hash of the PaymentRequest message that is fetched via the r parameter. The hash is meant to link the trust anchor (e.g. the QR code) to the payment request message in a secure way. This will solve the problem several apps are comparing address+amount fields as a workaround instead, preventing some advanced BIP70 usecases. When these apps read a matching hash, they need not compare any of the other fields. Sounds like a good idea to me. I had no idea that some clients were comparing addresses and amounts in the URI with the payment request for security, that seems like a hacky and inflexible way. This is much better. Wladimir -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [ann] Bitcoin Core 0.9.3 rc1 is available for download
Bitcoin Core version 0.9.3rc1 is now available from: https://bitcoin.org/bin/0.9.3/test/ This is a release candidate (test version) for a new minor version release, bringing only bug fixes and updated translations. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues Upgrading and downgrading == How to Upgrade -- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). If you are upgrading from version 0.7.2 or earlier, the first time you run 0.9.3 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine. Downgrading warnings The 'chainstate' for this release is not always compatible with previous releases, so if you run 0.9.x and then decide to switch back to a 0.8.x release you might get a blockchain validation error when starting the old release (due to 'pruned outputs' being omitted from the index of unspent transaction outputs). Running the old release with the -reindex option will rebuild the chainstate data structures and correct the problem. Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan the blockchain for missing spent coins, which will take a long time (tens of minutes on a typical machine). 0.9.3 Release notes === RPC: - Avoid a segfault on getblock if it can't read a block from disk - Add paranoid return value checks in base58 Protocol and network code: - Don't poll showmyip.com, it doesn't exist anymore - Add a way to limit deserialized string lengths and use it - Add a new checkpoint at block 295,000 - Increase IsStandard() scriptSig length - Avoid querying DNS seeds, if we have open connections Wallet: - Check redeemScript size does not exceed 520 byte limit - Ignore (and warn about) too-long redeemScripts while loading wallet GUI: - fix 'opens in testnet mode when presented with a BIP-72 link with no fallback' - AvailableCoins: acquire cs_main mutex - Fix unicode character display on MacOSX Miscellaneous: - key.cpp: fail with a friendlier message on missing ssl EC support - Remove bignum dependency for scripts - Upgrade OpenSSL to 1.0.1i (see https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no critical issues for Bitcoin Core) - Upgrade miniupnpc to 1.9.20140701 - Fix boost detection in build system on some platforms Credits Thanks to everyone who contributed to this release: - Andrew Poelstra - Cory Fields - Jeff Garzik - Johnathan Corgan - Julian Haight - Michael Ford - Pavel Vasin - Peter Todd - Pieter Wuille - Rose Toomey - Ruben Dario Ponticelli - Trevin Hofmann - Wladimir J. van der Laan - Zak Wilcox As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). -- 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
Re: [Bitcoin-development] Reconsidering github
On Sat, Aug 23, 2014 at 1:38 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Note that we're generally aiming (though not yet enforcing) to have merges done through the github-merge tool, which performs the merge locally, shows the resulting diff, compares it with the merge done by github, and GnuPG signs it. Indeed. I always use that look at and test and the merges locally before pushing them. I never use the github merge button. I'd recommend other people to do so as well - and as can be seen with `git log --show-signature` it's common practice. For browsing git history locally I find gitk to be a useful tool. I'd absolutely encourage for more people to review code changes. Even better if a few people do this through local tooling instead of the web page. But my gut feeling is that hosting the code on github results in many more eyes on the code overall than would be when requiring *everyone* to use local tools. It's easy to let paranoia get in the way of actual effectiveness. Wladimir -- 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
Re: [Bitcoin-development] Reconsidering github
On Wed, Aug 20, 2014 at 3:26 AM, Troy Benjegerdes ho...@hozed.org wrote: If bitcoin wants to become irrelevant, then by all means, continue to depend on github and all the unknown attack surface it exposes. Those of us that do run our own servers will migrate to higher quality alternatives. So that means you're volunteering to run a web-accessible mirror of the bitcoin repositories? Wladimir -- 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
Re: [Bitcoin-development] Reconsidering github
On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik jgar...@bitpay.com wrote: It would be nice if the issues and git repo for Bitcoin Core were not on such a centralized service as github, nice and convenient as it is. Despite my complaining about github, I don't like the idea of moving somewhere else. The current way of working - to use github for storing the tree, and use a custom script for signing+merging - is fine with me. Github has a low barrier to contribution. Almost every open source developer already has a github account. Switching to something self-hosted makes it more difficult for people to contribute. Plus if we have to take the hosting upon ourselves, we have to handle sysadmin work ourselves as well. That's not a good use of the limited manpower available. Also it will be a lot of work to migrate over all the current issues and pulls. I don't look forward to that. I don't see the point of this, sorry. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] What is the danger if bitcoind startted with -flushwallet=false ?
On Wed, Aug 13, 2014 at 6:22 PM, 潘庆庆 qingqing@okcoin.com wrote: Hi everybody, I tried to reduce the IO of bitcoind, and I found '-flushwallet=false'. After trying it, my IO reduced greatly. But why 'flushwallet' is true by default? Is there any danger if closing the flush wallet thread? I lost all my coins in testnet after one crash with '-flushwallet=false', was this because of no flush wallet thread? When flushwallet is disabled, the wallet is not flushed (written to disk in a self-contained state) periodically. This means that there's a larger chance that the wallet database is in inconsistent state when the process stops unexpectedly. This can happen either due to a crash, or an external cause such as the power turning off unexpectedly. With the wallet in non-self-contained state, the next time that you start bitcoind BerkeleyDB will have to process log files. There is a non-zero chance that this will fail and manual recovery is needed. As the wallet is usually critical, it is unwise to disable that option. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 11:45 AM, Mike Hearn m...@plan99.net wrote: Given that we're not running out of service bits and service bits mean you don't have to try connecting to every node to find out what services it supports, why not keep using the existing extension mechanism until we start running out of bits? He wants to use it to advertise services that are not part of the P2P protocol itself, but run on a different port. Reserving services bits for those is not acceptable. All the NODE_EXT_SERVICES bit does is advertise the P2P getextsrv command to get information, such as the port to connect on, for the auxilary service. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn m...@plan99.net wrote: He wants to use it to advertise services that are not part of the P2P protocol itself, but run on a different port. Reserving services bits for those is not acceptable. Why not? Does the port matter much? Yes. The services bits are for advertising services on the P2P network. That's not open for discussion. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 12:15 PM, Wladimir laa...@gmail.com wrote: On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn m...@plan99.net wrote: He wants to use it to advertise services that are not part of the P2P protocol itself, but run on a different port. Reserving services bits for those is not acceptable. Why not? Does the port matter much? Yes. The services bits are for advertising services on the P2P network. That's not open for discussion. It also wouldn't work. A bit is not enough to find an external service except in the naive case where the advertised service would have a fixed port. Not even bitcoind has a fixed port. So there needs to be a mechanism to find how to connect to the 'external service'. This is provided by the proposed extension. It would in principle be possible to advertise an extra service bit *in addition to* this one, to make it easier to find through the addr mechanism. But it would be confusing and IMO an abuse of P2P service bits. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
Generally agreed, though for ZMQ it is a bit different than a P2P service. IMO, ZMQ really wants to be a plug-in that registers some internal signals. It wants to capture the precise points where a block was accepted internally. PR #4599 tries to lead by example: https://github.com/bitcoin/bitcoin/pull/4599 A P2P service would be a slightly different sort of plug-in. ZeroMQ is just a lightweight message routing system. It could just as well make P2P messages available to other applications (if they subscribe to them). The other way around, routing messages from ZeroMQ to certain P2P clients, is easy. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn m...@plan99.net wrote: Something like `getutxos` or this proposal could be implemented as an external application or script, instead of having to integrate everything into bitcoind. Right, although getutxos needs access to the UTXO set which bitcoind already has. An external plugin would have to recalculate it from scratch which seems redundant. Well to play the devil's advocate, you could set it up to query the information back over RPC :-) But yeah, I didn't mean getutxos specifically, it has a trivial implementation anyway. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn m...@plan99.net wrote: Maybe, that feels like it could be overkill though. Probably just something like ./bitcoind -servicecookie=long random string -allowextservices=127.0.0.1/8 I don't like conflating the external and internal interface. The interface to the outside and the interface to the inside should be well-separated. I'd be OK with such an idea if bitcoind listens on a separate port for connections from plugins, a port that cannot be used for normal P2P traffic. This could also be a UNIX socket instead of a TCP port. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin development (testing where to get Wallet code)
On Wed, Jul 30, 2014 at 12:32 AM, Caleb Roger Davis moab...@gmail.com wrote: I have several Bitcoin contributions I would like to make, mostly for learning purposes to get started: I would like to contribute to unit and/or other types of tests (code), not production code. Low-level unit tests are in `src/test`. These use the boost unit-testing framework. You can run them with 'make check' or `src/test/test_bitcoin`. High-level RPC tests are in `qa/rpc-tests`. These are Python scripts that can be invoked manually, and are based on our own simple framework. There is also a java-based 'comparison tool' that tests high-level behavior with regard to the block chain. It is based on bitcoinj and acts as an external node. This is not part of the github bitcoin repository itself, but of bitcoinj (AFAIK). I would like to understand the Bitcoin code (as much as possible from top to bottom) See https://www.bitcoin.org/en/developer-guide I would like to write a Bitcoin wallet in another language (so would like to know where to get the Bitcoin - Core Wallet code, but not sure where it resides. All of the wallet code is in `src/wallet.cpp` and `src/walletdb.cpp`. If the purpose is just studying, the bitcoin core wallet is not the most readable wallet code around, and also hard to port as it relies on a full node in the same process. It's better to look at SPV wallets, for example the bitcoinj-based ones. I am a seasoned software developer, but I do need direction on where to get started. If there is a wiki doc for new developers that would reduce my searching and experimentation that would be great. Something like that would be useful, yes. For each of the three items above, I would like to know the tools and frameworks I would need to understand and initially work on tests ( how to run the existing tests to get code coverage and find where coverage is needed, what is the preferred IDE and full development stack etc ), and also where to get started looking at the bitcoin core code and also the wallet code (where is the initial starting point and then I could trace from there ). If you want to work on Bitcoin Core, a Linux box (or VM) is the best development environment. Getting started building on WIndows or Mac is harder (but possible). There is work in progress to make building the dependencies easier for those. Wladimir -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Abusive and broken bitcoin seeders
The version message helpfully tells me my own IP address but not theirs ;p Try -logips. Logging peer IPs was disabled by default after #3764. BTW I'm seeing the same abusive behavior. Who is running these? Why do the requests need to be so frequent? Wladimir -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Policy for DNS seeds
We've established a few basic rules for the DNS seeds as used in the Bitcoin Core software. See below. If you run one of the DNS seeds please reply to this and let us know whether you agree to these terms. if you think some requirements are unreasonable let us know too. If we haven't heard from you by 2014-08-04 we will remove your DNS seed from the list of defaults. Expectations for DNSSeed operators Bitcoin Core attempts to minimize the level of trust in DNS seeds, but DNS seeds still pose a small amount of risk for the network. Other implementations of Bitcoin software may also use the same seeds and may be more exposed. In light of this exposure this document establishes some basic expectations for the expectations for the operation of dnsseeds. 0. A DNSseed operating organization or person is expected to follow good host security practices and maintain control of their serving infrastructure and not sell or transfer control of their infrastructure. Any hosting services contracted by the operator are equally expected to uphold these expectations. 1. The DNSseed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network to the best of the operators understanding and capability. 2. For the avoidance of doubt, the results may be randomized but must not single-out any group of hosts to receive different results unless due to an urgent technical necessity and disclosed. 3. The results may not be served with a DNS TTL of less than one minute. 4. Any logging of DNS queries should be only that which is necessary for the operation of the service or urgent health of the Bitcoin network and must not be retained longer than necessary or disclosed to any third party. 5. Information gathered as a result of the operators node-spidering (not from DNS queries) may be freely published or retained, but only if this data was not made more complete by biasing node connectivity (a violation of expectation (1)). 6. Operators are encouraged, but not required, to publicly document the details of their operating practices. 7. A reachable email contact address must be published for inquiries related to the DNSseed operation. If these expectations cannot be satisfied the operator should discontinue providing services and contact the active Bitcoin Core development team as well as posting on bitcoin-development. Behavior outside of these expectations may be reasonable in some situations but should be discussed in public in advance. See https://github.com/bitcoin/bitcoin/pull/4566 Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire
On Fri, Jul 18, 2014 at 4:53 PM, Gavin Andresen gavinandre...@gmail.com wrote: Two more half-baked thoughts: We should be able to assume that the majority of transaction data (except for coinbase) has already been propagated. As Jeff said, incentivizing nodes to propagate transactions is a very good thing (the signature cache already gives a small incentive to miners to propagate and not 'hoard' transactions). Maybe a stupid idea - but couldn't we make that assumption a surety by starting the 'set synchronization process' as soon as the miner starts crunching on a certain block, instead of when it broadcasts it? So the peers are prepared, and the actual block broadcast is just the header + coinbase tx. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Small update to BIP 62
On Fri, Jul 18, 2014 at 5:14 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Hi all, I've sent a pull request to make a small change to BIP 62 (my anti-malleability proposal) which is still a draft; see: * https://github.com/bitcoin/bips/pull/90 (the request) * https://github.com/sipa/bips/blob/bip62up/bip-0062.mediawiki (the result) It makes two of the 7 new rules mandatory in new blocks, even for old-style transactions. Both are already non-standard since 0.8.0, and have no use cases in my opinion. Looks good to me. The reason for this change is dropping the requirement for signature verification engines to be bug-for-bug compatible with OpenSSL (which supports many non-standard encodings for signatures). Requiring strict DER compliance for signatures means any implementation just needs to support DER. This is certainly a good thing. Not even OpenSSL is guaranteed to be bug-for-bug compatible with its own prior versions forever, so better to strictly define what is allowed. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 38 NFC normalisation issue
On Wed, Jul 16, 2014 at 11:29 AM, Mike Hearn m...@plan99.net wrote: Yes sorry, you're right, the issue starts with the null code point. Python seems to have problems starting there too. It might work if we took that out. Forbidding control characters, at least anything 32 makes a lot of sense to me. Carriage returns, linefeeds, formfeeds, null characters, I see no valid reason to allow them and lots of reasons they could cause havoc. PILE OF POO or GRINNING CAT FACE WITH SMILING EYES should be allowed in this day and age though. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
On Tue, Jul 15, 2014 at 10:00 AM, Jeff Garzik jgar...@bitpay.com wrote: Proxying another's idea, from CoinSummit. The request: It would be useful to limit the lifetime of a bitcoin address. Intentionally prevent (somehow) bitcoins being sent to a pubkey/pkh after the key expires. Payment request expiration was meant to address this. Adding an optional expiration timestamp to addresses would be possible, however, it would be a non-backward-compatible change and lots of software would have to be changed at this point. In my opinion encouraging the use of the payment protocol and deprecating the use of addresses is the best way forward, and not just for this reason. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
On Tue, Jul 15, 2014 at 10:23 AM, Jeff Garzik jgar...@bitpay.com wrote: On Tue, Jul 15, 2014 at 4:19 AM, Wladimir laa...@gmail.com wrote: There are major gaps that the payment protocol doesn't cover. There are several deployed use cases where you are provided/request an address, an API provides one, and one or more incoming payments arrive as the user sends them over minutes/hours/days/weeks. Couldn't these services return a payment message instead of an address? I agree that there is currently an UI issue here: there is no way in current wallets to store a payment message and pay to it later. We will need something like that for recurring payments as well. Bitcoin addresses were never designed with extensibility in mind. Before the payment protocol there have been lots of ideas to add functionality to them, but the underlying idea that they have to be handled by users manually means that they have to be as short as possible, which is a conflicting aim with extensibility... Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Protocol Specification
As a loose description of the protocol for newbies it's an invaluable resource and perhaps we should link to it from the developer guide. It has already been linked from the developer guide for quite a while, under Additional Resources. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck#174; Code Sight#153; - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anyone still using SOCKS4?
On Mon, Jul 7, 2014 at 8:34 AM, Odinn Cyberguerrilla odinn.cyberguerri...@riseup.net wrote: Wait, I thought SOCKS4 was supposed to help somehow in terms of prevention of leaking of information? SOCKS4a (unlike SOCKS4) supports doing DNS lookups on the server, but it is not supported by bitcoin core. So it is not part of this discussion. And SOCKS5 can do all of that just as well. But if you feel like contributing SOCKS4a support that's fine with me. Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anyone still using SOCKS4?
On Wed, Jun 11, 2014 at 5:39 PM, Wladimir laa...@gmail.com wrote: If no one screams fire, we plan on removing support for it in the next major release, for two reasons: - It would remove some crufty, hardly tested code paths - SOCKS5 offers better privacy as it allows DNS redirection Another one: - SOCKS5 supports IPv6 Last call... Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About the small number of bitcoin nodes
- Create a grafical interface for bitcoind on Linux servers: Create a command, for example bitcoind show that shows a nice summary in your Terminal (Console) with all the data that a node administrator wants to know. When I say grafical interface I mean like top command, an interface made out of characters in ASCII. FYI someone created this! It's still in the initial stages, I'm sure the author could use some help to grow this into a full-functional node admin tool. https://github.com/azeteki/bitcoind-ncurses Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
The question is; what does this buy us, and is it worth the potentially huge amount of time it could take? My gut feeling is we have bigger fish to fry. There's plenty of work to do just on the core consensus code, making Bitcoin Core into a competitive wallet as well would be an additional burden. I don't intend to work on that myself but that's up to the people that want to contribute to that. Once it's a separate project it could either be a big success, or it could slowly wither away. It can have a release cycle separate from the node. Likely faster. The organizational reason to split off the wallet is to get rid of that responsibility (and code) from the bitcoind repo. Maintaining a wallet should not be part of maintaining the core infrastructure. But just deleting it would be unreasonable. However I may be quite biased, as I am the maintainer of what is primarily a wallet library :) Hah. I've thought about that migration path as well. From my experience the main thing people are missing with BitcoinJ is a quick and easy way to set up a wallet as a daemon, to use the functionality from non-java through RPC. But there are other interesting upcoming wallet projects as well, for example CoinVault. Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
On Tue, Jun 24, 2014 at 1:29 PM, Jorge Timón jti...@monetize.io wrote: On 6/24/14, Mike Hearn m...@plan99.net wrote: ou did want to separate the wallet code from the full node then that'd be the way to do it. Exactly, this is part of my point, the qt-wallet does not support SPV operation at this point, and that complex work should be done after the wallet is separated. Thus the first version of the separated wallet should be functionally equivalent to today's wallet, that is, a full node wallet (even though I understand Wladimir's arguments against full-node wallets). Do mind that some of the steps on the path of bitcoind towards SPV are also useful in general. For example, headers-first allows parallel block download, which would solve a lot of sync issues people are having - a much higher priority than the wallet. But anyhow I'm describing how I would do it. If you're going to do it, you can do it in any order that you want. As we're talking about a separate project here it's not even clear who will be maintainer. 2) That doesn't necessarily mean that optionally maintaining additional indexes in the core is not interesting for some use cases (interesting for bitcoind, I don't care much if electrum-server currently does this and more [with more dependencies]). Although Pieter thinks that should also be separated into an index node too, but I think that's another discussion. I don't understand your argument against Electrum here. Dependencies? Come on, that's a matter of software distribution. If that really bothers you I suppose you could contribute to Electrum server so that it has less deps. It doesn't make the protocol worth any less. Although Pieter and I disagree with regard to issue #4351, we agree on wanting to keep (or at least making) bitcoind as lean as possible. Maintaining extra indices for others doesn't fit in there - that's also why the address index patch was not merged. An 'index node' could be a different animal. Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
On Tue, Jun 24, 2014 at 2:16 PM, Mike Hearn m...@plan99.net wrote: priority. So a single unified program that just figures it out automatically rather than expecting users to assemble a bag of parts seems a goal worth striving for. As I've said before -- and I think we disagree here - I like moving towards a bag of parts of specialized tools, maintained by people that specialize in those tools, instead of a single project that aims to do and know everything. This encourages experimentation and makes competition possible and I think that is healthy in this space. Bitcoin has a strict need for consensus in the block chain format, scripting system and validation. Outside of those, innovation should be possible without any gatekeeper bottleneck or even widespread agreement. Wallets, what data to store on disk, what indices to maintain. But even P2P message extensions, as long as it doesn't interfere with the rest of the network. After an experiment is successful it could always be merged into bitcoin core. But then the 'what-ifers' have less ammo, as it has been tested in the real world. For user convenience it's still possible to package pre-assembled bags. But that doesn't need to figure into how things are developed. Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
On Mon, Jun 23, 2014 at 11:50 AM, Jorge Timón jti...@monetize.io wrote: I know there are plans to separate the wallet from the core code and I think it's a great idea that will result in cleaner and more modular software. But it seems like my assumptions on how this would be done may be incorrect. I was assuming that the wallet would consume data from a trusted bitcoind core node using rpc or a better interface like an http rest api (see PR #2844). It's least surprising if the wallet works as a SPV client by default. Then, users can use it without first setting up a core. Thus the idea would be to use P2P primarily. There could be a mode to use a trusted core by RPC for mempool/conflicted transaction validation and such. But I'm not sure about this - as we've seen, pure-SPV wallets work pretty well. If you want it to act as an edge router you can point a SPV wallet at your trusted core as well. There are no plans for adding Electrum-like functionality to bitcoind. There is already Electrum. Let's not reinvent any wheels. So the core would take care of the hard consensus stuff, and the wallet would maintain its own database with private keys, addresses, balances, etc. and would consume some data contained in bitcoind's database. Right, the wallet would keep track of those. I also assumed that the interface between wallet and core would include queries to the UTXO (see PR #4351) and maybe TXO (see PR #3652) for getting the historic balances. As said, I'm not sure these assumptions are true anymore so I ask. Is this the plan? Is the plan that the wallet will use the p2p directly and maintain its own chain database? It does not need to keep a full chain database. But it needs its own record of the chain, headers-only + what concerns the keys in the wallet. Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: allocate 8 service bits for experimental use
On Tue, Jun 17, 2014 at 11:29 PM, Jeff Garzik jgar...@bitpay.com wrote: I wrote a patch for string-based name extensions, circa 2011-2012. I agree that is preferable to unreadable bits, for reasons you cite. However, it was noted that extensions (or UUIDs etc.) would not be propagated around the network in addr messages, as service bits are. Thanks for letting me know, I didn't remember your patch. Ugh, yes, propagating all extensions in `addr` messages is not how I imagined this to work. But then there would need to be an alternative way to discover nodes that offer a certain extension. Alas, this moves it from a straightforward and common sense change to a significant change to the protocol. Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: allocate 8 service bits for experimental use
On Tue, Jun 17, 2014 at 10:08 AM, Wladimir laa...@gmail.com wrote: On Tue, Jun 17, 2014 at 10:02 AM, Matt Whitlock b...@mattwhitlock.name wrote: On Tuesday, 17 June 2014, at 9:57 am, Wladimir wrote: Yes, as I said in the github topic (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a string-based name space for extensions. Why use textual strings? These fields are not for human consumption. Why not use UUIDs, which are fixed length and will not waste as much bandwidth in the protocol? Or if you'd prefer a hierarchical namespace, you could use OIDs, a la ASN.1. Also it IS useful for these fields to be human readable for statistics, peer list views and such. When encountering a new, unknown extension when connecting to a node it's much more useful to get a google-able string to find out what it is about, than some long hexadecimal or dotted-number identifier. Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [ann] Bitcoin Core version 0.9.2 has been released
events while client is running - Optionally add third party links to transaction context menu - Check for !pixmap() before trying to export QR code (avoids crashes when no QR code could be generated) - Fix Start bitcoin on system login Miscellaneous: - Replace non-threadsafe C functions (gmtime, strerror and setlocale) - Add missing cs_main and wallet locks - Avoid exception at startup when system locale not recognized - Changed bitrpc.py's raw_input to getpass for passwords to conceal characters during command line input - devtools: add a script to fetch and postprocess translations Credits Thanks to everyone who contributed to this release: - Addy Yeow - Altoidnerd - Andrea D'Amore - Andreas Schildbach - Bardi Harborow - Brandon Dahler - Bryan Bishop - Chris Beams - Christian von Roques - Cory Fields - Cozz Lovan - daniel - Daniel Newton - David A. Harding - ditto-b - duanemoody - Eric S. Bullington - Fabian Raetz - Gavin Andresen - Gregory Maxwell - gubatron - Haakon Nilsen - harry - Hector Jusforgues - Isidoro Ghezzi - Jeff Garzik - Johnathan Corgan - jtimon - Kamil Domanski - langerhans - Luke Dashjr - Manuel Araoz - Mark Friedenbach - Matt Corallo - Matthew Bogosian - Meeh - Michael Ford - Michagogo - Mikael Wikman - Mike Hearn - olalonde - paveljanik - peryaudo - Philip Kaufmann - philsong - Pieter Wuille - R E Broadley - richierichrawr - Rune K. Svendsen - rxl - shshshsh - Simon de la Rouviere - Stuart Cardall - super3 - Telepatheic - Thomas Zander - Torstein Husebø - Warren Togami - Wladimir J. van der Laan - Yoichi Hirai -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [ann] Bitcoin Core version 0.9.2 has been released
On Tue, Jun 17, 2014 at 4:27 PM, Jesus Cea j...@jcea.es wrote: On 17/06/14 11:46, Wladimir wrote: Under Ubuntu 10.04: jcea@ubuntu:/tmp/bitcoin-0.9.2-linux/bin/64$ ./bitcoin-qt ./bitcoin-qt: symbol lookup error: ./bitcoin-qt: undefined symbol: _ZN10QTextCodec11validCodecsEv Did it work with the release candidate? Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Going to tag 0.9.2 final
On Sat, Jun 14, 2014 at 7:58 AM, Un Ix slashdevn...@hotmail.com wrote: Was joking, but isn't the translation process back-ended with runtime tests to ensure that any stray chars etc cause the application to fail? There is some postprocessing done in the script that fetches translation files (see https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/update-translations.py ). It removes stray control characters, but for example there is no check for number and presence of formatting characters. I generally check that by manually looking through the diffs. But would be great if someone added that. Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Going to tag 0.9.2 final
On Sat, Jun 14, 2014 at 7:42 AM, Un Ix slashdevn...@hotmail.com wrote: How about a prize for anyone who can spot any malicious strings within next hour? ;-) Hah, if there was to be a prize I'd rather have people looking out for icebergs than for wrongly arranged deck chairs :-) Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Going to tag 0.9.2 final
It cannot, it is just data. Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Anyone still using SOCKS4?
Hello all, Is anyone using a SOCKS4-only proxy with Bitcoin Core? SOCKS5 was introduced in 1996, so there is hardly an excuse to not support it. If no one screams fire, we plan on removing support for it in the next major release, for two reasons: - It would remove some crufty, hardly tested code paths - SOCKS5 offers better privacy as it allows DNS redirection Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 0.9.2rc2 tagged, gitian builds needed
Hello, This Friday I tagged 0.9.2rc2, with the following changes compared to 0.9.2rc1: - #4282: cwallet init fix - #4295: upgrade OpenSSL to 1.0.1h - #4261: Use pnode-nLastRecv as sync score We still need more gitian builds - I'd like to do the 0.9.2 final release end of this week as I haven't seen any new problems reported, but it'd be useful to get these last-minute fixes tested too. Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] # error Bitcoin cannot be compiled without assertions. NOT
On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese s9jaf...@stud.uni-saarland.de wrote: I think most concerns about the current use of asserts would be resolved if the currently used asserts would be changed to a nicer definition which is independent of NDEBUG, and a second class of debugging asserts would be introduced, which is exclusively for expensive, redundant checks and is disabled by NDEBUG. Also, most assertion errors that happen to people running Bitcoin Core are not caused by software bugs but database corruption errors (usually due to unclean shutdown). For example in case we detect missing/truncated block files or UTXO db consistency we should, instead of raising an assertion error, propose a -reindex - see also https://github.com/bitcoin/bitcoin/issues/2202 . So instead of using assertions we need a fatal error function for those problems which are probably recoverable in a certain specific way. In principle starting a reindex wouldn't even need to take down the entire process (though that's easier for implementation due to cleanup and assumptions made). Wladimir -- 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
[Bitcoin-development] Do not use github issues on BIPs repository
Hello, I see that people have been filing issues on the Bitcoin Improvement Requests repository, https://github.com/bitcoin/bips. This is not how it is supposed to work -- BIP authors are not required to monitor the github issues, and it is not a good place to discuss in the first place. If you have a remark about a BIP or want to discuss it please use this mailing list (preferably) or contact the authors some other way. After discussion you can submit a pull request. Or if the change is trivial, such as a typo, you can submit a pull immediately. For this reason I intend to disable issues (not pull requests, of course) on the repository. Wladimir -- 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
[Bitcoin-development] Bitcoin Core 0.9.2 release candidate 1 is available
code could be generated) - Fix Start bitcoin on system login Miscellaneous: - Replace non-threadsafe C functions (gmtime, strerror and setlocale) - Add missing cs_main and wallet locks - Avoid exception at startup when system locale not recognized - Changed bitrpc.py's raw_input to getpass for passwords to conceal characters during command line input - devtools: add a script to fetch and postprocess translations Credits Thanks to everyone who contributed to this release: - Addy Yeow - Altoidnerd - Andrea D'Amore - Andreas Schildbach - Bardi Harborow - Brandon Dahler - Bryan Bishop - Chris Beams - Christian von Roques - Cory Fields - Cozz Lovan - daniel - Daniel Newton - David A. Harding - ditto-b - duanemoody - Eric S. Bullington - Fabian Raetz - Gavin Andresen - Gregory Maxwell - gubatron - Haakon Nilsen - harry - Hector Jusforgues - Isidoro Ghezzi - Jeff Garzik - Johnathan Corgan - jtimon - Kamil Domanski - langerhans - Luke Dashjr - Manuel Araoz - Mark Friedenbach - Matt Corallo - Matthew Bogosian - Meeh - Michael Ford - Michagogo - Mikael Wikman - Mike Hearn - olalonde - paveljanik - peryaudo - Philip Kaufmann - philsong - Pieter Wuille - R E Broadley - richierichrawr - Rune K. Svendsen - rxl - shshshsh - Simon de la Rouviere - Stuart Cardall - super3 - Telepatheic - Thomas Zander - Torstein Husebø - Warren Togami - Wladimir J. van der Laan - Yoichi Hirai -- 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
