public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: Tom Harding <tomh@thinlink.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Răspuns: Personal opinion on the fee market from a worried local trader
Date: Fri, 31 Jul 2015 03:29:21 +0200	[thread overview]
Message-ID: <CABm2gDopoEgMOPWfqH1Jqk4HktodkhWhYZYmqb2edgi9N7+mXA@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDqCdrVvEzOfUZMBTbEfw5-nfNjBpDcWS-zmNey+_n-qMQ@mail.gmail.com>

I'm re-reading and I have many spelling errors, sorry.

On Fri, Jul 31, 2015 at 3:21 AM, Jorge Timón <jtimon@jtimon.cc> wrote:
> On Thu, Jul 30, 2015 at 10:53 PM, Tom Harding <tomh@thinlink.com> wrote:
>> On 7/30/2015 11:14 AM, Jorge Timón wrote:
>>> The blocksize limit (your "production quota") is necessary for
>>> decentralization, not for having a functioning fee market.
>>
>>> If we can agree that hitting the limit will JUST cause higher fees and
>>> not bitcoin to fail, puppies to die or the sky to turn purple I think
>>> that's a great step forward in this debate.
>>
>> It's interesting how people see things differently.  I think your first
>> statement above represents a great step forward in the debate.  Unlike
>> Adam Back, you state that a block size limit is not necessary to create
>> a functioning fee market.
>
> Yes, Adam Back and I some times see things differently, and that's fine.
> Many times, we realize later that we're saying the same thing with
> different words and we're just discussing about terminology. That's
> not an exclusive problem we have, it's a universal communication
> problem. That's why math (which is nothing but a language) was
> invented: to never discuss about terminology, to force any used
> concept to be defined beforehand.
> Sorry for the distraction, but I think this is one of those times.
> Whether "hitting the limit" is "necessary" (I bet he never said
> "strictly necessary") or just "helpful" is not very relevant. I think
> Adam and I agree that hitting the limit wouldn't be bad, but actually
> good for an young and immature market like bitcoin fees.
> Apart from the dubious time-preference premium (dubious because in
> most cases is just wallet's defaults and not users in a hurry),
> transactions are basically free if you are willing to wait (and
> apparently not that much).
>
> If I was a miner and you want me to include your transaction for free,
> you're asking me to give you money, which I would prefer to do
> directly if you are a friend or a non-profit organization that I like
> or whatever rather than giving you money through bitcoin fee
> discounts.
> By including your transaction, I'm increasing the probability of my
> mined block being orphaned and you're not willing to give me even a
> single satoshi in exchange.
> Today, in practice, one satoshi fee and no fee at all are treated
> exactly the same by most (maybe all?) miners, which if you ask me, I
> find very ~~unfair~~ economically absurd.
>
> Are all miners just stupid?
> Not necessarily, they just don't care about fees or transactions at all.
> Who is to blame? Certainly not the value chosen for the block size
> limit, it's clearly the subsidy's fault: subsidy is all miners care
> about (by the way, that's also the illness behind the SPV-mining
> symptom). I am very worried about excessive mining subsidies (if you
> knew how worried the freicoin community was [and still is] about this
> problem, even if freicoin probably has one of the lowest mining
> subsidies out there [currently and perpetually annual 5% of the
> monetary base]...).
> And I think that "hitting the limit" is not a catastrophe at all, but
> rather an opportunity to motivate miners to start caring more about
> transactions and fees (in proportion to what they care about).
> And if the limit is increased later and fees fall again, that's fine,
> because miners' will already be more prepared for the next time we
> "hit the limit".
> Anyway, maybe that hope is irrelevant, but what I'm convinced about is
> that rising non-fast-confirmation mining fees above zero is not a bad
> thing.
>
>> As to your second statement, unfortunately for immediate harmonious
>> relations, I was merely separating out the elevated fee market concern,
>> not at all saying it is the only or even the biggest concern with
>> limited capacity.  Alan Reiner, Ryan X. Charles and others have
>> eloquently explained how restrictive a 1MB limit is, even with "layer 2".
>
> To be honest, I've only followed those were assuming the worse case
> for optimization: bitcoin global monetary monopoly.
> If I remember correctly, they were aiming for something around 170 MB,
> but in any case, any value for the constant is completely arbitrary to
> me at this point, including 1 MB. I'm deeply offended when I feel
> included in the "1MBers group" because I don't feel like that at all.
> To be honest, I have no idea what the correct value should be, all I
> know it's a trade-off in a monotonic function:
>
> f(blocksize) = decentralization
>
>> What's missing from the decentralization dialog is a quantitative
>> measure of decentralization.
>
> You are completely right: there's no defined measurable unit for
> "decentralization" ("p2pness", whatever bitcoin has that wasn't
> possible before pow-based distributed consensus).
> And I'm afraid we will never have such a measurable unit. Maybe the
> best definition of the property we're trying to capture is just "the
> opposite of centralization", assuming centralization is easier to
> define.
> The best we have now are pool percentages, number of nodes,
> subsidy/fee ratio (as said, this influences things like SPV mining)
> How all that gets to...?
>
> g(many unrelated matrics) = centralization
>
> I don't really think anybody knows, but no matter what your
> interpretation of some Japanese-named dude on the internet's words
> (aka bitcoin sacred history) are, if you think 3 validating nodes is
> enough for a "p2p" monetary network.
> It is very possible that decentralization(blocksize) =
> decentralization(blocksize+1) for many values of blocksize, but I
> think the burden of the proof that decentralization(current_blocksize)
> ~= decentralization(current_blocksize+1) is on those who propose
> ++current_blocksize.
> But I think ANY metric for centralization would be welcomed right now.
> In fact, it doesn't need to be a function of blocksize, it can be a
> function of maxBlockSigops or maybe even maxBlockInputs or
> maxBlockOuputs.
> But if we don't want to have any consensus limit to centralization
> bitcoin has already fail (and doesn't need expensive proof of work).
>
>> Why not slam users with higher fees now, if we accept that they may be
>> necessary someday? For the same reasons you don't ask a child, age 5, to
>> work in a factory.
>
> It is a certainty that fees will be necessary someday: bitcoin's
> seigniorage is limited to 21 M to subsidize mining, and we know that
> won't last forever. Expensive proof of work (that centralized systems
> lack) must be paid for somehow.
> Who's child am I asking to work in a factory? I feel I'm missing
> something there.


  reply	other threads:[~2015-07-31  1:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CADZB0_ZgDMhVgCUh2PTAPDL7k_W8QGt_HLYdkwv_qQ5xEMn8HA@mail.gmail.com>
2015-07-29 14:09 ` [bitcoin-dev] Răspuns: Personal opinion on the fee market from a worried local trader Vali Zero
2015-07-29 17:47   ` Raystonn .
2015-07-29 22:54     ` s7r
2015-07-30  3:41       ` Ryan Butler
2015-07-30  4:00         ` Adam Back
2015-07-30  4:05           ` Adam Back
2015-07-30  4:48           ` Ryan Butler
2015-07-30 13:14             ` Tom Harding
2015-07-30 14:25               ` Dave Hudson
2015-07-30 14:57                 ` Tom Harding
2015-07-30 18:14               ` Jorge Timón
2015-07-30 18:16                 ` Jorge Timón
2015-07-30 20:53                 ` Tom Harding
2015-07-31  1:21                   ` Jorge Timón
2015-07-31  1:29                     ` Jorge Timón [this message]
2015-07-31  9:56                     ` Thomas Zander
2015-07-31 12:32                       ` Oleg Andreev
2015-07-31 15:24                         ` Jorge Timón
2015-07-30 12:45           ` Ivan Brightly
2015-07-30  4:07         ` Jean-Paul Kogelman
2015-07-30  9:52       ` odinn

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=CABm2gDopoEgMOPWfqH1Jqk4HktodkhWhYZYmqb2edgi9N7+mXA@mail.gmail.com \
    --to=jtimon@jtimon.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=tomh@thinlink.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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