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

2015-06-19 Thread Bryan Bishop
On Fri, Jun 19, 2015 at 5:45 AM, Dr Adam Back wrote: payment protocol layer in my view. (If thats not obvious to some lurkers I elaborate on that argument amongst other things here: ) Someone might find it more convenient to

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 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 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 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 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 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

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 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 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 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] side-chains 2-way pegging (Re: is there a way to do bitcoin-staging?)

2014-10-22 Thread Bryan Bishop
On Wed, Oct 22, 2014 at 5:01 PM, Daniel Murrell wrote: p.s. I'm not trying to monetize this site. I just tried to make something I thought could be useful. [Unsolicited administrivia follows.] You have been posting this in a bunch of places for a while now, at least three

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 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 wrote: As a first step, one possibility is putting the primary repo on somewhere, and simply mirroring that to github for each push. Smaller first step would be to mirror the git repository on, which is