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.
next prev parent 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 ` 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$(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