[Bitcoin-development] (no subject)

[Bitcoin-development] (no subject)

[Zooko Wilcox-OHearn]

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

Re: [Bitcoin-development] (no subject)

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1164 bytes --]

[Bitcoin-development] Handling alerts & communication on bitcoin.org

[Saïvann]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1207 bytes --]

Re: [Bitcoin-development] (no subject)

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3034 bytes --]

Re: [Bitcoin-development] (no subject)

[Luke-Jr]

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

Re: [Bitcoin-development] (no subject)

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2189 bytes --]

[Bitcoin-development] (no subject)

[losewife]

[-- Attachment #1: Type: text/plain, Size: 47 bytes --]







losewife@gmail.com


losewife@gmail.com


[-- Attachment #2: Type: text/html, Size: 580 bytes --]