[Bitcoin-development] Blocksize and off-chain transactions

[Bitcoin-development] Blocksize and off-chain transactions

[Gavin Andresen]

> 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 either/or mentality.

OF COURSE we're going to raise the block size limit. Limiting the main
blockchain to single-digit transactions-per-second is not an option,
the vision FOREVER has been to scale it up.

And OF COURSE there will be off-chain transactions-- at the very
least, we need them for "instantly confirmed" transactions.

But lets table that whole discussion until 0.8.1 is out the door.

-- 
--
Gavin Andresen

Re: [Bitcoin-development] Blocksize and off-chain transactions

[Peter Todd]

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

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 either/or mentality.

You said it best yourself:

10:48 < gavinandresen> Luke-Jr: argument for another day, but I can
almost guarantee that the blocksize limit will be raised in less than 2
years, just based on pressure from the big businesses using the chain
(and no, NOT satoshidice)

Decentralization offers big businesses nothing; they're a regulation
target already by virtue of size alone.

> OF COURSE we're going to raise the block size limit. Limiting the main
> blockchain to single-digit transactions-per-second is not an option,
> the vision FOREVER has been to scale it up.
> 
> And OF COURSE there will be off-chain transactions-- at the very
> least, we need them for "instantly confirmed" transactions.
> 
> But lets table that whole discussion until 0.8.1 is out the door.
> 
> -- 
> --
> Gavin Andresen
> 

-- 
'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] Blocksize and off-chain transactions

[Michael Gronager]

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 a setup for "considerate mining":
* Run pools either on newest or second newest version (up to you depending on which features you like as a pool admin) - say e.g. 0.8
* Connect to the rest of the bitcoin network _only_ through a node of the other version - say e.g. 0.7

This guarantees that no blocks will get into the network that will not be accepted by both 0.8 and 0.7. Those two  versions together should add up to say >90%.

Once everyone else (90%) have upgraded to the newest, (0.8), drop the 0.7 and start to introduce 0.9 instead.

/M

Re: [Bitcoin-development] Blocksize and off-chain transactions

[Luke-Jr]

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.

Re: [Bitcoin-development] Blocksize and off-chain transactions

[Pieter Wuille]

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 a similar situations in the future.

The current behaviour in 0.7 and before is indeed broken, and we cannot afford to keep
that as an implicitly-defined rule on the network. I fully agree with that, but it will
require a hardfork.

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 implemented in your client are outdated." - that
is not how Bitcoin works: the network defines the rules.

IMHO, the way to go is first get a 0.8.1 out that mimics the old behaviour - just as a
stopgap solution. That will allow miners to safely use 0.8-based code at least. We can
also get patches for 0.7 and previous branches that fix the lock limit issue, but enforce
the same limit as 0.8.1 does, simply as band-aid for those who do not yet wish to upgrade
to 0.8.

Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. This is something
that requires widespread community consensus - far more than just miners and developers -
but as this is about fixing a bug that would otherwise prevent most evolution, I hope it
can be a very non-controversial one. To that end, I would prefer to limit this hard fork
to only direct bug fixes, and leave the block limit issue for later. By now, I think it
is clear that a hard fork will be inevitable, and by doing one, I think we can learn a
lot that can make later ones easier.

-- 
Pieter

Re: [Bitcoin-development] Blocksize and off-chain transactions

[Roy Badami]

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 network that
has a mix of 0.8.1 nodes (which will reject the block) and 0.7 nodes
(which will hang when receiving the block?) would appear to remove the
fork risk.  Is it obvious that no other serious problems remain in
such a network?

(Although I note your proposal to patch 0.7 too, so hopefully the
network wouldn't remain in that state for very long)

roy

Re: [Bitcoin-development] Blocksize and off-chain transactions

[Stephen Pair]

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

On Wed, Mar 13, 2013 at 2:28 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:

> 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 implemented in your client are
> outdated." - that
> is not how Bitcoin works: the network defines the rules.
> ...
> Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. This
> is something
> that requires widespread community consensus - far more than just miners
> and developers


The way I've started thinking about it is that there is a market for
securing a payment network.  In that market you have consumers (users of
bitcoin) and providers (miners).  It's not clear to me that if the
overwhelming majority of miners stayed on 0.8 that the 0.7 fork wouldn't
have still won out in the long run because effectively what you would have
had is a situation where the providers abandon a large portion of their
customers (0.7 users) and start providing a service that is in much less
demand.  Would everyone have upgraded to 0.8?  Maybe, but maybe not.  Maybe
many people would have made the rational decision to stay on earlier
versions and the small minority of miners that choose to service the 0.7
fork could have earned more Bitcoin on that fork...and maybe in the long
run, the majority of miners on 0.8 would realize this situation and start
to trickle back over to the 0.7 fork.  The flip side of the equation is
that the users have a pretty compelling reasons to use the services of the
most secure network (less risk of double spends).  So, the users very well
could have made the rational decision to consume the services of the most
powerful network and made the switch to 0.8.

What happened in reality is that the majority of the mining community made
the rational decision to service the largest pool of customers (0.8 as well
as 0.7 and earlier users).  It was rational because the risk of servicing
only the 0.8 users would have been much greater.

Because of this dynamic, I doubt there would ever be multiple forks of any
consequence in permanent coexistence.  I would even go so far as to say
that at this point, a successful competitor to Bitcoin would have to arise
as a fork of the UTXOs in the block chain (even if the competitor didn't
even use a block chain).  That competitor might even have to begin life in
lock step co-existence with Bitcoin, recognizing all Bitcoin transactions
for some period of time while it attempts to gain market share.

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

Re: [Bitcoin-development] Blocksize and off-chain transactions

[Michael Gronager]

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 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 implemented in your client are outdated." - that
> is not how Bitcoin works: the network defines the rules.

Consensus was rapidly reached a day ago: To ensure the majority (all of?) the network could accept the blocks mined, and not just 0.8. This was the right decision! Too many was dependent on <=0.7

So, the question is not if, but when to do a hardfork. We need to define and monitor the % of nodes running different versions (preferably a weighted average - some nodes, like e.g. blockchain.info & mtgox serve many...). Once there was the rowit bitcoinstatus page - do we have another resource for this ?

Then the second question is how to ensure we don't create a fork again? Pieter (and others?) are of the opinion that we should mimic a 0.7 lock-object-starvation-reject-rule. I don't like this for three reasons:
1. I find it hard to ensure we have actually coined the bug precisely
2. I expect that similar issues will happen again
3. The current issue was between two versions, but in the future it could be between two implementations - then trying implement or even to coordinate strange rules becomes very unlikely.

Hence the scheme for "considerate mining" - it is the only scheme that guarantees 100% that no block are released that will not be accepted by a supermajority of the install base.

Another nice thing about it - it requires no development :)

So simply run in serial in front of all considerate miners nodes of different versions until a certain threshold of the install base is reached.

/M