(no subject)

jgarzik wrote:

 > 1) Rule changes.  We don't want these.

In general? What constitutes a rule change?

For example, if I understand correctly (from what Gavin said at Bitcoin 2013), there is a move afoot to lift the block size limit. Although, when I went to confirm my understanding by reading the bitcoin-development list archives, I don't see mention of this. Is there another forum I should be reading if I want to follow Bitcoin development?

Anyway, I hope that there are some rule changes that you would consider for Bitcoin, although I recognize there are vast classes of such changes that you wouldn't.

I'm trying to figure out what's the most productive way to show you, and everyone, candidates for such changes. Things that are definitely not suitable for merging to trunk tomorrow, but might be suitable in a year or two, or "Next Time We Have A Hardfork".

I don't think alternative bitcoin-clones are the best venue for those. Although they are certainly good venues for changes which can never make it into Bitcoin.

Perhaps the best venue for such a thing is just to fork bitcoin.git on github.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com

On Sat, May 25, 2013 at 7:46 AM, Zooko Wilcox-OHearn < zooko@leastauthority•com> wrote:

> jgarzik wrote:
>  > 1) Rule changes.  We don't want these.
>
> In general? What constitutes a rule change?
>

I'm sure he means rule changes with economical impact, such as miner block reward, total number of bitcoins, block speed. Mostly non-interesting from a technical view point, but the only changes most altcoins seem to be making... In any case, these are set in stone and cannot ever be changed for bitcoin or all hell will break loose.

See also https://en.bitcoin.it/wiki/Hardfork_Wishlist.

Wladimir

On 25 May 2013 07:46, Zooko Wilcox-OHearn <zooko@leastauthority•com> wrote:

> jgarzik wrote:
>  > 1) Rule changes.  We don't want these.
>
> In general? What constitutes a rule change?
>
> For example, if I understand correctly (from what Gavin said at
> Bitcoin 2013), there is a move afoot to lift the block size limit.
> Although, when I went to confirm my understanding by reading the
> bitcoin-development list archives, I don't see mention of this. Is
> there another forum I should be reading if I want to follow Bitcoin
> development?
>
> Anyway, I hope that there are some rule changes that you would
> consider for Bitcoin, although I recognize there are vast classes of
> such changes that you wouldn't.
>
> I'm trying to figure out what's the most productive way to show you,
> and everyone, candidates for such changes. Things that are definitely
> not suitable for merging to trunk tomorrow, but might be suitable in a
> year or two, or "Next Time We Have A Hardfork".
>
> I don't think alternative bitcoin-clones are the best venue for those.
> Although they are certainly good venues for changes which can never
> make it into Bitcoin.
>
> Perhaps the best venue for such a thing is just to fork bitcoin.git on
> github.
>

It might be an idea to have 'rule change' fixes and 'bug fix' releases go out separately

>
> Regards,
>
> Zooko Wilcox-O'Hearn
>
> Founder, CEO, and Customer Support Rep
>
> https://LeastAuthority.com
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote:

> It might be an idea to have 'rule change' fixes and 'bug fix' releases go
> out separately

Bitcoin is a consensus system. You can't run clients with different rules on the same blockchain/network - it just won't work! Maybe we're now talking about mere client default policies? In which case, you should be able to configure previous behaviour...

If you want just bug fixes and rule changes, without policy default changes, new features, etc, you can use the 0.4.x - 0.7.x backports. But be advised these are short-term solutions and won't be maintained forever - so you really should try to get the behaviour you want from the current release. If you can't for some reason, please do report a bug explaining what it is the older version was capable of that the new one isn't!

Luke

On 25 May 2013 10:53, Luke-Jr <luke@dashjr•org> wrote:

> On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote:
> > It might be an idea to have 'rule change' fixes and 'bug fix' releases go
> > out separately
>
> Bitcoin is a consensus system. You can't run clients with different rules
> on
> the same blockchain/network - it just won't work! Maybe we're now talking
> about mere client default policies? In which case, you should be able to
> configure previous behaviour...
>

[[ Not wishing to stray too far off topic ]]

I think you are perhaps underestimating the effect of 'mere' default policies.

It would be nice to think that every node was a free thinking individual that is motivated to vote with their feet, but in practice most people dont have time.

There is research showing that 80% of users tend to accept defaults.

Rule changes and changing defaults would seem to be things worth weighing. Bug fixes hopefully should be fairly unanimous. Of course a grey area exists in between.

>
> If you want just bug fixes and rule changes, without policy default
> changes,
> new features, etc, you can use the 0.4.x - 0.7.x backports. But be advised
> these are short-term solutions and won't be maintained forever - so you
> really
> should try to get the behaviour you want from the current release. If you
> can't for some reason, please do report a bug explaining what it is the
> older
> version was capable of that the new one isn't!
>
> Luke
>

Hi,

There is currently 5 alerts pages on bitcoin.org concerning past network events (vulnerabilities, hard fork, etc.). Those don't have any visibility and cannot be listed or followed easily.

I've created a setup to improve this and allow developers to easily communicate about any kind of network event worth mentionning. Code, screenshot, live demo, instructions and details are in the pull request : https://github.com/bitcoin/bitcoin.org/pull/194

Any comment is welcome. And since it is ultimately a tool for developers, only you can define if it makes sense to merge it. Or if you would like it to be done differently.

Best,

Saïvann