Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

[Richard Moore]

Awesome graph!

It would be interesting if you could use your Excel voodoo (or whatever graph 
app you use) to add density as a heat map, making areas with more blocks red 
and regions with less blocks blue…


> On Jun 1, 2015, at 8:42 PM, Tom Harding  wrote:
> 
> On 6/1/2015 10:21 AM, Adam Back wrote:
>> if it stays as is for a year, in a wait and see, reduce spam, see
>> fee-pressure take effect as it has before, work on improving improve
>> decentralisation metrics, relay latency, and do a blocksize increment
>> to kick the can if-and-when it becomes necessary and in the mean-time
>> try to do something more long-term ambitious about scale rather than
>> volume.
> 
> What's your estimate of the lead time required to kick the can,
> if-and-when it becomes necessary?
> 
> The other time-series I've seen all plot an average block size.  That's
> misleading, because there's a distribution of block sizes.  If you bin
> by retarget interval and plot every single block, you get this
> 
> http://i.imgur.com/5Gfh9CW.png
> 
> The max block size has clearly been in play for 8 months already.
> 
> 
> 
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>

Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ric...@geneticmistakes.com 
www: http://GeneticMistakes.com 
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

[Tom Harding]

On 6/1/2015 10:21 AM, Adam Back wrote:
> if it stays as is for a year, in a wait and see, reduce spam, see
> fee-pressure take effect as it has before, work on improving improve
> decentralisation metrics, relay latency, and do a blocksize increment
> to kick the can if-and-when it becomes necessary and in the mean-time
> try to do something more long-term ambitious about scale rather than
> volume.

What's your estimate of the lead time required to kick the can,
if-and-when it becomes necessary?

The other time-series I've seen all plot an average block size.  That's
misleading, because there's a distribution of block sizes.  If you bin
by retarget interval and plot every single block, you get this

http://i.imgur.com/5Gfh9CW.png

The max block size has clearly been in play for 8 months already.



--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

[Mike Hearn]

>
> (at reduced security if it has software that doesnt understand it)


Well, yes. Isn't that rather key to the issue?  Whereas by simply
increasing the block size, SPV wallets don't care (same security and
protocol as before) and fully validating wallets can be updated with a very
small code change.


> A 1MB client wont even understand the difference between a 1MB and 8MB
> out payment.


Let's say an old client makes a payment that only gets confirmed in an
extension block. The wallet will think the payment is unconfirmed and show
that to the user forever, no?

Can you walk through the UX for each case?


> If I am not misremembering, I think you've sided typically
> with the huge block, big data center only end of the spectrum.


It would be Satoshi, that argued that.

I think there must be a communication issue here somewhere. I'm not sure
how this meme has taken hold amongst you guys, as I am the guy who wrote
the scalability page back in 2011:

https://en.bitcoin.it/wiki/Scalability

It says:

*The core Bitcoin network can scale to much higher transaction rates than
are seen today, assuming that nodes in the network are primarily running on
high end servers rather than desktops. *


By "much higher rates" I meant VISA scale and by "high end server" I meant
high end by today's standards not tomorrows. There's a big difference
between a datacenter and a single server! By definition a single server is
not a datacenter, although it would be conventional to place it in
one. But even
with the most wildly optimistic growth imaginable, I couldn't foresee a
time when you needed more than a single machine to keep up with the
transaction stream.

And we're not going to get to VISA scale any time soon: I don't think I've
ever argued we will. If it does happen it would presumably be decades away.
Again, short of some currently unimagined killer app.

So I don't believe I've ever argued this, and honestly I kinda feel people
are putting words in my mouth.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

[Adam Back]

Mike wrote:
>> Businesses who are keen to
>> have more transactions, would make it their problem to implement in
>> their wallet, or ask the wallet vendor/maintainer they're working with
>> to do it.  Nothing breaks if they dont use it.
>
>
> I don't see how this is the case. If an exchange supports extension blocks
> and I withdraw from that to a wallet that doesn't, the money will never
> arrive from my perspective. Yet the exchange will claim they sent it and
> they will wash their hands of the matter. Disaster.

To be clear in case you are missing part of the mechanism.: it is
forward and backwards compatible meaning a 1MB address can receive
payments from an 8MB address (at reduced security if it has software
that doesnt understand it) and a 1MB address can pay an 8MB address by
paying to an OP_TRUE that has meaning to the extension block nodes.

A 1MB client wont even understand the difference between a 1MB and 8MB
out payment.  An 8MB client will understand and pay 1MB addresses in a
different way (moving the coin back to the 1MB chain).

So its opt-in and incrementally deployable.  Exchanges could encourage
their users to use wallets that support 8MB blocks, eg by charging a
fee for 1MB transactions.  If 1MB blocks experience significant fee
pressure, this will be persuasive.  Or they could chose not to and eat
the cost.  This is all normal market adoption of a new cheaper
technical option (in this case with a tradeoff of reduced
security/more centralisation for those opting in to it).

>> Because the more complex one is safer, more flexible, more future
>> proof and better for decentralisation
>
> I disagree with all of those points. I find Lightning/Stroem etc to be more
> dangerous, less flexible, and worse for decentralisation. I explain why
> here:

Extension blocks & lightning are unrelated things.

While I understand the need for being practical, there is IMO, amongst
engineering maxims something as far as being too pragmatic,
dangerously pragmatic even.  We cant do stuff in bitcoin that has bad
carry costs, nor throw out the baby with the bathwater.

The situation is just that we are facing a security vs volume tradeoff
and different people will have different requirements and comfort
zones.  If I am not misremembering, I think you've sided typically
with the huge block, big data center only end of the spectrum.  What I
am proposing empowers you to do experiments in that direction without
getting into a requirements conflict with people who value more
strongly the bitcoin properties arising from it being robustly
decentralised.

I am not sure personally where the blocksize discussion comes out - if
it stays as is for a year, in a wait and see, reduce spam, see
fee-pressure take effect as it has before, work on improving improve
decentralisation metrics, relay latency, and do a blocksize increment
to kick the can if-and-when it becomes necessary and in the mean-time
try to do something more long-term ambitious about scale rather than
volume.  Bitcoin without scale improvements probably wont get the
volume people would like.  So scale is more important than volume; and
security (decentralisation) is important too.  To the extreme analogy
we could fix scale tomorrow by throwing up a single high perf
database, but then we'd break the security properties arising from
decentralisation.  We should improve both within an approximately safe
envelope IMO.

Adam

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

[Mike Hearn]

Hi Adam,

I have more experience than Gavin of building consumer wallets, so I'll
make an attempt to answer your questions.

> Then ask the various wallet developer how long it would take them to
> update
> > their software to support something like this,
>
> I don't think thats any particular concern


I am a wallet developer and I am telling you that it is.


> Businesses who are keen to
> have more transactions, would make it their problem to implement in
> their wallet, or ask the wallet vendor/maintainer they're working with
> to do it.  Nothing breaks if they dont use it.


I don't see how this is the case. If an exchange supports extension blocks
and I withdraw from that to a wallet that doesn't, the money will never
arrive from my perspective. Yet the exchange will claim they sent it and
they will wash their hands of the matter. Disaster.

I am not a UX guy
>

But I am. I've designed both consumer and engineering UI's at Google, and
also more recently for Lighthouse.

Attempting to explain to a user why they sent money that didn't show up on
the other end is a non starter. It's bad enough when things take a long
time to confirm or bugs cause propagation failures. Doing it
deliberately is not going to work. Payments *must* be reliable and wallets
*must* be compatible with each other.

This is one reason why a Lightning style approach also isn't going to work
any time soon. For example, it would require people to abandon Bitcoin
addresses. I pushed for that before, around the P2SH time, and Gavin
correctly intuited that the community wasn't ready for it yet. I'm not sure
much has changed.


> Because the more complex one is safer, more flexible, more future
> proof and better for decentralisation


I disagree with all of those points. I find Lightning/Stroem etc to be more
dangerous, less flexible, and worse for decentralisation. I explain why
here:

https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e

You mentioned decentralisation metrics. Gregory's post is ignoring one of
the most important decentralisation metrics, which is number of wallets
made by independent developers. That has got dramatically better over time.
It would get worse if wallets became more complex very suddenly.


> As an aside, a risk with using companies as a sounding board, is that
> you can get a misleading sense of consensus.


>From what I can tell Blockstream employees are just ignoring those
companies entirely, which will give you a radically more distorted view of
the consensus. As companies providing services to our community have
serious economic weight, it stands to reason that their opinions would
matter a great deal. Yet on this mailing list I see zero effort to even
recognise their concerns, let alone care about them.
  
Anyway, let me repeat again to make it clear - as someone who has spent
five years writing SPV wallets, I am not on board with extension blocks or
any other Rube Goldberg contraption that exists purely to work around
theoretical objections by Blockstream employees+Peter Todd, which is what
this feels like to me.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] soft-fork block size increase (extension blocks)

[Adam Back]

Hi Gavin

Sorry for slow response & broken threading - mailbox filled up & only
saw your response on archive.

I do earnestly think opt-in block-size increases are politically
cleaner (gives different people different sized blocks by their own
volition without forcing a compromise) and less risky than hard forks.
Particularly if a hard-fork were really provoked without clear and
wide consensus - dragons lay there.

> Then ask the various wallet developer how long it would take them to update
> their software to support something like this,

I don't think thats any particular concern, extension block payments
are forwards and backwards compatible.  Businesses who are keen to
have more transactions, would make it their problem to implement in
their wallet, or ask the wallet vendor/maintainer they're working with
to do it.  Nothing breaks if they dont use it.  The people that have
the need for it will work on it.  Market at work.  If it turns out
they dont really have a need for it, just projected huge numbers for
their business plan that say dont materialise, well no foul.

> and do some UI mockups of what the experience would look like for users.

I am not a UX guy, but for example it might be appropriate for tipping
services or other micropayments to use an extension block.  Or small
retail payments.  They can choose what address they use.  Merchants,
integrators etc can do likewise.
It gives plenty enough scope that people can work with useful
trade-offs while others work on lightning.

> If there are two engineering solutions to a problem, one really simple, and
> one complex, why would you pick the complex one?

Because the more complex one is safer, more flexible, more future
proof and better for decentralisation (and so as a bonus and might
actually get done without more months of argument as its less
contentious because it gives users choice to opt-in).  Bitcoin itself
is complex, a central ledger is simpler but as we know uninteresting
which is to say this is a security tradeoff.

Obviously I do appreciate KISS as a design principle, and utility of
incremental improvements, but this is a security trade-off we're
discussing here.  I am proposing a way to not weaken security, while
getting what you think is important - access to more TPS with a higher
centralisation tradeoff (for those who opt-in to it, rather than for
everyone whether that tradeoff is strongly against their interests or
not).

The decentralisation metrics are getting worse, not better, see Greg
Maxwell's comments
http://www.reddit.com/r/Bitcoin/comments/37vg8y/is_the_blockstream_company_the_reason_why_4_core/crqg381

This would not by those metrics be a good moment in history to make
the situation worse.

> Especially if the complex solution has all of the problems of the simple
> one (20MB extension blocks are just as "dangerous" as 20MB main blocks,
> yes? If not, why not?)

Not at all, thats the point.  Bitcoin has a one-size fits all
blocksize.  People can pool mine the 8MB extension block, while solo
or GBT mining the 1MB block.  Thats more centralising than staying at
1MB (because to get the fees from the extension block some people
without that kind of bandwidth are pool mining 8/9th of the lower
security/decentralisation transactions.  But its less centralising
than a fixed blocksize of 9MB (1+8 for apples/apples) because
realistically if those transactions are not spam, they would've
happened offchain, and offchain until we get lightning like systems
up, means central systems which are worse than the slight
centralisation of 8MB blocks being single servers and prone to custody
& security failure.  I think you made that point yourself in a recent
post also.

Sound good? ;)  Seriously I think its the least bad idea I've heard on
this topic.

As an aside, a risk with using companies as a sounding board, is that
you can get a misleading sense of consensus.  Did they understand the
tradeoff between security (decentralisation) and blocksize.  Did they
care?  Do they represent users interests?  Would they have "voted"
instead for extension blocks if it was presented in similar terms?  (I
have to imagine they might have preferred extension blocks given the
better story if you gloss over complexity and tradeoffs).

Adam

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

[Andrew]

Hello Adam

First of all, thank you for inventing hashcash, which is basically what
bitcoin is!

Some people have said that my proposal, subject line "Scaling Bitcoin with
Subchains" is essentially the idea of blockchain extensions. Though, I
think there is quite a difference between what I propose and what you
propose. You want to add one optional 10 MB blockchain that synchronizes
with the 1 MB blockchain, while I want to add ten 1 MB
 blockchains that each synchronize with the 1 MB chain (and you can
continue like that). I think, as long as we want to keep using blockchains
for our cryptocurrency, we will need a tree structure of blockchains in
order to scale for an arbitrary number of transactions. With just one 10 MB
blockchain, someone who wants to do the lower valued transactions will need
to validate all 10 MB, while with ten 1 MB chains, they can choose just the
chain or chains that are of interest to them. With a tree structure you get
O(a^(n-1)) MB of transactions in the network while each participant only
has to validate O(n) MB of transactions (a is just the number of children
chains per parent divided by 2, so 5 in the case of 10 children as I
described). With just one child chain, you don't get this scaling, and it
is pretty much equivalent to increasing the blocksize, though with a
soft-fork instead of a hard-fork.

I think the actual way that the blockchains interact can be still worked
out (Recently I was thinking of maybe creating a contract system or even a
decentralized market between chains). But still, everyone should agree that
you need this kind of tree structure. Even if you want to only run a pruned
node, the CPU usage and memory scales just as bad. The tree structure also
has good privacy and miner decentralization properties, as I can write
about later.

But another thing that I recommend is an "exit plan". What if we go with
some kind of soft fork and then in the future some better idea comes along?
Then we should have a way to reverse the soft fork. If people already have
coins tied up in sidechains, it can be problematic. So perhaps, in case
people want to later ditch the soft fork, nodes in the parent chain can
allow only old transactions inside the child chains to be accepted back up,
while new transactions are not recognized anymore. That way you can limit
the amount of useless transaction traffic that results in case we want
something else.

On Sat, May 30, 2015 at 1:36 AM, Raystonn  wrote:

> My fear now is too much unnecessary complexity.  More complex means
> brittle code, but also fewer programmers working on this, which is a risk.
>
> We shouldn't delay forever until every potential solution has been
> explored.  There's always going to be one more thing to explore.
>  On 29 May 2015 5:16 pm, Gavin Andresen  wrote:
>
> RE: soft-forking an "extension block":
>
> So... go for it, code it up. Implement it in the Bitcoin Core wallet.
>
> Then ask the various wallet developer how long it would take them to
> update their software to support something like this, and do some UI
> mockups of what the experience would look like for users.
>
> If there are two engineering solutions to a problem, one really simple,
> and one complex, why would you pick the complex one?
>
> Especially if the complex solution has all of the problems of the simple
> one (20MB extension blocks are just as "dangerous" as 20MB main blocks,
> yes? If not, why not?)
>
>
> --
> --
> Gavin Andresen
>
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

[Raystonn]

My fear now is too much unnecessary complexity.  More complex means brittle code, but also fewer programmers working on this, which is a risk.
We shouldn't delay forever until every potential solution has been explored.  There's always going to be one more thing to explore.

On 29 May 2015 5:16 pm, Gavin Andresen  wrote:RE: soft-forking an "extension block":So... go for it, code it up. Implement it in the Bitcoin Core wallet.Then ask the various wallet developer how long it would take them to update their software to support something like this, and do some UI mockups of what the experience would look like for users.If there are two engineering solutions to a problem, one really simple, and one complex, why would you pick the complex one?Especially if the complex solution has all of the problems of the simple one (20MB extension blocks are just as "dangerous" as 20MB main blocks, yes? If not, why not?)-- --Gavin Andresen

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

[Gavin Andresen]

RE: soft-forking an "extension block":

So... go for it, code it up. Implement it in the Bitcoin Core wallet.

Then ask the various wallet developer how long it would take them to update
their software to support something like this, and do some UI mockups of
what the experience would look like for users.

If there are two engineering solutions to a problem, one really simple, and
one complex, why would you pick the complex one?

Especially if the complex solution has all of the problems of the simple
one (20MB extension blocks are just as "dangerous" as 20MB main blocks,
yes? If not, why not?)


-- 
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

[Adam Back]

I discussed the extension block idea on wizards a while back and it is
a way to soft-fork an opt-in block-size increase.  Like everything
here there are pros and cons.

The security is better than Raylstonn inferred from Tier's explanation
I think..  It works as Tier described - there is an extension block
(say 10MB) and the existing 1MB block.  The extension block is
committed to in the 1MB chain.  Users can transfer bitcoin into the
extension block, and they can transfer them out.

The interesting thing is this makes block sizes changes opt-in and
gives users choice.  Choice is good.  Bitcoin has a one-size-fits-all
blocksize at present hence the block size debate.  If a bigger
block-size were an opt-in choice, and some people wanted 10MB or even
100MB blocks for low value transactions I expect it would be far
easier a discussion - people who think 100MB blocks are dangerously
centralising, would not opt to use them (or would put only small
values they can afford to lose in them).  There are some security
implications though, so this also is nuanced, and more on that in a
bit.

Fee pressure still exists for blocks of difference size as the
security assurances are not the same.  It is plausible that some
people would pay more for transactions in the 1MB block.

Now there are three choices of validation level, rather than the
normal 2-levels of SPV or full-node, with extension blocks we get a
choice: A) a user could run a full node for both 1MB and 10MB blocks,
and get full security for both 1MB and 10MB block transactions (but at
higher bandwidth cost), or B) a user could run a full node on the 1MB
block, but operate as an SPV node for the 10MB block, or C) run in SPV
mode for both 1MB and 10MB blocks.

Similarly for mining - miners could validate 1MB and 10MB transactions
(solo mine or GBT-style), or they could self-validate 1MB transactions
and pool mine 10MB transactions (have a pool validate those).

1MB full node users who do not upgrade to software that understands
extension blocks, could run in SPV mode with respect to 10MB blocks.
Here lies the risk - this imposes a security downgrade on the 1MB
non-upgraded users, and also on users who upgrade but dont have the
bandwidth to validate 10MB blocks.


We could defend non-upgrade users by making receiving funds that came
via the extension block opt-in also, eg an optional to use new address
version and construct the extension block so that payments out of it
can only go to new version addresses.

We could harden 1MB block SPV security (when receiving weaker
extension block transactions) in a number of ways: UTXO commitments,
fraud proofs (and fraud bounties) for moving from the extension block
to the 1MB block.  We could optionally require coins moving via the
extension block to the 1MB block to be matured (eg 100 blocks delay)


Anyway something else to evaluate.  Not as simple to code as a
hard-fork, but way safer transition than a hard-fork, and opt-in - if
you prefer the higher decentralisation of 1MB blocks, keep using them;
if you prefer 10MB blocks you can opt-in to them.

Adam

On 29 May 2015 at 17:39, Raystonn .  wrote:
> Regarding Tier’s proposal: The lower security you mention for extended
> blocks would delay, possibly forever, the larger blocks maximum block size
> that we want for the entire network.  That doesn’t sound like an optimal
> solution.
>
> Regarding consensus for larger maximum block size, what we are seeing on
> this list is typical of what we see in the U.S. Congress.  Support for
> changes by the stakeholders (support for bills by the citizens as a whole)
> has become irrelevant to the probability of these changes being adopted.
> Lobbyists have all the sway in getting their policies enacted.  In our case,
> I would bet on some lobbying of core developers by wealthy miners.
>
> Someone recently proposed that secret ballots could help eliminate the power
> of lobbyists in Congress.  Nobody invests in that which cannot be confirmed.
> Secret ballots mean the vote you are buying cannot be confirmed.  Perhaps
> this will work for Bitcoin Core as well.
>
>
> From: Tier Nolan
> Sent: Friday, May 29, 2015 7:22 AM
> Cc: Bitcoin Dev
> Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB
> stepfunction
>
> On Fri, May 29, 2015 at 3:09 PM, Tier Nolan  wrote:
>>
>>
>>
>> On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen 
>> wrote:
>>>
>>> But if there is still no consensus among developers but the "bigger
>>> blocks now" movement is successful, I'll ask for help getting big miners to
>>> do the same, and use the soft-fork block version voting mechanism to
>>> (hopefully) get a majority and then a super-majority willing to produce
>>> bigger blocks. The purpose of that process is to prove to any doubters that
>>> they'd better start supporting bigger blocks or they'll be left behind, and
>>> to give them a chance to upgrade before that happens.
>>
>>
>> How do you define that the movement is successful?
>
>
> Sorry again,