On Wed, Mar 13, 2013 at 01:01:43PM -0400, Gavin Andresen wrote:
The very statement that we're willing to increase the blocksize as our
solution to increased transaction volume rather go down the path of
off-chain transactions is incredibly controversial.
I really don't understand this
Please note that it was not 0.8 that had issues, but 0.7(and downwards).
I really think changing features in 0.8 aiming for a fluffy limit to avoid lock
object errors on 0.7 is the wrong way to go, and it will never cover for a
similar situations in the future.
Instead I would like to propose
On Wednesday, March 13, 2013 6:01:02 PM Michael Gronager wrote:
Please note that it was not 0.8 that had issues, but 0.7(and downwards).
While 0.7 and earlier do have issues, they also define the Bitcoin protocol.
0.8's failure to comply with the protocol is an issue.
On Wed, Mar 13, 2013 at 07:01:02PM +0100, Michael Gronager wrote:
Please note that it was not 0.8 that had issues, but 0.7(and downwards).
I really think changing features in 0.8 aiming for a fluffy limit to avoid
lock object errors on 0.7 is the wrong way to go, and it will never cover for
On Wed, Mar 13, 2013 at 07:28:06PM +0100, Pieter Wuille wrote:
IMHO, the way to go is first get a 0.8.1 out that mimics the old
behaviour - just as a stopgap solution.
Presumably not emulate too precisely, at least if your initial report
that the block caused 0.7 to 'get stuck' was correct. A
On Wed, Mar 13, 2013 at 2:28 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
But we cannot just drop support for old nodes. It is completely
unreasonable to put the
_majority_ of the network on a fork, without even as much as a discussion
about it.
Oh, you didn't get the memo? The rules
I hear consensus that at some point we need a hardfork (== creating blocks that
will not be accepted by 0.7 clients).
Miners generate block, hence they are the ones who should filter themselves
though some consensus.
But we cannot just drop support for old nodes. It is completely
7 matches
Mail list logo
