Re: [bitcoin-dev] Bitcoin Core and hard forks

["Jorge Timón" <jtimon@jtimon.cc>]

On Thu, Jul 23, 2015 at 6:17 PM, Tom Harding via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
>
>> If the user expectation is that a price would never arise because
>> supply is going to be increased ad infinitum and they will always be
>> able to send fast in-chain bitcoin transactions for free, just like
>> breath air (an abundant resource) for free, then we should change that
>> expectation as soon as possible.
>
> No.  We should accept that reality may change, and we should promote
> understanding of that fact.
>
> We should not artificially manipulate the market "as soon as possible,"
> since we ourselves don't know much at all about how the market will
> unfold in the future.

We know perfectly well that the system will need to eventually be
sustained by fees.
We should stop misinforming new users talking them about how bitcoin
transactions "are free", because they're clearly not.

>> the criteria for the consensus block size should be purely based on
>> technological capacity (propagation benchmarking, etc) and
>> centralization concerns
>
> Right, purely these.  There is no place for artificially manipulating
> expectations.

Am I "artificially manipulating expectations" ?

>> they will simply advance the front and start another battle, because
>> their true hidden faction is the "not ever side". Please, Jeff, Gavin,
>> Mike, show me that I'm wrong on this point. Please, answer my question
>> this time. If "not now", then when?
>
> Bitcoin has all the hash power.  The merkle root has effectively
> infinite capacity.  We should be asking HOW to scale the supporting
> information propagation system appropriately, not WHEN to limit the
> capacity of the primary time-stamping machine.

Timestamping data using the blockchain is not the same as including
that the data in the blockchain itself because the later is a scarce
resource.
The "timestamping space" is already unlimited today with no changes.
You can use a bitcoin transaction to timestamp an unbounded amount of
external data using exactly 0 extra bytes in your transaction!
Here's the code: https://github.com/Blockstream/contracthashtool

And I'm very interested in scaling Bitcoin, I just disagree that
changing a constant is a "scaling solution".

On Thu, Jul 23, 2015 at 6:28 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev
>> We haven't tried yet.  I can't answer for the people you asked, but
>> personally I haven't thought much about when we should declare failure.
>
>
> Yes! Lets plan for success!

I extremely disagree that having a block limit is failure. It's a
design decision to protect the system against centralization (which we
will be able to rise as we solve technical and centralization problems
we have today).
But thank you for being more clear about it now, Gavin. You won't stop
on a 8GB or 32GB limit because you think having ANY limit would be a
failure.
Is that correct?
If not, can you please answer clearly when and why you think the
blocksize should be lower than demand (when you will be ok with
bitcoin users having to pay fees for the service they're enjoying)?
If your answer is "never", I would prefer to hear it from you than
just concluding it by the lack of an answer.