[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
On Wed, Oct 15, 2014 at 8:29 AM, Wladimir laa...@gmail.com wrote: 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. 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. 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. -- 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] BIP process
RE: process: I like author == primary control, and an assume they will do the right thing, revert if they don't RE: separate mailing list for BIP discussion: Great idea. Jeff Garzik was looking for a better mailing list solution than SourceForge, but assuming there isn't a clearly better solution I think we should create a strictly moderated bitcoin-bips@lists.sourceforge list. -- -- Gavin Andresen -- 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
Great idea. Jeff Garzik was looking for a better mailing list solution than SourceForge, but assuming there isn't a clearly better solution I think we should create a strictly moderated bitcoin-bips@lists.sourceforge list. Let's stay away from SF.net or any mailman-controlled lists if at all possible. They break DKIM signatures which means they're no longer compatible with Yahoo, all mail from Yahoo users gets spamfoldered immediately. Google Groups gets this right. Perhaps other list operators do too. Groups also has moderation features. -- 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
please not google groups *, I'd vote for sourceforge or other simple open list software over google groups. Adam * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that your address is associated with a gmail account. Quite frustrating. On 15 October 2014 16:46, Mike Hearn m...@plan99.net wrote: Great idea. Jeff Garzik was looking for a better mailing list solution than SourceForge, but assuming there isn't a clearly better solution I think we should create a strictly moderated bitcoin-bips@lists.sourceforge list. Let's stay away from SF.net or any mailman-controlled lists if at all possible. They break DKIM signatures which means they're no longer compatible with Yahoo, all mail from Yahoo users gets spamfoldered immediately. Google Groups gets this right. Perhaps other list operators do too. Groups also has moderation features. -- 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 -- 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
On Wed, Oct 15, 2014 at 04:54:57PM +0100, Adam Back wrote: please not google groups *, I'd vote for sourceforge or other simple open list software over google groups. Adam * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that your address is associated with a gmail account. Quite frustrating. I'll second that request. Something mailman based; don't particularly care where it's hosted. After all, one of the big advantages of open mailing lists is that multiple third-parties can easily provide archives, for instance www.mail-archive.com -- 'peter'[:-1]@petertodd.org 0a91d3bbf16d2b80e142f98e6ff45b615f668dba558a4413 signature.asc Description: Digital signature -- 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
I don't care much what exact list software/service is used, but lists.sf.net hasn't changed in years and is basically dying. Trashing all @yahoo accounts because ancient mailman does a MITM attack on people's email is no good, it's not any better than a web proxy that breaks every SSL connection. For a project that is based on digital signatures, it's really bad that the mailing list is incompatible with Yahoo's mail signatures must be valid policy. Plus its moderation features suck, its mail archiving features suck, etc. It essentially has no redeeming features at all. mail-archive.com can be easily used with any mailing list, so not sure why that's brought up. You just add it as a member, as documented here: http://www.mail-archive.com/faq.html#newlist -- 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
On Wed, Oct 15, 2014 at 4:54 PM, Adam Back a...@cypherspace.org wrote: please not google groups *, I'd vote for sourceforge or other simple open list software over google groups. Please not sourceforge. * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that your address is associated with a gmail account. Quite frustrating. Mailman is good enough... -- 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
Sounds like this is what you're after, it's a fairly new feature: https://github.com/blog/1375%0A-task-lists-in-gfm-issues-pulls-comments I've been meaning to use it in a PR to try it out. Cory On Wed, Oct 15, 2014 at 5:36 AM, Wladimir laa...@gmail.com wrote: 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 -- 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
On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote: * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that your address is associated with a gmail account. Quite frustrating. Mailman is good enough... I used these guys for awhile to host a small mailman list with absolutely no issues. Just $5/month for 1000 subscribers. https://www.mailmanlist.net/ -- 'peter'[:-1]@petertodd.org 19e75ca8667f175b61a41ad950d15b61d83d3faf1a128f94 signature.asc Description: Digital signature -- 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
On 10/15/14 08:47, Wladimir wrote: 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) ACK. - 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 -- 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
On Wednesday, October 15, 2014 8:47:18 AM Wladimir wrote: 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) ACK - BIP 21 (URI Scheme) ACK - BIP 22 (getblocktemplate - Fundamentals) ACK - BIP 31 (Pong Message) ACK - BIP 34 (Block v2, Height in coinbase) ACK - BIP 35 (mempool message) ACK - BIP 37 (Bloom filtering) Let me know if you (don't) agree. Shouldn't we be doing this in a GitHub PR rather than spamming up the ML? Luke -- 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
On Wednesday, October 15, 2014 7:40:04 PM Peter Todd wrote: On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote: * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that your address is associated with a gmail account. Quite frustrating. Mailman is good enough... I used these guys for awhile to host a small mailman list with absolutely no issues. Just $5/month for 1000 subscribers. https://www.mailmanlist.net/ I've been using http://lists.nongnu.org/ for BFGMiner announce/dev mailing lists for a while. I don't know what software it runs, but it works. Catch is that we'd need to go through Savannah's free software auditing. That might be a good idea anyway? Luke -- 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
Hi all, I've also been spending a few months coding upon the change's Pieter has been making with the headersfirst8 pull request. My code updates are also ready to test, and are available on github at https://github.com/rebroad/bitcoin/ and the branch is sipa-headersfirst8-patches. I've made a number of improvement. Namely that it tracks the block as it downloads and won't disconnect if the block is downloading at a reasonable speed. The current stall logic of Pieter's is broken in that it will continue to disconnect a peer that is providing a block - particularly the next block needed to advance the current tip. I've raised this issue, but so far haven't been able to communicate the problem in a way that's been understood. I've also added logic to avoid the node stalling due to many blocks being added to the ActiveTip (which would cause timeouts both from our node, and nodes we are connected to). It will also log and determine bandwidth per node, and the next changes I will be adding will be to make it prefer to download from the faster nodes (coming shortly). I have also added code ready to adapt the window size for the download. Currently the start setting for blocks in flight is 3 per node, but for early on on the block chain this will be too small, so once it realises this after a few downloads and determines the average block size and speed, it will automatically adjust the number of blocks to request per node and revise this each minute. Please do take a look at my code, and feel free to test it. It also improves some of the debug.log output to make it easier to read and provide useful information about concurrent downloads, etc. Edmund On Sun, Oct 12, 2014 at 7:34 AM, Pieter Wuille pieter.wui...@gmail.com wrote: Hi all, I believe that a large change that I've been working on for Bitcoin Core is ready for review and testing: headers-first synchronization. In short, it changes the way the best chain is discovered, downloaded and verified, with several advantages: * Parallel block downloading (much faster sync on typical network connections). * No more stalled downloads. * Much more robust against unresponsive or slow peers. * Removes a class of DoS attacks related to peers feeding you low-difficulty valid large blocks on a side branch. * Reduces the need for checkpoints in the code. * No orphan blocks stored in memory anymore (reducing memory usage during sync). * A major step step towards an SPV mode using the reference codebase. Historically, this mode of operation has been known for years (Greg Maxwell wrote up a description of a very similar method in https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync in early 2012, but it was known before that), but it took a long time to refactor these code enough to support it. Technically, it works by replacing the single-peer blocks download by a single-peer headers download (which typically takes seconds/minutes) and verification, and simultaneously fetching blocks along the best known headers chain from all peers that are known to have the relevant blocks. Downloading is constrained to a moving window to avoid unbounded unordering of blocks on disk (which would interfere with pruning later). At the protocol level, it increases the minimally supported version for peers to 31800 (corresponding to bitcoin v3.18, released in december 2010), as earlier versions did not support the getheaders P2P message. So, the code is available as a github pull request (https://github.com/bitcoin/bitcoin/pull/4468), or packaged on http://bitcoin.sipa.be/builds/headersfirst, where you can also find binaries to test with. Known issues: * At the very start of the sync, especially before all headers are processed, downloading is very slow due to a limited number of blocks that are requested per peer simultaneously. The policies around this will need some experimentation can certainly be improved. * Blocks will be stored on disk out of order (in the order they are received, really), which makes it incompatible with some tools or other programs. Reindexing using earlier versions will also not work anymore as a result of this. * The block index database will now hold headers for which no block is stored on disk, which earlier versions won't support. If you are fully synced, it may still be possible to go back to an earlier version. Unknown issues: * Who knows, maybe it will replace your familiy pictures with Nyan Cat? Use at your own risk. TL;DR: Review/test https://github.com/bitcoin/bitcoin/pull/4468 or http://bitcoin.sipa.be/builds/headersfirst. -- Pieter -- 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
