rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2015-08-30 📝 Original message:On Sun, Aug 30, 2015 at 4:13 AM, Peter R <peter_r at gmx.com> wrote: > 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. If not for the other errors in your work, 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. 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. > -- Instead the same information can be transmitted _in advance_, as > has been previously proposed, and various techniques can make doing > so arbitrarily efficient. > > I assume, very reasonably, that the block solutions contain information > about the transactions included in the block. This is the case today, this > is the case using the relay network, and this would be the case using any > compression scheme I can personally imagine actually occurring in the > future. This assumption is unreasonable, and does not-- in fact-- accurately reflect the situation today. For example it does not reflect how hashers return work to pools _today_ (and since 2011) as they so to only by referencing the merkel root... the pool already knows the transaction set. In that particular case it knows it because it selected it to begin with, but the same behavior holds if the hasher selects the transaction set and sends it first. It only _very_ weakly reflects how the relay protocol works (only the selection and permutation is communicated; not the transaction data itself; for already known transactions). Even if you assume nothing more than that (in spite of the existing reality) you have not shown that the compressed data must be linear in the size of the block. It does not reflect how P2Pool works (which also sends the transactions in advance). There is a simple, and intuitive understanding that does not require any complex supposition: You argue that the information must be transfered when a block is found, thus delaying it. I point out, no, any required information (to the extent that there is any at all after efficient encoding) can be sent in advance of the block. I believe that you've allowed the fact that the specifc example block relay protocol doesn't bother sending _all_ information in advance to confuse it for mere compression. > My public comments have been factual. I've even gone out of my way in > several public threads to point out your objection that the coding gain > could be zero (even though I think it is flawed "black-and-white thinking" > about an academic scenario that will never unfold and might actually be > physically impossible without Bitcoin already being centralized). I believe my reponses are firmly grounded in the physical reality of actually deployed systems and constructable protocols. By comparison, even if I were to agree that the bound is not actually exactly 0 proporionality you have already agreed that with "compression" the amount sent could be arbritarily low. The result being that the behavior you're describing would only be asymptoic and have no relationship to the actual Bitcoin system that exists in a finite universe. But you continue to demand debate over this meaningless point. > I'll end by saying that I am the one describing things as the presently are. > You are talking about a hypothetical future that may or may not exist (and > may not even be possible). The results of my paper logically follow from > the assumptions made. You think the assumption that "block solutions contain > information about the transactions included in the block" will not hold in > the future. Can you show: > > (a) Under what assumptions/requirements your communication scheme is > physically possible. Pratically every block today is mined under a protocol which does not need to communicate anything but constant data when a block is found. I am getting a little tired of people suggesting things which are widely deployed are not physically possible. Yes, that particular example is not the most powerful form of that idea-- but it has the benefit of _universal_ use. > (b) That such a configuration is not equivalent to a single entity[1] > controlling >50% of the hash power. I find this a little amusing. Even in this messsage you defend ignoring of centeralization considerations in your paper. But here ask that I address concerns which you refused to suggest. Why do you demand my correction use weaker assumptions than your work? That said-- I already gave you a fairly concrete description of a pratical protocol which would accomplish your requirement ( (a) reduce the information transmitted in a latency critical way at block discovery time to O(1) network wide, (b) without creating centeralization in chain or transaction selection). I believe my description in the messages was adequate that anyone working on Bitcoin Core could go implement a version of it, at least. You appear to have simply ignrored it. If the actual technical details made your eyes glaze over I also offered a simple intutive understanding: The no proportional information need be transfered at the latency critical time, because it can be transfered in _advance_. Everything beyond that is just efficiency optimizations to reduce the cost of doing the advanced transmission. > (c) That the network moving into such a configuration is plausible. That it already uses advanced information techniques in every widely used mining protocol, that the relay protocol was rapidly adopted, and that your own model would suggest significant profits from any such improvement would seem to remove any doubt related to (c)... and again here you hold me to a higher bar than your own work: as nowhere do you show that the "limits" your model erroniously extracts are plausable as limits, and in private you seemed to admit to me that they may well not be.