public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] (no subject)
@ 2014-05-04  1:47 losewife
  0 siblings, 0 replies; 6+ messages in thread
From: losewife @ 2014-05-04  1:47 UTC (permalink / raw)
  To: bitcoin-development

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







losewife@gmail•com


losewife@gmail•com


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] (no subject)
  2013-05-25  8:53   ` Luke-Jr
@ 2013-05-25  9:23     ` Melvin Carvalho
  0 siblings, 0 replies; 6+ messages in thread
From: Melvin Carvalho @ 2013-05-25  9:23 UTC (permalink / raw)
  To: Luke-Jr; +Cc: Bitcoin Dev

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] (no subject)
  2013-05-25  8:25 ` Melvin Carvalho
@ 2013-05-25  8:53   ` Luke-Jr
  2013-05-25  9:23     ` Melvin Carvalho
  0 siblings, 1 reply; 6+ messages in thread
From: Luke-Jr @ 2013-05-25  8:53 UTC (permalink / raw)
  To: 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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] (no subject)
  2013-05-25  5:46 Zooko Wilcox-OHearn
  2013-05-25  8:09 ` Wladimir
@ 2013-05-25  8:25 ` Melvin Carvalho
  2013-05-25  8:53   ` Luke-Jr
  1 sibling, 1 reply; 6+ messages in thread
From: Melvin Carvalho @ 2013-05-25  8:25 UTC (permalink / raw)
  To: Zooko Wilcox-OHearn; +Cc: Bitcoin Dev

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] (no subject)
  2013-05-25  5:46 Zooko Wilcox-OHearn
@ 2013-05-25  8:09 ` Wladimir
  2013-05-25  8:25 ` Melvin Carvalho
  1 sibling, 0 replies; 6+ messages in thread
From: Wladimir @ 2013-05-25  8:09 UTC (permalink / raw)
  To: Zooko Wilcox-OHearn; +Cc: Bitcoin Dev

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bitcoin-development] (no subject)
@ 2013-05-25  5:46 Zooko Wilcox-OHearn
  2013-05-25  8:09 ` Wladimir
  2013-05-25  8:25 ` Melvin Carvalho
  0 siblings, 2 replies; 6+ messages in thread
From: Zooko Wilcox-OHearn @ 2013-05-25  5:46 UTC (permalink / raw)
  To: bitcoin-development

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-05-04  1:49 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-04  1:47 [Bitcoin-development] (no subject) losewife
  -- strict thread matches above, loose matches on Subject: below --
2013-05-25  5:46 Zooko Wilcox-OHearn
2013-05-25  8:09 ` Wladimir
2013-05-25  8:25 ` Melvin Carvalho
2013-05-25  8:53   ` Luke-Jr
2013-05-25  9:23     ` Melvin Carvalho

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox