On Fri, Mar 15, 2013 at 10:06 AM, Benjamin Lindner wrote:
> This. Software behavior which is not described by the source code should not
> be considered an integral part of the rule set.
> Any influence of external libraries on the consensus mechanism is
> unacceptable.
No one thinks its contro
On Friday, March 15, 2013 5:06:20 PM Benjamin Lindner wrote:
> On Mar 13, 2013, at 8:18 PM, Cameron Garnham wrote:
> > For me, everyone signed up to bitcoin thinking that there was a 1MB /
> > block limit. The lock limits were unexpected, and could be considered
> > extremely uncontroversial to r
On Mar 13, 2013, at 8:18 PM, Cameron Garnham wrote:
> For me, everyone signed up to bitcoin thinking that there was a 1MB /
> block limit. The lock limits were unexpected, and could be considered
> extremely uncontroversial to remove.
This. Software behavior which is not described by the source
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I think that the course of action is quite simple:
1. Upgrade all the clients to implement the lock limits. (in code,
not at the DB exception layer). A bit of research is needed to work
out exactly what these limits are so we can maximise the num
On Wed, Mar 13, 2013 at 02:27:01PM -0700, Gregory Maxwell wrote:
> On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami wrote:
> > The idea of the client detecting/warning about not-trivial forking
> > seems worthwhile too, though, assuming it doesn't already (AIUI it
> > doesn't).
>
> It does warn??? if
On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami wrote:
> The idea of the client detecting/warning about not-trivial forking
> seems worthwhile too, though, assuming it doesn't already (AIUI it
> doesn't).
It does warn— if its heard the fork and its on the lower difficulty
side. Extending that to also
On Wed, Mar 13, 2013 at 09:14:03PM +, Luke-Jr wrote:
> On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote:
> > On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
> > > Here's a simple proposal to start discussion from...
> >
> > It seems to me that the biggest failure was not the develop
On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote:
> On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
> > Here's a simple proposal to start discussion from...
>
> It seems to me that the biggest failure was not the development of two
> chains, but the assurance to users (by the client) th
On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
> Here's a simple proposal to start discussion from...
It seems to me that the biggest failure was not the development of two
chains, but the assurance to users (by the client) that their transactions
were confirmed.
Is it possible to change the
On Wed, Mar 13, 2013 at 1:10 PM, Matthew Mitchell
wrote:
> Why would it be a difficulty in getting people to update away from 0.7 and
> earlier? How long would that roughly take? If people are hesitant to update,
> imagine if a more serious vulnerability is found. It could be disastrous.
The de
On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote:
> Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules
> which all verifying implementations must adhere to. I'm suggesting that we
> instead change the old codebase to do what we expected it to do all along
> (what 0
On Wed, Mar 13, 2013 at 11:27 AM, Mark Friedenbach wrote:
> This may be a semantic issue. I meant that it's not a hard-fork of the
> bitcoin protocol, which I'm taking to mean the way in which we all
> *expected* every version of the Satoshi client to behave: the rules which we
In our common lang
Agree. I quite like Mark's proposal. Yes, formally it is hard fork. But the
step 4) can come very far in the future, when the penetration of <0.8
clients will be mininimal.
slush
On Wed, Mar 13, 2013 at 7:27 PM, Mark Friedenbach wrote:
> This problem is very clearly a *bug* in the old codebase.
On Wed, Mar 13, 2013 at 11:27:13AM -0700, Mark Friedenbach wrote:
> I know there's people here who will jump in saying that the bitcoin
> protocol is the behavior of the Satoshi client, period. But which Satoshi
> client? 0.7 or 0.8?
The protocol is whatever the network enforces - and that is some
This may be a semantic issue. I meant that it's not a hard-fork of the
bitcoin protocol, which I'm taking to mean the way in which we all
*expected* every version of the Satoshi client to behave: the rules which
we have documented informally on the wiki, this mailing list, and in code
comments, etc
On Wednesday, March 13, 2013 5:41:29 PM you wrote:
> I'm not sure I understand the need for hard forks. We can get through this
> crisis by mining pool collusion to prevent forking blocks until there is
> widespread adoption of patched clients.
Anything requiring widespread adoption of patched cli
On Wed, Mar 13, 2013 at 10:41:29AM -0700, Mark Friedenbach wrote:
> 4) At some point in the future once we've crossed an acceptable adoption
> threshold, the miners remove the above patch in a coordinated way.
>
> Does that not get us past this crisis without a hard-fork?
This is a hardfork: it m
I'm not sure I understand the need for hard forks. We can get through this
crisis by mining pool collusion to prevent forking blocks until there is
widespread adoption of patched clients.
Proposal:
1) Patch the pre-0.8 branches to support an increased lock count, whatever
number is required to ma
On Wed, Mar 13, 2013 at 03:26:14PM +, Luke-Jr wrote:
> On Wednesday, March 13, 2013 3:18:36 PM Gregory Maxwell wrote:
> > On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd wrote:
> > > If we're going to consider doing this, at minimum we need to also
> >
> > I beg people to not derail discussion ab
On Wednesday, March 13, 2013 3:18:36 PM Gregory Maxwell wrote:
> On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd wrote:
> > If we're going to consider doing this, at minimum we need to also
>
> I beg people to not derail discussion about fixing things with
> discussion of other controversial changes.
On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd wrote:
> If we're going to consider doing this, at minimum we need to also
I beg people to not derail discussion about fixing things with
discussion of other controversial changes.
Luke-jr, any chance in getting you to revise your proposal to narrow
th
On Wed, Mar 13, 2013 at 12:56:29PM +, Luke-Jr wrote:
> Here's a simple proposal to start discussion from...
>
> BEFORE block 262144:
> - Never make a block that, combined with the previous 4 blocks, results in
> over 4500 transaction modifications.
> - Reject any block that includes more than
On Wed, Mar 13, 2013 at 5:56 AM, Luke-Jr wrote:
> FROM block 262144 to block 393216 (hard fork #1):
> - Never make, and reject any block that includes more than 24391 transaction
> modifications on its own (this *should* be equivalent to 1 MB)
> - (this rules can make older client backports safe u
23 matches
Mail list logo
