daily pastebin goal
84%
SHARE
TWEET

Your Gmaxwell exchange

a guest Aug 29th, 2015 1,222 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Begin forwarded message:
  2.  
  3. From: Daniele Pinna <daniele.pinna@gmail.com>
  4. Subject: Your Gmaxwell exchange
  5. Date: 29 August, 2015 5:05:33 PM PDT
  6. To: Peter R <peter_r@gmx.com>
  7.  
  8. Why wouldn't you forward this to me when you've known about me working on extending your work for the past two weeks...
  9.  
  10. Daniele
  11.  
  12. ---------- Forwarded message ----------
  13. From: "Gregory Maxwell" <gmaxwell@gmail.com>
  14. Date: Aug 29, 2015 10:40 PM
  15. Subject: Fwd: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests
  16. To: "Daniele Pinna" <daniele.pinna@gmail.com>
  17. Cc:
  18.  
  19.  
  20. Forwarded conversation
  21. Subject: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests
  22. ------------------------
  23.  
  24. From: Peter R via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
  25. Date: Tue, Aug 4, 2015 at 6:40 AM
  26. To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
  27.  
  28.  
  29. Dear Bitcoin-Dev Mailing list,
  30.  
  31. I’d like to share a research paper I’ve recently completed titled “A Transaction Fee Market Exists Without a Block Size Limit.”  In addition to presenting some useful charts such as the cost to produce large spam blocks, I think the paper convincingly demonstrates that, due to the orphaning cost, a block size limit is not necessary to ensure a functioning fee market.  
  32.  
  33. The paper does not argue that a block size limit is unnecessary in general, and in fact brings up questions related to mining cartels and the size of the UTXO set.  
  34.  
  35. It can be downloaded in PDF format here:
  36.  
  37. https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
  38.  
  39. Or viewed with a web-browser here:
  40.  
  41. https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit
  42.  
  43. Abstract.  This paper shows how a rational Bitcoin miner should select transactions from his node’s mempool, when creating a new block, in order to maximize his profit in the absence of a block size limit. To show this, the paper introduces the block space supply curve and the mempool demand curve.  The former describes the cost for a miner to supply block space by accounting for orphaning risk.  The latter represents the fees offered by the transactions in mempool, and is expressed versus the minimum block size required to claim a given portion of the fees.  The paper explains how the supply and demand curves from classical economics are related to the derivatives of these two curves, and proves that producing the quantity of block space indicated by their intersection point maximizes the miner’s profit.  The paper then shows that an unhealthy fee market—where miners are incentivized to produce arbitrarily large blocks—cannot exist since it requires communicating information at an arbitrarily fast rate.  The paper concludes by considering the conditions under which a rational miner would produce big, small or empty blocks, and by estimating the cost of a spam attack.  
  44.  
  45. Best regards,
  46. Peter
  47.  
  48. _______________________________________________
  49. bitcoin-dev mailing list
  50. bitcoin-dev@lists.linuxfoundation.org
  51. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  52.  
  53.  
  54. ----------
  55. From: Gregory Maxwell <gmaxwell@gmail.com>
  56. Date: Tue, Aug 4, 2015 at 7:42 AM
  57. To: Peter R <peter_r@gmx.com>
  58.  
  59.  
  60. How could you have written at such length and complexity but ignoring
  61. the simple expident miners have of simply centeralizing their
  62. operation around larger pools to lower their costs-- an activity they
  63. previously performed, in practice, not just theory (which was walked
  64. back by handing them more efficient relay mechenisms) and which is
  65. simple, easy, and which reduces those marginal costs to 0 at the limit
  66. (e.g. all miners served off a particular host) --- after I
  67. specifically called you out on this previously?   Doubly so when your
  68. analysis gives provides a framework for analyizing the profitibility
  69. of moving from one point on that income tradeoff graph to another
  70. (e.g. the lost income from failing to centeralize)....
  71. > _______________________________________________
  72. > bitcoin-dev mailing list
  73. > bitcoin-dev@lists.linuxfoundation.org
  74. > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  75. >
  76.  
  77. ----------
  78. From: Peter R <peter_r@gmx.com>
  79. Date: Tue, Aug 4, 2015 at 7:52 AM
  80. To: Gregory Maxwell <gmaxwell@gmail.com>
  81.  
  82.  
  83. Hey Greg,
  84.  
  85. The paper does consider more efficient relaying mechanisms.  This is what I refer to as the "propagation impedance."  Figure 8 shows that the cost of spam blocks decrease considerably with faster block propagation.  The first two simplifying assumptions described in the conclusion (p.13, second paragraph) speak to this further, and the first two "topics for further research" in that same paragraph relate to this as well.
  86.  
  87. Best regards,
  88. Peter
  89.  
  90. ----------
  91. From: Gregory Maxwell <gmaxwell@gmail.com>
  92. Date: Tue, Aug 4, 2015 at 8:01 AM
  93. To: Peter R <peter_r@gmx.com>
  94.  
  95.  
  96. On Tue, Aug 4, 2015 at 7:52 AM, Peter R <peter_r@gmx.com> wrote:
  97. > Hey Greg,
  98. >
  99. > The paper does consider more efficient relaying mechanisms.  This is what I refer to as the "propagation impedance."  Figure 8 shows that the cost of spam blocks decrease considerably with faster block propagation.  The first two simplifying assumptions described in the conclusion (p.13, second paragraph) speak to this further, and the first two "topics for further research" in that same paragraph relate to this as well.
  100.  
  101. I'm aware--  But "use the same pool" is a seperate modality from "use
  102. more efficient transmission"; for one because if all miners do so (or
  103. technically just a simple majority plus a preference to mine on their
  104. own blocks even if later) then I believe your model would have an
  105. impediance of zero which has very different behavior.  It also already
  106. exists, e.g. doesn't require new technology.  And for any point on
  107. your demand curve you assume the system is operating at, if the size
  108. of blocks can go up, I believe your model shows miners will increase
  109. income by centeralizing (because absent a limit on the supply, a lower
  110. impedance is more profitable).
  111.  
  112.  
  113. A more minor point, perhaps I'm missing it, but you don't seem to
  114. analyize the effect of R/T changing on your model. As you know, in
  115. Bitcoin unless the supply of coins is increased R/T is vanishing and
  116. will geometrically become 0.
  117.  
  118. ----------
  119. From: Gregory Maxwell <gmaxwell@gmail.com>
  120. Date: Tue, Aug 4, 2015 at 8:37 AM
  121. To: Peter R <peter_r@gmx.com>
  122.  
  123.  
  124. On Tue, Aug 4, 2015 at 8:01 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
  125. > On Tue, Aug 4, 2015 at 7:52 AM, Peter R <peter_r@gmx.com> wrote:
  126. >> Hey Greg,
  127. >>
  128. >> The paper does consider more efficient relaying mechanisms.  This is what I refer to as the "propagation impedance."  Figure 8 shows that the cost of spam blocks decrease considerably with faster block propagation.  The first two simplifying assumptions described in the conclusion (p.13, second paragraph) speak to this further, and the first two "topics for further research" in that same paragraph relate to this as well.
  129. >
  130. > I'm aware--  But "use the same pool" is a seperate modality from "use
  131. > more efficient transmission"; for one because if all miners do so (or
  132. > technically just a simple majority plus a preference to mine on their
  133. > own blocks even if later) then I believe your model would have an
  134. > impediance of zero which has very different behavior.  It also already
  135.  
  136. It occurs to me that I'm perhaps being too understated.
  137.  
  138. "An unhealthy fee market requires a propagation time that grows
  139. asymptotically with block size slower than log Q Using physical
  140. arguments, we can show that this is not possible"
  141.  
  142. Your physical argument is incorrect on several folds.  First, if we
  143. miners centralize they can achieve a growth of propagation time of 0.
  144. 0 is less than log(Q), that condition is trivially possible.
  145.  
  146. More generally your invocation of shanon-hartley is misapplied because
  147. you are ignoring the entropy of the signal. Even disregarding the
  148. miners ability to optimize communication by centralizing, no
  149. blocksize-proportional information is /necessarily/ transmitted at the
  150. time a block has been received. For example, imagine if miners only
  151. include transactions that were previously committed to by another,
  152. external, consensus system the concent of the blocks would be known in
  153. advance, and not need to be transmitted. As a more concrete example,
  154. the block relay network today communicates far less than one bit per
  155. bit of blocksize to relay a block (e.g. transmitting a 962597 byte
  156. block using 3804 bytes-- I wonder why instead you did not announce
  157. your discovery that the block relay network has beat the Shanon limit!
  158. :) --- after all, by your metric it can transmit X bits of information
  159. over a channel which has _significantly_ less than X capacity).
  160.  
  161. If miners choose transactions in a way to minimize the transmission
  162. delays there is no physical limit on how small the amount of
  163. information is, and it does not necessarily depend on the blocksize at
  164. all (see e.g. the practice of agreeing on transactions in advance--
  165. e.g. the transmitted transaction proportional data can be the constant
  166. size of 0),
  167.  
  168. ----------
  169. From: Peter R <peter_r@gmx.com>
  170. Date: Tue, Aug 4, 2015 at 9:27 AM
  171. To: Gregory Maxwell <gmaxwell@gmail.com>
  172.  
  173.  
  174. Hi Greg,
  175.  
  176. Thanks for the comments and interest in my paper.
  177.  
  178. > I'm aware--  But "use the same pool" is a seperate modality from "use
  179. > more efficient transmission"; for one because if all miners do so (or
  180. > technically just a simple majority plus a preference to mine on their
  181. > own blocks even if later) then I believe your model would have an
  182. > impediance of zero which has very different behavior.  It also already
  183. > exists, e.g. doesn't require new technology.  And for any point on
  184. > your demand curve you assume the system is operating at, if the size
  185. > of blocks can go up, I believe your model shows miners will increase
  186. > income by centeralizing (because absent a limit on the supply, a lower
  187. > impedance is more profitable).
  188.  
  189. I agree that lowering the propagation impedance is a profitable strategy.  I also agree that if the hash power is all pointed to one "super pool" that the impedance would be zero.
  190.  
  191. > A more minor point, perhaps I'm missing it, but you don't seem to
  192. > analyize the effect of R/T changing on your model. As you know, in
  193. > Bitcoin unless the supply of coins is increased R/T is vanishing and
  194. > will geometrically become 0.
  195.  
  196. I don't, except briefly in the last paragraph of the conclusion.  The paper was already quite long and I didn't want to open a can of worms about things a quarter of a century away.
  197.  
  198. > Your physical argument is incorrect on several folds.  First, if we
  199. > miners centralize they can achieve a growth of propagation time of 0.
  200. > 0 is less than log(Q), that condition is trivially possible.
  201.  
  202. Good point.  I'm implicitly assuming that mining isn't centralized…that information must still be communicated across the network.  I thought that was sort of obvious (because that's the 51% scenario will already know about), but I agree I should have spoken to this point in more detail.
  203.  
  204. > More generally your invocation of shanon-hartley is misapplied because
  205. > you are ignoring the entropy of the signal.
  206.  
  207. The "gamma" variable represents the coding gain (the degree to which the blocks can be compressed) and "C" represents the channel capacity.  So the term (gamma * C) represents the effective rate than the uncompressed block's propagate at.  The actual bit rate is just C.
  208.  
  209. As long as information needs to be communicated across channels, the Shannon-Hartley theorem applies.  To what extent the solutions can be compressed (what gamma value can be obtained) is an open research questions, afaik.
  210.  
  211. > I wonder why instead you did not announce
  212. > your discovery that the block relay network has beat the Shanon limit!
  213. > :) --- after all, by your metric it can transmit X bits of information
  214. > over a channel which has _significantly_ less than X capacity).
  215.  
  216. Haha, but I actually do discuss this in two places on page 9.  But I agree now that you point it out that I should have explained how the relay network has a higher "gamma" value than the peer-to-peer network, and that's part of the reason why it's propagation impedance is so much lower.  I will include this in the next version!
  217.  
  218. Best regards,
  219. Peter
  220.  
  221. ----------
  222. From: Gregory Maxwell <gmaxwell@gmail.com>
  223. Date: Tue, Aug 4, 2015 at 9:43 AM
  224. To: Peter R <peter_r@gmx.com>
  225.  
  226.  
  227. On Tue, Aug 4, 2015 at 9:27 AM, Peter R <peter_r@gmx.com> wrote:
  228. > Good point.  I'm implicitly assuming that mining isn't centralized…that information must still be communicated across the network.  I thought that was sort of obvious (because that's the 51% scenario will already know about), but I agree I should have spoken to this point in more detail.
  229.  
  230. Thats orthorgonal--  in that yes, if mining is not decenteralized less
  231. infomration must be communicated (in fact it's a progression, not a
  232. threshold-- the more centeralized the network the less information
  233. will be transmitted even by a naieve system)... but even with complete
  234. decenteralization no information needs to be transmitted at the time a
  235. block is found.
  236.  
  237. > To what extent the solutions can be compressed (what gamma value can be obtained) is an open research questions, afaik.
  238.  
  239. Consider the following scheme (which, we've proposed deploying
  240. previously in varrious forms):
  241.  
  242. Miners volutarily participate in a fast consensus mechenism which
  243. commits to transactions-- it could be a merged mined blockchain (like
  244. the P2Pool chain, which commits to transactions) or something entirely
  245. different.  No reward is given for participation in this scheme.  In
  246. their Bitcoin blocks miners only include transactions which are at
  247. least 6 blocks deep in that chain, moreover they include all
  248. transactions which are in it, in a determinstic order.
  249.  
  250. Now when they find a block, all the participants will know exactly
  251. which transactions they included, in exactly which order. No matter
  252. how many there were.  _No_ information proportal to the transaction
  253. count needs to be communicated to trasmit the block.
  254.  
  255. -
  256. ----------
  257. From: Gregory Maxwell <gmaxwell@gmail.com>
  258. Date: Wed, Aug 5, 2015 at 8:50 PM
  259. To: Peter R <peter_r@gmx.com>
  260.  
  261.  
  262. Peter,  It's been over 24 hours since my last message to you-- and I'm
  263. greatly confused by the correspondance which I see you posting on
  264. reddit.
  265.  
  266. I believe in my discussion with you I conveyed a total break of your
  267. paper: I believe demonstrated that your premises were incorrect and do
  268. not support your some of your strongest conclusions.
  269.  
  270. I've been expecting you to come back with a response that you would be
  271. retracting or seriously revising your paper and its conclusions.  And
  272. yet I see you continuing to communicate with the public in messages
  273. which suggest you are unaware of these considerations.
  274. (e.g. https://www.reddit.com/r/Bitcoin/comments/3fuz2s/peter_todd_against_gavin_on_the_bitcoindev/cts983w
  275. ).
  276.  
  277. I don't think Peter Todd's response to you was approiate at the
  278. time... but it would be helpful if you didn't demonstrate that he was
  279. actually correct.
  280.  
  281. ----------
  282. From: Peter R <peter_r@gmx.com>
  283. Date: Wed, Aug 5, 2015 at 9:43 PM
  284. To: Gregory Maxwell <gmaxwell@gmail.com>
  285.  
  286.  
  287. Hi Greg,
  288.  
  289. Peter,  It's been over 24 hours since my last message to you-- and I'm
  290. greatly confused by the correspondance which I see you posting on
  291. reddit.
  292.  
  293. Sorry for the delay.  It was my last day in Annecy and we were swimming and today I was on the train to the Paris airport.
  294.  
  295. On Tue, Aug 4, 2015 at 9:27 AM, Peter R <peter_r@gmx.com> wrote:
  296. Good point.  I'm implicitly assuming that mining isn't centralized…that information must still be communicated across the network.  I thought that was sort of obvious (because that's the 51% scenario will already know about), but I agree I should have spoken to this point in more detail.
  297.  
  298. Thats orthorgonal--  in that yes, if mining is not decenteralized less
  299. infomration must be communicated (in fact it's a progression, not a
  300. threshold-- the more centeralized the network the less information
  301. will be transmitted even by a naieve system)... but even with complete
  302. decenteralization no information needs to be transmitted at the time a
  303. block is found.
  304.  
  305. I'm not following your logic here.  At some point information needs to be transmitted to the miner's peers.  This takes a non-zero amount of time according to the Shannon-Hartley theorem.  This time has a cost associated with it.  What do you disagree with here?  
  306.  
  307. To what extent the solutions can be compressed (what gamma value can be obtained) is an open research questions, afaik.
  308.  
  309. Consider the following scheme (which, we've proposed deploying
  310. previously in varrious forms):
  311.  
  312. Miners volutarily participate in a fast consensus mechenism which
  313. commits to transactions-- it could be a merged mined blockchain (like
  314. the P2Pool chain, which commits to transactions) or something entirely
  315. different.  No reward is given for participation in this scheme.  In
  316. their Bitcoin blocks miners only include transactions which are at
  317. least 6 blocks deep in that chain, moreover they include all
  318. transactions which are in it, in a determinstic order.
  319.  
  320. Now when they find a block, all the participants will know exactly
  321. which transactions they included, in exactly which order. No matter
  322. how many there were.  _No_ information proportal to the transaction
  323. count needs to be communicated to trasmit the block.
  324.  
  325. If zero information related to the transactions needs to be transmitted between peers, then the peers aren't making decisions of their own volition related to the transactions included in a block.  If they're not making decisions related to transactions then they're not really "peers" in my opinion.  I see this as another example of how a single entity who controls a lot of hash power can do various nasty stuff.  
  326.  
  327. What is your definition of a peer?  To me, a peer needs to get information from his other peers from which he makes his own independent decisions.  This information takes time to communicate.  If there's more transactions, there's more information to communicate.  The only way this isn't true if I'm not mistaken is if there's no information to communicate related to the transactions in the block.  But like I said earlier, in this case then the miner's aren't peers--they're just slaves--and the system is already centralized.  
  328.  
  329. I believe in my discussion with you I conveyed a total break of your
  330. paper: I believe demonstrated that your premises were incorrect and do
  331. not support your some of your strongest conclusions.
  332.  
  333. The only objection I've heard that makes sense to me is Dave Hudson's.  Can you explain exactly a what point in my paper you disagree with the math, the logic, or the assumptions?  How should the math change to make it correct in your opinion?
  334.  
  335. I've been expecting you to come back with a response that you would be
  336. retracting or seriously revising your paper and its conclusions.  And
  337. yet I see you continuing to communicate with the public in messages
  338. which suggest you are unaware of these considerations.
  339. (e.g. https://www.reddit.com/r/Bitcoin/comments/3fuz2s/peter_todd_against_gavin_on_the_bitcoindev/cts983w
  340. ).
  341.  
  342. I don't think Peter Todd's response to you was approiate at the
  343. time... but it would be helpful if you didn't demonstrate that he was
  344. actually correct.
  345.  
  346. Dave Hudson made what I feel was a valid objection regarding the "you-don't-orphan-your-own-blocks" idea.  I agree that my paper doesn't address his objection, but I believe it can be modified to do so without changing the results of the paper (that a healthy fee market exists).  Peter Todd echoed something agreeing with Dave, no?
  347.  
  348. Best regards,
  349. Peter
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356. ----------
  357. From: Gregory Maxwell <gmaxwell@gmail.com>
  358. Date: Wed, Aug 5, 2015 at 10:29 PM
  359. To: Peter R <peter_r@gmx.com>
  360.  
  361.  
  362. On Wed, Aug 5, 2015 at 9:43 PM, Peter R <peter_r@gmx.com> wrote:
  363. > I'm not following your logic here.  At some point information needs to be
  364. > transmitted to the miner's peers.  This takes a non-zero amount of time
  365. > according to the Shannon-Hartley theorem.  This time has a cost associated
  366. > with it.  What do you disagree with here?
  367.  
  368. Hm. I thought I gave a sufficiently concrete example. No information
  369. needs to be conveyed at the time a block is found (beyond the fact of
  370. the block, e.g. it's extranonce, which is all constant size); because
  371. the information can have been sent in advance, unboundadly far in
  372. advance is possible in fact.
  373.  
  374. > If zero information related to the transactions needs to be transmitted
  375. > between peers, then the peers aren't making decisions of their own volition
  376. > related to the transactions included in a block.  If they're not making
  377. > decisions related to transactions then they're not really "peers" in my
  378. > opinion.  I see this as another example of how a single entity who controls
  379. > a lot of hash power can do various nasty stuff.
  380.  
  381. Thats not the example I'm making.
  382.  
  383. (Though the centeralization pressure you're talking about is a
  384. consideration you should have gone into too! -- but I think it's
  385. mostly mooted by the bigger issue I'm raising)
  386.  
  387.  
  388. > What is your definition of a peer?  To me, a peer needs to get information
  389. > from his other peers from which he makes his own independent decisions.
  390. > This information takes time to communicate.  If there's more transactions,
  391. > there's more information to communicate.  The only way this isn't true if
  392. > I'm not mistaken is if there's no information to communicate related to the
  393. > transactions in the block.  But like I said earlier, in this case then the
  394. > miner's aren't peers--they're just slaves--and the system is already
  395. > centralized.
  396.  
  397. I think you're stuck thinking in a particular model and I'm not sure
  398. how to break you out of it.
  399.  
  400. For example, I'm about to communicate the whole 40 some gigabytes of
  401. the Bitcoin blockchain to you:
  402.  
  403. 00000000000000001454fdecfdb2b18cc07bf759f759ce4d8cac3301dc98f478
  404.  
  405. As you can see, I was able to do that by communicating only 32bytes--
  406. and amount that I sent you here had no real dependence on the size of
  407. the blockchain.
  408.  
  409. This was possible because our computers had already agreed on the
  410. content of the blockchain before my communication to you happened.
  411.  
  412. Yes, communication did occur-- but not at the time of my transmission,
  413. it happened arbritarily before.  This is devistating for your analysis
  414. because you are working exclusively with the increased delay in
  415. transmission as a function of the blocksize as a mechenism for
  416. increasing orphaning resulting in an equlibrium profit maximizing
  417. size.  Data which they sent earlier may have some costs to them, but
  418. it does not have a cost in terms of increasing their orphan rate.
  419.  
  420. In that case I used data I didn't choose (the blockchain), but this
  421. works just as well for data I did choose: I could send you a gigabyte
  422. of data right now, then later send you an extranonce to append that
  423. makes the result have a low hash.
  424.  
  425. There are many ways to use this fundimental result, and the relay
  426. network protocol currently uses it in the simplest possible way.
  427. Ultimately, it means that its possible to construct schemes where
  428. miners retain choice but transmit a constant amount of information at
  429. the time of block announcement.
  430.  
  431. ----------
  432. From: Peter R <peter_r@gmx.com>
  433. Date: Wed, Aug 5, 2015 at 10:49 PM
  434. To: Gregory Maxwell <gmaxwell@gmail.com>
  435.  
  436.  
  437. Hi Greg,
  438.  
  439. OK I think I understand what you're saying.  I need to think more about it though.  One point already: wouldn't this strongly affect the miner's ability to include very recent transactions in a block?  A miner receives a transaction with a juicy fee, includes it, and then 1 second later solves the block.  New information needs to be communicated to his peers. The more recent TXs included, the more information.  Also, I can imagine how your scheme works if everyone agrees ahead of time exactly how they'll build blocks, but I don't see that it works if miner's are free to build blocks how they choose.
  440.  
  441. Off to bed...
  442.  
  443. Best regards,
  444. Peter
  445.  
  446. ----------
  447. From: Tom Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
  448. Date: Wed, Aug 5, 2015 at 11:45 PM
  449. To: bitcoin-dev@lists.linuxfoundation.org
  450.  
  451.  
  452. On 8/5/2015 3:44 PM, Dave Hudson via bitcoin-dev wrote:
  453. I do suspect that if we were to model this more accurately we might be able to infer the "typical" propagation characteristics by measuring the deviation from the expected distribution.
  454.  
  455. The paper models propagation using a single time value that is a function of block size.  Modeling the propagation distribution (which is totally separate from the poisson model of block production) would add a lot of complexity and my guess is the outcome would be little changed.
  456.  
  457.  
  458. On 5 Aug 2015, at 15:15, Peter R <peter_r@gmx.com> wrote:
  459. Although a miner may not orphan his own block, by building on his own block he may now orphan two blocks in a row.  At some point, his solution or solutions must be communicated to his peers.
  460.  
  461. Why complicate the analysis by assuming that a miner who finds two blocks sequentially does not publish the first, or that other miners would orphan miner's first block unless both were very quick?  In general you don't consider anything beyond 1 block in the future, which seems fine.
  462.  
  463.  
  464. I suspect this may well change some of the conclusions as larger block makers will definitely be able to create larger blocks than their smaller counterparts.
  465. It will be interesting to see.  I suspect that the main result that "a healthy fee market exists" will still hold (assuming of course that a single miner with >50% of the hash power isn't acting maliciously).  Whether miners with larger value of h/H have a profit advantage, I'm not sure (but that was outside the scope of the paper anyways).
  466.  
  467. Correcting for non-orphaning of one's own blocks could be as simple as adding a factor (1 - h/H) to equation 4, which it appears would leave hashpower as an independent variable in the results.  But at worst, the discussion can be considered to apply directly only to low-hashpower miners right now.
  468.  
  469. Overall, the paper does not predict big changes to per/kb fees or spam costs for the kinds of block sizes being discussed for the immediate future (8MB).  But it does conclude that these fees will rise, not fall, with bigger blocks.
  470.  
  471. Also it is welcome that this paper actually mentions the bitcoin exchange rate as a factor in relation to block size (it points out that a spam attack is much more expensive in fiat terms today than it was years ago).
  472.  
  473. ----------
  474. From: Gregory Maxwell <gmaxwell@gmail.com>
  475. Date: Wed, Aug 5, 2015 at 11:50 PM
  476. To: Peter R <peter_r@gmx.com>
  477.  
  478.  
  479. On Wed, Aug 5, 2015 at 10:49 PM, Peter R <peter_r@gmx.com> wrote:
  480. > OK I think I understand what you're saying.  I need to think more about it though.
  481.  
  482. Understood.  Enjoy your travels. (I should have said in my last
  483. message: sorry to nag about response times, I certantly understand.)
  484.  
  485. > One point already: wouldn't this strongly affect the miner's ability to include very recent transactions in a block?
  486.  
  487. It would. Though with the high varience in block finding (e.g. 10
  488. minutes expected but 1 hour blocks happen quite a few times a week) I
  489. don't think e.g. effectively having a second or two delay would be
  490. noticed by users at all. (actually there are already a bunch of delays
  491. in transaction handling that no one seems to care about-- e.g. until
  492. fairly recently each hop added up to 200ms delay just from sleeps in
  493. the networking code; thats part of why decker's propagation numbers
  494. are so high).
  495.  
  496. > A miner receives a transaction with a juicy fee, includes it, and then 1 second later solves the block.  New information needs to be communicated to his peers. The more recent TXs included, the more information.
  497.  
  498. Yes, new information needs to be conveyed in that case. At a cost;
  499. although: by using forward error correction we can make it so that the
  500. miner can convey information only proportional to the amount of
  501. missing data they're correcting, without actually knowing which data
  502. is specifically missing..  But all that gets you is a bound on how
  503. many __very__ (e.g.within seconds) new transactions a miner can
  504. profitably include... it's not relevant if the fees are fairly uniform
  505. and there is a backlog.
  506.  
  507. Speaking of backlog, if you're looking for other avenues your work
  508. didn't consider.  Think about the incentives of a miner once fees are
  509. larger than subsidy (which is something that could reasonably happen
  510. in just a few years) absent a block size limit. Instead of moving the
  511. chain forward, why doesn't he instead orphan the tip, take all its
  512. transactions and add the new ones that has come in since?    It's not
  513. hard to setup a situation where the chain only makes progress when a
  514. miner gets multiple blocks in a row (multiple depending on how much
  515. larger than subsidy the fees are).
  516.  
  517. > Also, I can imagine how your scheme works if everyone agrees ahead of time exactly how they'll build blocks, but I don't see that it works if miner's are free to build blocks how they choose.
  518.  
  519. I was giving a simplified example to make it easier to follow.  For
  520. example, even without agreeing on anything except the past history,
  521. each miner can announce their intent to all the other miners (using
  522. hashcash to prevent DOS), the communication overhead for this depends
  523. on how efficient the communication is (e.g. just differential with the
  524. intents of other miners?) but doesn't impact orphaning... if your
  525. intent is taking a long time to communicate you have some penalty how
  526. recent a transaction you can include without a marginal orphaning cost
  527. for that transaction.
  528.  
  529. ----------
  530. From: Peter R <peter_r@gmx.com>
  531. Date: Thu, Aug 6, 2015 at 7:34 AM
  532. To: Gregory Maxwell <gmaxwell@gmail.com>
  533.  
  534.  
  535. Hi Greg,
  536.  
  537. Thank you for your response.  I think you bring up some interesting points that readers should be made aware of.  Transforming your concerns to the language of my paper, I think you're challenging the claim that "gamma" [the coding gain with which block solutions are transmitted] can not be infinite (cf. Section 7).  Indeed, if gamma is infinite then the analysis breaks down.  
  538.  
  539. I propose the following changes:
  540.  
  541. 1.  I will make it more clear that the results of the paper hinge on the assumption that block solutions are propagated across channels, and that the quantity of pure information communicated per solution is proportional to the amount of information contained within the block.  
  542.  
  543. 2.  I will add a note [unless you ask me not to] something to the effect of "Greg Maxwell challenges the claim that the coding gain cannot be infinite…" followed by a summary of the scenario you described.  I will reference "personal communication."  I will also run the note by you before I make the next revision public.  
  544.  
  545. 3.  I will point out that if the coding gain can be made spectacularly high, that the propagation impedance in my model will become very small, and that although a fee market may strictly exist in the asymptotic sense, such a fee market may not be relevant (the phenomena in the paper would be negligible compared to the dynamics from some other effect).  
  546.  
  547. 4. [UNRELATED] I also plan to address Dave Hudson's objections in my next revision (the "you don't orphan your own block" point).  
  548.  
  549. Lastly, thank you for the note about what might happen when fees > rewards.  I've have indeed been thinking about this.  I believe it is outside the scope of the present paper, although I am doing some work on the topic. (Perhaps I'll add a bit more discussion on this topic to the present paper to get the reader thinking in this direction).
  550.  
  551. Best regards,
  552. Peter
  553.  
  554. ----------
  555. From: Gregory Maxwell <gmaxwell@gmail.com>
  556. Date: Sat, Aug 29, 2015 at 8:32 PM
  557. To: Peter R <peter_r@gmx.com>
  558.  
  559.  
  560. https://www.reddit.com/r/Bitcoin/comments/3iuz3r/on_the_nature_of_miner_advantages_in_uncapped/cujz46a
  561.  
  562. Again, I am disappointed find you posting on reddit without correcting
  563. factual statements which I know you know to be wrong.
  564.  
  565. E.g. in dpinna's paper, "PeterR has recently proven that unhealthy
  566. fee markets where a miner’s surplus continuously grows with block
  567. space are impossible. This is guarateed by the fact that while the fee
  568. demand curve is asymptotically linear for largeblock sizes (see (3)),"
  569.  
  570. You know that your "proof" of this problematic-- outright false under
  571. the discussion we had, or at least likely of little pratical relevance
  572. under reasonable, pratical assumptions.  But you respond to dpinna
  573. agreeing with him and not cautioning him on relying on these
  574. assumptions.
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top