Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Bryan Bishop
On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn m...@plan99.net wrote: Dude, calm down. Well hold on, his concerns are real and he seems perfectly calm to me and others apparently. and Gavin already said long ago he wouldn't just commit something, even though he has the ability to do so.

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

2015-05-27 Thread Bryan Bishop
On Wed, May 27, 2015 at 9:16 PM, Andrew onelinepr...@gmail.com wrote: You should also keep in mind the big picture when it comes to decentralization. If the hard drives (or tapes) can only be produced by a small number of large companies like Western Digital or Seagate, then you can't really

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-08 Thread Bryan Bishop
On Fri, May 8, 2015 at 2:20 AM, Matt Whitlock b...@mattwhitlock.name wrote: - Perhaps the hard block size limit should be a function of the actual block sizes over some trailing sampling period. For example, take the median block size among the most recent 2016 blocks and multiply it by

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Bryan Bishop
On Thu, May 7, 2015 at 9:05 AM, Mike Hearn m...@plan99.net wrote: Maybe you dislike that idea. It's so centralised. So let's say Gavin commits his patch, because his authority is equal to all other committers. Someone else rolls it back. Gavin sets up a cron job to keep committing the

Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Bryan Bishop
On Wed, May 6, 2015 at 5:12 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Well, there has been significant public discussion in #bitcoin-wizards on irc.freenode.net

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-12 Thread Bryan Bishop
On Wed, Mar 11, 2015 at 11:09 PM, Gregory Maxwell gmaxw...@gmail.com wrote: For an emergency transition the user is probably better off with an explicit unstructured mass private key export, and a sweep function; and guaranteeing compatibility with that is much easier; and because it moves

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Bryan Bishop
On Sun, Feb 22, 2015 at 8:11 AM, Adam Back a...@cypherspace.org wrote: away from that too) is how about we explore ways to improve practical security of fast confirmation transactions, and if we find something better, then we can help people migrate to that before deprecating the current

Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-14 Thread Bryan Bishop
On Sat, Feb 14, 2015 at 1:04 PM, Adam Back a...@cypherspace.org wrote: That its highly complex to maintain strict consensus between bitcoin versions, does not justify consensus rewrite experiments Correct. However, those maintenance costs absolutely do justify working towards formal proofs of

Re: [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets

2014-09-25 Thread Bryan Bishop
On Thu, Sep 25, 2014 at 8:53 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I've pinged some people privately but also pinging the list… no commentary on this proposal? One possible reason is that non-subscribed users aren't able to access the file through sourceforge. The attachment through

Re: [Bitcoin-development] Reconsidering github

2014-08-19 Thread Bryan Bishop
On Tue, Aug 19, 2014 at 7:02 AM, Jeff Garzik jgar...@bitpay.com wrote: As a first step, one possibility is putting the primary repo on bitcoin.org somewhere, and simply mirroring that to github for each push. Smaller first step would be to mirror the git repository on bitcoin.org, which is