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
[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] Block Size Increase
On Wed, May 06, 2015 at 10:12:14PM +, Matt Corallo wrote: Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler). I'm weakly against a block size increase in the near future. Some arguments follow. For sake of brevity, this ignores the inherent practical and political issues in scheduling a hardfork. Against: 1. The everyone-verifies-everything approach inherently doesn't scale well. Yes, it is possible to increase the capacity, within limits, without completely destroying the system, but if scaling turns out to be a success, even a 20-fold increase is just a drop in the bucket (this will not make a decentralized Changetip possible). The gain will always be linear, at a total cost that scales in the number of (full node) users times the block size. The whole idea of everyone verifying the whole world's bus tickets and coffee purchases seems ludicrous to me. For true scaling, as well as decentralized microtransactions, the community needs to work on non-centralized 'level 2' protocols for transactions, for example the Lightning network. I prefer not to rely on faith that 'Moore's law' - which isn't a physical law but a trend - will save us. And it doesn't so much apply to communication bandwidth as its techniques are more diverse. E.g. for Bitsat, 20MB blocks will push the limit. 2a. Pushing up bandwidth and CPU usage will, inevitably, push people at the lower end away from running their own full nodes. Mind you, the sheer number of full nodes is not the issue, but Bitcoin's security model is based on being able to verify the shared consensus on one's own. A lot of recent development effort went into making the node software less heavy. Yes, one could switch to SPV, but that is a serious privacy compromise. In the worst case people will feel forced to move to webwallets. That was about sustained bandwidth - syncing a new node from scratch through the internet will become unwieldy sooner - this can be worked around with UTXO snapshots, but doing this in a way that doesn't completely pull the rug under the security model needs research (I'm aware that this could be construed the other way, that such a solution will be needed eventually and fast block chain growth just accelerates it). 2b. The bandwidth bound for just downloading blocks is ~4GB per month now, it will be ~52GB per month. Behind Tor and other anonimity networks, nodes will reveal themselves by the sheer volume of data transferred even to only download the block chain. This may already be the case, but will become worse. It may even become harmful to Tor itself. 3a. The costs are effectively externalized to users. I, hence, don't like calling the costs trivial. I don't like making this decision for others, I'm not convinced that they are trivial for everyone. Besides, this will increase supply of block chain space, and thus push down transaction fees, but at cost to *all users*, even users that hardly do any transactions. Hence it favors those that generate lots of transactions (is that a perverse incentive? not sure, but it needs to be weighted in any decision). 3b. A mounting fee pressure, resulting in a true fee market where transactions compete to get into blocks, results in urgency to develop decentralized off-chain solutions. I'm afraid increasing the block size will kick this can down the road and let people (and the large Bitcoin companies) relax, until it's again time for a block chain increase, and then they'll rally Gavin again, never resulting in a smart, sustainable solution but eternal awkward discussions like this. 4. We haven't solved the problem of arbitrary data storage, and increasing the block size would compound that problem. More data storage more storage available for the same price - and up to 20x faster growth of the UTXO set, which is permanent (more externalization). More opportunity for pedonazis to insert double-plus ungood data, exposing users to possible legal ramifications. For: 1. First, the obvious: It gives some breathing room in a year (or whenever the hard fork is planned). If necessary, it will allow more transactions to be on-chain for a while longer while other solutions are being implemented. 2. *Allowing* 20MB blocks does not mean miners will immediately start making them. Many of them aren't even filling up to the 1MB limit right now, probably due to latency/stale block issues. This makes objection 2 milder, which is about *worst case* bandwidth, as well as 4, as the end result may not be 20MB blocks filled with arbitrary junk. 3. Investment in off-chain solutions
[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