From: "Jorge Timón" <jtimon@jtimon•cc>
To: Tom Harding <tomh@thinlink•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Date: Thu, 23 Jul 2015 19:51:11 +0200 [thread overview]
Message-ID: <CABm2gDp5-D3r=0rbq28-h8ewyHY8Rj9B0AFjO1fWfyuUEDMMfg@mail.gmail.com> (raw)
In-Reply-To: <55B113AF.40500@thinlink.com>
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.
next prev parent reply other threads:[~2015-07-23 17:51 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
2015-07-22 16:52 ` Pieter Wuille
2015-07-22 17:18 ` Ross Nicoll
2015-07-22 17:32 ` Milly Bitcoin
2015-07-22 18:45 ` Bryan Cheng
2015-07-22 17:33 ` Jeff Garzik
2015-07-22 18:01 ` Jeff Garzik
2015-07-22 18:03 ` Alex Morcos
2015-07-22 18:24 ` Jeff Garzik
2015-07-23 12:17 ` Jorge Timón
2015-07-23 16:17 ` Tom Harding
2015-07-23 16:28 ` Gavin Andresen
2015-07-23 16:50 ` cipher anthem
2015-07-23 17:14 ` Robert Learney
2015-07-23 18:21 ` Eric Lombrozo
2015-07-23 18:47 ` Jorge Timón
2015-07-23 17:43 ` Eric Lombrozo
2015-07-23 18:10 ` Jameson Lopp
2015-07-23 19:14 ` Eric Lombrozo
2015-07-23 19:35 ` Gavin Andresen
2015-07-23 19:39 ` Eric Lombrozo
2015-07-23 19:51 ` Eric Lombrozo
2015-07-23 19:52 ` Jameson Lopp
2015-07-23 20:26 ` Jorge Timón
2015-07-23 20:52 ` Eric Lombrozo
2015-07-23 23:42 ` Benedict Chan
[not found] ` <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmai>
2015-07-23 23:57 ` Eric Lombrozo
2015-07-24 0:04 ` Eric Lombrozo
2015-07-24 0:20 ` Simon Liu
2015-07-24 0:22 ` Jean-Paul Kogelman
2015-07-24 0:32 ` Eric Lombrozo
2015-07-24 0:38 ` Eric Lombrozo
2015-07-24 0:45 ` Jean-Paul Kogelman
2015-07-24 0:49 ` Jean-Paul Kogelman
2015-07-24 0:53 ` Peter Todd
2015-07-24 1:03 ` Jean-Paul Kogelman
2015-07-24 1:08 ` Eric Lombrozo
2015-07-24 1:25 ` Jean-Paul Kogelman
2015-07-24 1:28 ` Eric Lombrozo
2015-07-24 1:37 ` Eric Lombrozo
2015-07-24 1:42 ` Jean-Paul Kogelman
2015-07-24 1:55 ` Eric Lombrozo
2015-07-24 2:12 ` [bitcoin-dev] Bitcoin, Perceptions, and Expectations Raystonn .
2015-07-24 8:48 ` Jonas Schnelli
2015-07-24 9:42 ` Jorge Timón
2015-07-24 14:37 ` Vincent Truong
2015-07-25 2:18 ` gb
2015-07-25 11:22 ` Slurms MacKenzie
2015-07-25 15:04 ` Thomas Kerin
2015-07-24 0:56 ` [bitcoin-dev] Bitcoin Core and hard forks Eric Lombrozo
2015-07-24 1:05 ` Jean-Paul Kogelman
2015-07-23 18:12 ` Slurms MacKenzie
2015-07-23 18:57 ` Mike Hearn
2015-07-23 17:51 ` Jorge Timón [this message]
2015-07-24 6:30 ` Tom Harding
2015-07-24 9:24 ` Jorge Timón
2015-07-24 22:50 ` Tom Harding
2015-07-28 11:29 ` Jorge Timón
2015-07-28 11:32 ` Jorge Timón
2015-07-28 16:44 ` Tom Harding
2015-07-28 17:33 ` Jorge Timón
2015-07-22 19:17 ` Eric Lombrozo
2015-07-22 21:43 ` Mike Hearn
2015-07-22 21:56 ` Eric Lombrozo
2015-07-22 22:01 ` Mike Hearn
2015-07-22 22:09 ` Eric Lombrozo
2015-07-23 1:53 ` Eric Lombrozo
2015-07-22 22:30 ` Jeff Garzik
2015-07-23 0:27 ` Tom Harding
2015-07-23 0:37 ` Eric Lombrozo
2015-07-23 4:40 ` Edmund Edgar
2015-07-27 12:08 ` Peter Todd
2015-07-27 12:44 ` Milly Bitcoin
2015-07-22 22:40 Raystonn
2015-07-22 23:42 ` Cory Fields
2015-07-22 23:53 ` Eric Lombrozo
2015-07-23 0:05 ` Cory Fields
2015-07-23 0:13 ` Eric Lombrozo
2015-07-23 0:34 ` Cory Fields
2015-07-23 0:43 ` Eric Lombrozo
2015-07-23 7:24 ` Ross Nicoll
2015-07-23 0:49 ` Eric Voskuil
2015-07-23 18:12 ` Jorge Timón
[not found] <BA7ACCE1-81B2-4AC1-B6DD-7A856FD27D52@gmail.com>
2015-07-23 8:24 ` Gareth Williams
2015-07-27 17:05 Alice Larson
2015-07-27 17:22 ` Eric Voskuil
2015-07-28 4:55 ` Wladimir J. van der Laan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABm2gDp5-D3r=0rbq28-h8ewyHY8Rj9B0AFjO1fWfyuUEDMMfg@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tomh@thinlink$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox