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

2015-06-01 Thread 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)

2015-06-01 Thread 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)

2015-06-01 Thread 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