From: Peter R <peter_r@gmx•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: "bitcoin-dev@lists•linuxfoundation.org Dev"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Your Gmaxwell exchange
Date: Sun, 30 Aug 2015 00:41:16 -0700 [thread overview]
Message-ID: <D00DB16B-6DAD-4F15-9DA6-15441C6223DA@gmx.com> (raw)
In-Reply-To: <CAAS2fgShF=2vtPrKtXmdA454s_xpJbxSB0SFBsstniHB8WtGzQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3601 bytes --]
Hi Greg,
>> I agree that miners may change their level of centralization. This neither
>> affects the model nor the results presented in the paper.
>
> It has tremdous significance to the real-world impact of your results.
The paper makes no claims about "miners changing their level of centralization." Whether it is or is not significant, it is outside the scope of the paper and irrelevant to the result that a fee market exists without a block size limit (given the assumption that some information about the transactions included in a block is communicated between miners during block solution propagation).
> If not for the other errors in your work,
Again, what you are calling "errors" are assumptions--in fact very reasonable assumptions that we know are valid for the network as a whole right now. You are proposing that maybe they won't be valid in the future if the miners move to some hypothetical configuration that you worry may be possible. I say prove it: show rigorously what the network would look like in a case where information about the transactions contained in a block is never communicated with the block solution. How do you get the miners to agree (assuming such a configuration is even physically possible)? Do you need all the miners to agree or only a portion of them? How reasonable is it that the systems moves into such a configuration? I know you spoke to this in your last response, but I mean really prove it...with a mathematical model, with diagrams and charts, with equations, with your assumptions clearly stated so that they can be put to the test--not by waving your hands on the bitcoin-dev mailing list.
This is an exciting field of research and we should encourage people to continue to explore these questions.
> this point would make the
> take away of your work not "a healthy transaction fee market exists
> without a block size limit" but rather "a decenteralized bitcoin
> cannot exist"-- as, accepting the other errors as fact your model
> shows that centralizing mining is always strictly more profitable at
> any level of fee demand; because your model equivilent shows that for
> any level of fee demand and gamma miners could increase their income
> by centeralizing further.
OK, I actually sort of agree with your very last sentence above. My paper indeed suggests that the most "profitable" configuration is one where there is only one "super pool." Is that likely to happen? I personally don't think so because of the game theory involved. But regardless of my opinion or your opinion on that matter, whether it is or isn't likely to happen is outside the scope of my paper. It is irrelevant to the result that a fee market exists without a block size limit given the assumption that there is more than a single miner.
> I absolutely agree that simplifications are useful and essential, but
> it is critically important to call them out before someone mistakes
> theoretical work as useful motivation for policy in the non-simplified
> system.
I do call them out. Furthermore, I've already agreed with you to further clarify these assumptions when I make the other corrections to the paper. Doing so will make the paper stronger.
I'm not going to address the remainder of your email because I believe that we are now talking past each other. I do appreciate the interest and attention that you've paid to my work on the Transaction Fee Market, and I also recognize the important contributions you've made such as coinjoin and HD wallets.
Best regards,
Peter
[-- Attachment #2: Type: text/html, Size: 4369 bytes --]
next prev parent reply other threads:[~2015-08-30 7:41 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAEgR2PFB3h_8fr=d8HegRSD0XdooimhFKtLR4vKr2QXv+EwBfQ@mail.gmail.com>
[not found] ` <AD284610-4F40-445C-A074-CC94EDFFCBA8@gmx.com>
2015-08-30 3:25 ` Gregory Maxwell
2015-08-30 4:13 ` Peter R
2015-08-30 4:57 ` Gregory Maxwell
2015-08-30 6:38 ` Adam Ritter
2015-08-31 18:55 ` Justus Ranvier
2015-08-31 19:11 ` Mike Hearn
2015-09-01 20:29 ` Wladimir J. van der Laan
2015-09-02 18:51 ` Justus Ranvier
2015-09-01 2:30 ` Oliver Petruzel
2015-08-30 7:41 ` Peter R [this message]
2015-08-31 20:06 Monarch
2015-08-31 20:27 ` Justus Ranvier
2015-08-31 20:48 ` Monarch
2015-08-31 21:24 ` Allen Piscitello
2015-08-31 21:42 ` Monarch
2015-08-31 21:54 ` Justus Ranvier
2015-08-31 22:53 ` Monarch
2015-08-31 23:24 ` Justus Ranvier
2015-09-01 0:02 ` Milly Bitcoin
2015-09-01 9:25 ` Jorge Timón
2015-08-31 23:32 ` Peter R
2015-08-31 23:47 ` s7r
2015-09-01 11:44 ` Monarch
2015-09-01 11:11 ` Monarch
2015-09-01 15:59 ` Dave Collins
2015-09-01 16:51 ` Monarch
2015-09-01 18:37 ` Eric Voskuil
2015-09-01 20:08 ` Monarch
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=D00DB16B-6DAD-4F15-9DA6-15441C6223DA@gmx.com \
--to=peter_r@gmx$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmaxwell@gmail$(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