public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Fwd: Your Gmaxwell exchange
@ 2015-08-30  1:59 Peter R
  0 siblings, 0 replies; only message in thread
From: Peter R @ 2015-08-30  1:59 UTC (permalink / raw)
  To: bitcoin-dev@lists.linuxfoundation.org Dev, Gregory Maxwell

[-- Attachment #1: Type: text/plain, Size: 3281 bytes --]

Dear Greg,

I am moving our conversation into public as I've recently learned that you've been forwarding our private email conversation verbatim without my permission [I received permission from dpinna to share the email that proves this fact: http://pastebin.com/jFgkk8M3].
> Greg wrote to Peter R:  "You know that your "proof" of this problematic-- outright false under the discussion we had, or at least likely of little pratical relevance under reasonable, pratical assumptions.  But you respond to dpinna agreeing with him and not cautioning him on relying on these
> 
The proof is not "problematic."  Right now you're providing an example of what Mike Hearn refers to as "black-and-white" thinking.  Just because the proof makes simplifying assumptions, doesn't mean it's not useful in helping us to understand the dynamics of the transaction fee market.  Proofs about physical systems need to make simplifying assumptions because the physical world is messy (unlike the world of pure math).  

My proof assumes very reasonably that block solutions contain information (i.e., Shannon Entropy) about the transactions included in a block.  As long as this is true, and as long as miners act rationally to maximize their profit, then the fee market will remain "healthy" according to the definitions given in my paper.  This is the case right now, this is the case with the Relay Network, and this would be the case using any implementation of IBLTs that I can imagine, so long as miners retain the ability to construct blocks according to their own volition.  The "healthy fee market" result follows from the Shannon-Hartley theorem; the SH-theorem describes the maximum rate at which information (Shannon Entropy) can be transmitted over a physical communication channel.   

You are imagining an academic scenario (to use your own words: "perhaps of little practical relevance") where all of the block solutions announcements contain no information at all about the transactions included in the blocks.  Although I agree that the fee market would not be healthy in such a scenario, it is my feeling that this also requires miners to relinquish their ability to construct blocks according to their own volition (i.e., the system would already be centralized).  I look forward to reading a white paper where you show:

(a) Under what assumptions/requirements such a communication scheme is physically possible.

(b) That such a configuration is not equivalent to a single entity[1] controlling >50% of the hash power.

(c) That the network moving into such a configuration is plausible.

Lastly, I'd like to conclude by saying that we are all here trying to learn about this new amazing thing called Bitcoin.  Please go ahead and write a paper that shows under what network configuration my results don't hold.  I'd love to read it!  This is how we make progress in science!!

Sincerely, 
Peter

[1] For example, if--in order to achieve such a configuration with infinite coding gain--miners can no longer choose how to structure their blocks according to their own volition, then I would classify those miners as slaves rather than as peers, and the network as already centralized.


Link to forwarded email pastebin: http://pastebin.com/jFgkk8M3


[-- Attachment #2: Type: text/html, Size: 4100 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2015-08-30  2:00 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-30  1:59 [bitcoin-dev] Fwd: Your Gmaxwell exchange Peter R

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox