* Re: [bitcoin-dev] Your Gmaxwell exchange [not found] ` <AD284610-4F40-445C-A074-CC94EDFFCBA8@gmx.com> @ 2015-08-30 3:25 ` Gregory Maxwell 2015-08-30 4:13 ` Peter R 0 siblings, 1 reply; 28+ messages in thread From: Gregory Maxwell @ 2015-08-30 3:25 UTC (permalink / raw) To: Peter R; +Cc: bitcoin-dev@lists•linuxfoundation.org Dev On Sun, Aug 30, 2015 at 1:43 AM, Peter R <peter_r@gmx•com> wrote: > 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 > below that proves this fact]. Unfortunately, your work extensive as it was made at least two non-disclosed or poorly-disclosed simplifying assumptions and a significant system understanding error which, I believe, undermined it completely. In short these were: * You assume miners do not have the ability to change their level centralization. -- In fact they do, not just in theory but in pratice have responded to orphaning this way in the past; and it is one of the major concerns in this space. * You assume the supply of bitcoin is infinite (that subsidy never declines) -- It declines geometrically, and must if the 21m limit is to be upheld. (Though I think this is not equally important as the other concerns) * You argue, incorrectly, that amount of information which must be transmitted at the moment a block is discovered is proportional to the block's size. -- Instead the same information can be transmitted _in advance_, as has been previously proposed, and various techniques can make doing so arbitrarily efficient. [I would encourage anyone who is interested to read the posted off-list discussion] I contacted you in private as a courtesy in the hope that it would be a more productive pathway to improving our collective understanding; as well as a courtesy to the readers of the list in consideration of traffic levels. In one sense, this was a success: Our conversation concluded with you enumerating a series of corrective actions that you would take: -------- > 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. > > 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. > > 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). > > 4. [UNRELATED] I also plan to address Dave Hudson's objections in my > next revision (the "you don't orphan your own block" point). > > 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). -------- To the best of my knowledge, you've taken none of these corrective actions in the nearly month that has passed. I certainly understand being backlogged, but you've also continued to make public comments about your work seemingly (to me) in contradiction with the above corrective actions. Today I discovered that another author spent their time extending your work and wasn't made aware of these points. A result was that the other author's work may require significant revisions. I complained about this to you, again privately, and your (apparent) response was to post to that thread stating that there was a details-unspecified academic disagreement with me and "I look forward to a white paper demonstrating otherwise!", in direct contradiction to your remarks to me three weeks ago in private correspondence: In private you said that your model may only hold in an asymptotic sense and that "the phenomena in the paper (may) be negligible compared to the dynamics from some other effect"; but in public you said /my/ position was "academic". At this point I thought continuing to withhold this information from the other author was unreasonable and no longer justified by courtesy to you, and I forwarded our complete discussion to the other author with the comment "I'll forward you a set of private correspondence that I've had with Peter R. I would recommend you take the time to read it and consider it.". I apologize if in doing so I've breached your confidence, none of the material we discussed was a sort that I would have ordinarily considered private, and you had already talked about making the product of our communication published as part of your corrective actions. I do not think it would be reasonable to demand that I spent time repeating the same discussion again with the other author, or deprive them of your side of it and/or the corrective actions which you had said you would take but have not yet taken. (In fact, I would argue that you were already obligated to share at least the substance of the discussion with the other author, both as part of your commitment to me as well it being necessiary for intellectual progress.) As you say, 'we are all here trying to learn about this new amazing thing called Bitcoin'; and I'm not embarrassed to error towards doing that and aiding others in doing so, but at the same time I am sorry to have done so in a way which caused you some injury. In any case, your prior proposed corrective actions seemed sufficient to me. It surprises me, greatly, that you are failing to see the extreme practicality of what I described to you, and that it does not meaningfully diminish miner control of transaction selection-- but even without it your remark that the proportionality could be arbitrarily small (Rather than 0, as I argue) is an adequate correction to your work, in my view. I believe my time would be better spent actually _implementing_ improved relaying described (and describe what was implemented) than continue a purely academic debate with you over the (IMO) inconsequential difference between epsilon and zero. Cheers, ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-30 3:25 ` [bitcoin-dev] Your Gmaxwell exchange Gregory Maxwell @ 2015-08-30 4:13 ` Peter R 2015-08-30 4:57 ` Gregory Maxwell 0 siblings, 1 reply; 28+ messages in thread From: Peter R @ 2015-08-30 4:13 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-dev@lists•linuxfoundation.org Dev [-- Attachment #1: Type: text/plain, Size: 6099 bytes --] Hi Greg, > Unfortunately, your work extensive as it was made at least two > non-disclosed or poorly-disclosed simplifying assumptions and a significant > system understanding error which, I believe, undermined it completely. > > In short these were: > > * You assume miners do not have the ability to change their level > centralization. > > -- In fact they do, not just in theory but in pratice have responded > to orphaning this way in the past; and it is one of the major > concerns in this space. I agree that miners may change their level of centralization. This neither affects the model nor the results presented in the paper. > * You assume the supply of bitcoin is infinite (that subsidy never > declines) > > -- It declines geometrically, and must if the 21m limit is to be upheld. > (Though I think this is not equally important as the other concerns) No I don't. I assume the inflation rate is R/T, where R is a variable. The last paragraph of the conclusion speaks to the paradox of what happens when R -> 0 as an area for future research. > * You argue, incorrectly, that amount of information which must be > transmitted at the moment a block is discovered is proportional to the > block's size. > > -- 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. (I've always agreed that if block solutions can be communicated to all of the hash power in such a way that they don't include any information about the transactions they contain, then the conditions for a healthy fee market would not be met [this would be gamma --> infinity in my model]). > [I would encourage anyone who is interested to read the posted off-list > discussion] As would I. > I contacted you in private as a courtesy in the hope that it would be > a more productive pathway to improving our collective understanding; as well > as a courtesy to the readers of the list in consideration of traffic levels. I appreciated the discussion we were having and I thought we had come to some kind of an understanding. I acknowledged that when I made the other corrections to my paper that I would further clarify the assumptions (I agreed that the presentation could be improved). What was not courteous was that you forwarded the entire private email chain to other people without my permission. > In one sense, this was a success: Our conversation concluded with you > enumerating a series of corrective actions that you would take: > > -------- >> 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. >> >> 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. >> >> 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). >> >> 4. [UNRELATED] I also plan to address Dave Hudson's objections in my >> next revision (the "you don't orphan your own block" point). >> >> 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). I stand by all of these four points. My paper wasn't perfectly presented. Making these clarifications will strengthen the manuscript by showing how strong the claim "a healthy transaction fee market exists without a block size limit" is. > To the best of my knowledge, you've taken none of these corrective > actions in the nearly month that has passed. I certainly understand being > backlogged, but you've also continued to make public comments about your > work seemingly (to me) in contradiction with the above corrective actions. 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'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. (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. Best regards, Peter [-- Attachment #2: Type: text/html, Size: 7360 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-30 4:13 ` Peter R @ 2015-08-30 4:57 ` Gregory Maxwell 2015-08-30 6:38 ` Adam Ritter 2015-08-30 7:41 ` Peter R 0 siblings, 2 replies; 28+ messages in thread From: Gregory Maxwell @ 2015-08-30 4:57 UTC (permalink / raw) To: Peter R; +Cc: bitcoin-dev@lists•linuxfoundation.org Dev On Sun, Aug 30, 2015 at 4:13 AM, Peter R <peter_r@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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-30 4:57 ` Gregory Maxwell @ 2015-08-30 6:38 ` Adam Ritter 2015-08-31 18:55 ` Justus Ranvier 2015-09-01 2:30 ` Oliver Petruzel 2015-08-30 7:41 ` Peter R 1 sibling, 2 replies; 28+ messages in thread From: Adam Ritter @ 2015-08-30 6:38 UTC (permalink / raw) To: bitcoin-dev@lists•linuxfoundation.org Dev I don't really see any problem with the paper: All it states is that having the assumption that miners don't centralize, transaction fees don't go to zero even without the blocksize limit. I think we can accept this as a nice academic research, and I believe that it's true. Still, it doesn't have anything that is practical for me as an user of the Bitcoin network (I use it for storing long-term purchase value, as most of the people who I know): it doesn't help me if I still need to pay transaction fees after the blocksize limit is gone. My (and other users') main concern is about centralization, which has nothing to do with transaction fees. I would be OK with $100 transaction fee as well, as long as the network is fair and secure (which comes from decentralization). ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 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-01 2:30 ` Oliver Petruzel 1 sibling, 2 replies; 28+ messages in thread From: Justus Ranvier @ 2015-08-31 18:55 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1.1: Type: text/plain, Size: 1827 bytes --] On 08/30/2015 01:38 AM, Adam Ritter via bitcoin-dev wrote: > Still, it doesn't have anything that is practical for me as an user of > the Bitcoin network (I use it for storing long-term purchase value, as > most of the people who I know): it doesn't help me if I still need to > pay transaction fees after the blocksize limit is gone. My (and other > users') main concern is about centralization, which has nothing to do > with transaction fees. I would be OK with $100 transaction fee as > well, as long as the network is fair and secure (which comes from > decentralization). I don't believe that any Bitcoin user actually cares about decentralization, because none of them I've asked can define that term. "decentralization" has become a placeholder word for "features or ideas that I like" and it's long past time to drag the discussion back into the realm of concrete and achievable goals. I think there are a few specific things we can surmise about what users might mean when they say they want Bitcoin to be "decentralized": * They should own their bitcoins, meaning that they retain exclusive control over their balances. Even more precisely, the network must always honour the conditions of the scripts associated with unspent outputs. * Their fraction of the Bitcoin ledger must not be diluted. * When they decide to spend their coins, they will be able to do so without requiring permission from a third party. A decentralized architecture in certain parts of the network can be helpful for achieving those goals, but it is not always necessary, nor is it always sufficient to achieve them. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ justus@openbitcoinprivacyproject•org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18667 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 18:55 ` Justus Ranvier @ 2015-08-31 19:11 ` Mike Hearn 2015-09-01 20:29 ` Wladimir J. van der Laan 1 sibling, 0 replies; 28+ messages in thread From: Mike Hearn @ 2015-08-31 19:11 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 721 bytes --] I think your summary of what people actually want from decentralisation is pretty good, Justus. > I don't believe that any Bitcoin user actually cares > about decentralization, because none of them I've asked can define that > term. > +1 Insightful It's been quite impressive to see so many Bitcoin users and developers saying, "Bitcoin is totally decentralised because it's open source and nobody is in charge...... oh nooooooo we didn't mean you could change *those lines! *If you want to change *those lines* then *we* must agree first!" Believing simultaneously that: 1. Bitcoin is decentralised 2. Nobody should modify the code in certain ways without the agreement of me and my buddies is just doublethink. [-- Attachment #2: Type: text/html, Size: 1190 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 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 1 sibling, 1 reply; 28+ messages in thread From: Wladimir J. van der Laan @ 2015-09-01 20:29 UTC (permalink / raw) To: Justus Ranvier; +Cc: bitcoin-dev On Mon, Aug 31, 2015 at 01:55:43PM -0500, Justus Ranvier via bitcoin-dev wrote: > * They should own their bitcoins, meaning that they retain exclusive > control over their balances. Even more precisely, the network must > always honour the conditions of the scripts associated with unspent outputs. > > * Their fraction of the Bitcoin ledger must not be diluted. > > * When they decide to spend their coins, they will be able to do so > without requiring permission from a third party. All of these properties are contingent on the system being decentralized. Asking random end-users if they care if bitcoin is decentralized is like asking random people if they care if their drinking water is dihydrogen monoxide. Both miner and full node over-centralization could result in - Permission requirements to submit transactions (miners can be pressured to adhere to KYC rules) - Transactions being reversed without consent (reorgs by the miner cartel) - ...even dilution of their fraction of their ledger (if changing the rules becomes normal, I'm sure some smoothtalker could come up with arguments to raise the 21M cap. Another option would be to force the remaining people that are able to run full nodes to comply) Bitcoin's properties don't come from magic. All its attractive properties are derived from decentralization, on spreading responsibility as widely globally as possible. Without that, it's just an inefficient ledger database. Wladimir ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-09-01 20:29 ` Wladimir J. van der Laan @ 2015-09-02 18:51 ` Justus Ranvier 0 siblings, 0 replies; 28+ messages in thread From: Justus Ranvier @ 2015-09-02 18:51 UTC (permalink / raw) To: Wladimir J. van der Laan; +Cc: bitcoin-dev [-- Attachment #1.1: Type: text/plain, Size: 1701 bytes --] On 09/01/2015 03:29 PM, Wladimir J. van der Laan wrote: > On Mon, Aug 31, 2015 at 01:55:43PM -0500, Justus Ranvier via bitcoin-dev wrote: > >> * They should own their bitcoins, meaning that they retain exclusive >> control over their balances. Even more precisely, the network must >> always honour the conditions of the scripts associated with unspent outputs. >> >> * Their fraction of the Bitcoin ledger must not be diluted. >> >> * When they decide to spend their coins, they will be able to do so >> without requiring permission from a third party. > > All of these properties are contingent on the system being decentralized. That is not true, unless you are using a definition of the word "decentralized" which is so broad as to convey no information whatsoever. Saying that Bitcoin's security depends on decentralization is like saying that a bridge's structural integrity depends on good materials. Statements like that convey zero relevant information. Potential users of a bridge want to know about the maximum working load of the bridge, and under which conditions it is safe to use. At what wind speed should the bridge be closed? Is it ok to keep using it after a magnitude 4 earthquake, or should it be closed for inspection? Repeatedly asserting that bridges need to be made of good materials as an alternative to answering those kinds of questions would be easily recognized as useless in that context, but for some reason people seem to accept it in this one. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ justus@openbitcoinprivacyproject•org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18667 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-30 6:38 ` Adam Ritter 2015-08-31 18:55 ` Justus Ranvier @ 2015-09-01 2:30 ` Oliver Petruzel 1 sibling, 0 replies; 28+ messages in thread From: Oliver Petruzel @ 2015-09-01 2:30 UTC (permalink / raw) To: Adam Ritter; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2299 bytes --] >>>I would be OK with $100 transaction fee Unless you're relying upon some hypothetical hyper-inflation of the USD, how does one accept or justify such fees given the title (and intentions) of Satoshi's own white paper and corresponding software? I believe the key words "cash system" must be kept in mind throughout all of these discussions and developments, or else we risk turning Bitcoin into something other than cash. Bitcoin will no longer be a P2P cash system if the fees make transactions prohibitively expensive for all but the wealthiest of individuals and corporations. I understand that a careful balance must be struck between (measurable?) decentralization and Bitcoin's use as an actual cash system; however, those who are willing to annihilate the latter to maintain ONLY the former must at least be honest with everyone that they really don't care if Bitcoin becomes something entirely different than Satoshi's original invention and intention. Call it a necessary transformation or reinvention, and by a new name, if you will; because, with exorbitant fees, it may no longer be accurate or appropriate to call it Bitcoin: A Peer-to-peer Electronic CASH System. Respectfully, Oliver On Aug 30, 2015 2:38 AM, "Adam Ritter via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > I don't really see any problem with the paper: > All it states is that having the assumption that miners don't > centralize, transaction fees don't go to zero even without the > blocksize limit. I think we can accept this as a nice academic > research, and I believe that it's true. > Still, it doesn't have anything that is practical for me as an user of > the Bitcoin network (I use it for storing long-term purchase value, as > most of the people who I know): it doesn't help me if I still need to > pay transaction fees after the blocksize limit is gone. My (and other > users') main concern is about centralization, which has nothing to do > with transaction fees. I would be OK with $100 transaction fee as > well, as long as the network is fair and secure (which comes from > decentralization). > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 2953 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-30 4:57 ` Gregory Maxwell 2015-08-30 6:38 ` Adam Ritter @ 2015-08-30 7:41 ` Peter R 1 sibling, 0 replies; 28+ messages in thread From: Peter R @ 2015-08-30 7:41 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-dev@lists•linuxfoundation.org Dev [-- 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 --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange
@ 2015-08-31 20:06 Monarch
2015-08-31 20:27 ` Justus Ranvier
0 siblings, 1 reply; 28+ messages in thread
From: Monarch @ 2015-08-31 20:06 UTC (permalink / raw)
To: hearn; +Cc: bitcoin-dev
On 2015-08-31 19:11, Mike Hearn via bitcoin-dev wrote:
> I think your summary of what people actually want from
> decentralisation is pretty good, Justus.
>
>
>> I don't believe that any Bitcoin user actually cares
>> about decentralization, because none of them I've asked can define
>> that term.
>
> +1 Insightful
>
What is Bitcoin if not decentralized?
Bitcoin the most awkward, unprivate and damaging currencies ever
created. It is terribly slow for general use, and it is very
difficult for users to get over the technical hurdles required to use
it safety. It is simultaneously the least private payment system ever
conceived for general use, yet still manages to consistently help
terrorists and pedophiles. Over half a gigawatt of power is used to
power the miners which timestamp the network, causing hundreds of
millions of tonnes of CO2 and radioactive particles to be spewed into
the atmosphere.
Perhaps we can justify these damages as the cost of decentralization,
similar to one justifying the tor anonymity network as having
significant positive effects outweighing the negative. However if you
are truly willing to give the goal of absolute decentralization up as
unachievable or unrealistic, it would be much more sensible to replace
the entire Bitcoin network with a couple of geographically distributed
SQL servers and call it a day.
Without decentralization as an ultimate goal, Bitcoin is an
abomination that is best dismantled.
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 20:06 Monarch @ 2015-08-31 20:27 ` Justus Ranvier 2015-08-31 20:48 ` Monarch 0 siblings, 1 reply; 28+ messages in thread From: Justus Ranvier @ 2015-08-31 20:27 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1.1: Type: text/plain, Size: 1990 bytes --] On 08/31/2015 03:06 PM, Monarch via bitcoin-dev wrote: > What is Bitcoin if not decentralized? > > Bitcoin the most awkward, unprivate and damaging currencies ever > created. It is terribly slow for general use, and it is very > difficult for users to get over the technical hurdles required to use > it safety. It is simultaneously the least private payment system ever > conceived for general use, yet still manages to consistently help > terrorists and pedophiles. Over half a gigawatt of power is used to > power the miners which timestamp the network, causing hundreds of > millions of tonnes of CO2 and radioactive particles to be spewed into > the atmosphere. > > Perhaps we can justify these damages as the cost of decentralization, > similar to one justifying the tor anonymity network as having > significant positive effects outweighing the negative. However if you > are truly willing to give the goal of absolute decentralization up as > unachievable or unrealistic, it would be much more sensible to replace > the entire Bitcoin network with a couple of geographically distributed > SQL servers and call it a day. > > Without decentralization as an ultimate goal, Bitcoin is an > abomination that is best dismantled. You don't understand what value proof of work provides, or what features differentiate good money from poor money, and you can't make a defensible statement of Bitcoin's value proposition. Because you can't do these things, you assume nobody else can do them either and therefore the only way for Bitcoin to survive is to sweep the problem under the rug and distract users with a word that means nothing (and therefore means whatever the observer wants it to mean). This is not a strategy that can be successful in the long term. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ justus@openbitcoinprivacyproject•org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18667 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 20:27 ` Justus Ranvier @ 2015-08-31 20:48 ` Monarch 2015-08-31 21:24 ` Allen Piscitello 0 siblings, 1 reply; 28+ messages in thread From: Monarch @ 2015-08-31 20:48 UTC (permalink / raw) To: Justus Ranvier; +Cc: bitcoin-dev On 2015-08-31 20:27, Justus Ranvier wrote: > You don't understand what value proof of work provides, or what > features > differentiate good money from poor money, and you can't make a > defensible statement of Bitcoin's value proposition. > > Because you can't do these things, you assume nobody else can do them > either and therefore the only way for Bitcoin to survive is to sweep > the > problem under the rug and distract users with a word that means nothing > (and therefore means whatever the observer wants it to mean). > > This is not a strategy that can be successful in the long term. Proof of work is probabilistic transaction ordering (and timestamping by extension), the only perceivable value in it is that it is decentralized. If you don't have that set as a requirement there are plenty of companies around who will act as a time stamping notary for you, just as there are many cloud services around to host the SQL- based Bitcoin replacement. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 20:48 ` Monarch @ 2015-08-31 21:24 ` Allen Piscitello 2015-08-31 21:42 ` Monarch 2015-08-31 23:32 ` Peter R 0 siblings, 2 replies; 28+ messages in thread From: Allen Piscitello @ 2015-08-31 21:24 UTC (permalink / raw) To: Monarch; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1420 bytes --] Even so, decentralization is a means to an end - not an end-goal. It is essential for Bitcoin to be a useful alternative, of course. On Mon, Aug 31, 2015 at 3:48 PM, Monarch via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On 2015-08-31 20:27, Justus Ranvier wrote: > >> You don't understand what value proof of work provides, or what features >> differentiate good money from poor money, and you can't make a >> defensible statement of Bitcoin's value proposition. >> >> Because you can't do these things, you assume nobody else can do them >> either and therefore the only way for Bitcoin to survive is to sweep the >> problem under the rug and distract users with a word that means nothing >> (and therefore means whatever the observer wants it to mean). >> >> This is not a strategy that can be successful in the long term. >> > > > Proof of work is probabilistic transaction ordering (and timestamping > by extension), the only perceivable value in it is that it is > decentralized. If you don't have that set as a requirement there are > plenty of companies around who will act as a time stamping notary for > you, just as there are many cloud services around to host the SQL- > based Bitcoin replacement. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 2184 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 21:24 ` Allen Piscitello @ 2015-08-31 21:42 ` Monarch 2015-08-31 21:54 ` Justus Ranvier 2015-08-31 23:32 ` Peter R 1 sibling, 1 reply; 28+ messages in thread From: Monarch @ 2015-08-31 21:42 UTC (permalink / raw) To: Allen Piscitello; +Cc: bitcoin-dev On 2015-08-31 21:24, Allen Piscitello wrote: > Even so, decentralization is a means to an end - not an end-goal. It > is essential for Bitcoin to be a useful alternative, of course. > The justification for the existence of Bitcoins hinges on it. What is described in the whitepaper is a system without the trust of third parties to process electronic payments, this can not exist without decentralization. Absent any unforseen revelations this is a requirement rather than a suggestion or fleeting fancy. Below a decentralized Bitcoin you are free to make systems as centralized as you please without affecting the parent, below a centralized Bitcoin there is no room to make it less. We really only have one shot at a properly bootstrapped, decentralized currency, and it would be a great shame to mess up the one we have with hasty decision making for unclear goals. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 21:42 ` Monarch @ 2015-08-31 21:54 ` Justus Ranvier 2015-08-31 22:53 ` Monarch 2015-09-01 9:25 ` Jorge Timón 0 siblings, 2 replies; 28+ messages in thread From: Justus Ranvier @ 2015-08-31 21:54 UTC (permalink / raw) To: Monarch, Allen Piscitello; +Cc: bitcoin-dev [-- Attachment #1.1: Type: text/plain, Size: 1849 bytes --] On 08/31/2015 04:42 PM, Monarch wrote: > The justification for the existence of Bitcoins hinges on it. What is > described in the whitepaper is a system without the trust of third > parties to process electronic payments, this can not exist without > decentralization. Absent any unforseen revelations this is a > requirement rather than a suggestion or fleeting fancy. Below a > decentralized Bitcoin you are free to make systems as centralized as > you please without affecting the parent, below a centralized Bitcoin > there is no room to make it less. We really only have one shot at a > properly bootstrapped, decentralized currency, and it would be a great > shame to mess up the one we have with hasty decision making for > unclear goals. You keep using the word "decentralized" without explaining (and most likely, understanding) what it means. You say: > a system without the trust of third parties to process electronic payments What does it mean to use a decentralized network instead of a trusted third party to process electronic payments? What undesirable actions can a trusted third party perform that a decentralized network can not perform? The answer to those questions are the *actual* goals, for which decentralization is just one portion of a solution. It might be helpful to organize Bitcoin's various existing, potential, rejected, and proposed features using the Kano model: https://en.wikipedia.org/wiki/Kano_model Example: The ability of one entity to spend another entity's Bitcoins without their consent is a reverse quality. It would at least give us something objective to talk about. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ justus@openbitcoinprivacyproject•org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18667 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 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 1 sibling, 2 replies; 28+ messages in thread From: Monarch @ 2015-08-31 22:53 UTC (permalink / raw) To: Justus Ranvier; +Cc: bitcoin-dev On 2015-08-31 21:54, Justus Ranvier wrote: > > You keep using the word "decentralized" without explaining (and most > likely, understanding) what it means. > Decentralization is a ubiquitous term within the Bitcoin, and the definition is by no measure new or often confused. It is realizing that systems involving trusted third parties have undesirable properties, be it regarding privacy, fraud, censorship, and removing the effect of them as much as is physically possible. WASTE and RetroShare are examples of decentralized messaging and file distribution systems, acknowledging the privacy problems involved with centralized systems like AOL Instant Messenger or IRC. > What does it mean to use a decentralized network instead of a trusted > third party to process electronic payments? What undesirable actions > can > a trusted third party perform that a decentralized network can not > perform? > Bitcoin is a decentralized currency which allows any person the ability to transact in a way that does not require specific trust in any particular party. Users can independently verify that transactions they receive are valid and confirmed, with strong confidence that they can not be reversed or modified. A third party does not hold these same properties, there is no reason to believe the information they present other than trust they will not lie, cheat, or violate privacy at their own will. Given information by a trusted third party (such as a balance or existance of transaction), a person has no ability to independently validate their claims as you do in a decentralized system. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 22:53 ` Monarch @ 2015-08-31 23:24 ` Justus Ranvier 2015-09-01 0:02 ` Milly Bitcoin 1 sibling, 0 replies; 28+ messages in thread From: Justus Ranvier @ 2015-08-31 23:24 UTC (permalink / raw) To: Monarch; +Cc: bitcoin-dev [-- Attachment #1.1: Type: text/plain, Size: 3579 bytes --] On 08/31/2015 05:53 PM, Monarch wrote: > > Bitcoin is a decentralized currency which allows any person the > ability to transact in a way that does not require specific trust in > any particular party. Users can independently verify that > transactions they receive are valid and confirmed, with strong > confidence that they can not be reversed or modified. A third party > does not hold these same properties, there is no reason to believe the > information they present other than trust they will not lie, cheat, or > violate privacy at their own will. Given information by a trusted > third party (such as a balance or existance of transaction), a person > has no ability to independently validate their claims as you do in a > decentralized system. This is on the right track, but still falls short in a few areas. It's a false dichotomy to say that our choices are: Bitcoin as it exists today (or in some theoretical perfect state of decentralization), or an Excel spreadsheet edited by a trusted third party who can change any number to be any other number they want. Imagine there was only one miner in the network. In spite of being the sole entity creating the blockchain there would still be many actions they could *not* do: * Falsify ECDSA signatures * Generate proof of work without expending energy * Produce blocks that non-mining nodes would recognize as including invalid transactions (including printing themselves unlimited balances) * Force other people to purchase the coins they mine so that they can pay their electric bills What they *can* do is: * Defraud recipients of transactions by including a payment transaction in a block, then orphaning that block with another block that contains a conflicting transaction (double spend). There is usually*** a cost to performing this attack, so miners would only be expected to do it if the benefit exceeds the cost. * Prevent the inclusion of valid transactions into any block using any criteria they want. The worse case scenario for mining monopolization is that the risk of profitable double spends means that transactions might require more confirmations to be reliable, and that some entity can censor transactions at will. Those aren't exactly end-of-the world failure cases. They are certainly undesirable and every means of preventing them should be investigated, but it does mean that it should be possible to dial back on the catastrophe language when analysing possible failure modes. The weakest area for Bitcoin to be attacked is via censorship enforced by miners. The first line of defence is to improve the privacy features of wallets to the point at which blacklists are not effective. I'm confident that this can be achieved. That leaves the censors with the choice of whether or not to escalate to whitelisting, which ultimately can be countered by users switching to a new system which does not have that particular anti-feature. tl;dr: Bitcoin security does not lie on a one-dimensional "centralized vs decentralized" axis. Treating it as if it does removes the clarity that is needed in order to effectively solve problems. ***Exploring the exact conditions under which this is true is an interesting exercise and relevant to long term discussions vis a vis the block subsidy and transaction fees in the future. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ justus@openbitcoinprivacyproject•org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18667 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 22:53 ` Monarch 2015-08-31 23:24 ` Justus Ranvier @ 2015-09-01 0:02 ` Milly Bitcoin 1 sibling, 0 replies; 28+ messages in thread From: Milly Bitcoin @ 2015-09-01 0:02 UTC (permalink / raw) To: bitcoin-dev > Bitcoin is a decentralized currency which allows any person the > ability to transact in a way that does not require specific trust in > any particular party. Bitcoin is only a partial solution to the Byzantine general problem. Users do need to trust that things such as mining and development systems work as intended. Once the user trusts those systems only then is the state of the ledger trustless. Just because the state of ledger is decentralized due to mining that does not automatically mean everything associated with Bitcoin is "decentralized." (Some people actually claim reddit is decentralized because users can vote. That would mean the US government is also decentralized since there are elections but i don't think most people would agree with that definition.) Centralized and decentralized system are not intrinsically good or bad. Each one has it use cases just like a hammer and a screw driver. Claiming otherwise is treating Bitcoin a as religion rather than a technology. Russ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 21:54 ` Justus Ranvier 2015-08-31 22:53 ` Monarch @ 2015-09-01 9:25 ` Jorge Timón 1 sibling, 0 replies; 28+ messages in thread From: Jorge Timón @ 2015-09-01 9:25 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1187 bytes --] On Aug 31, 2015 3:01 PM, "Justus Ranvier via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > You keep using the word "decentralized" without explaining (and most > likely, understanding) what it means. I believe he explained very well what he meant by decentralized, please stop suggesting he doesn't understand his own thoughts: it is extremely irritating. > You say: > > > a system without the trust of third parties to process electronic payments > > What does it mean to use a decentralized network instead of a trusted > third party to process electronic payments? What undesirable actions can > a trusted third party perform that a decentralized network can not perform? For starters, a third party (or a recuded group of miners controlling the majority of the hashrate) can censor transactions. It doesn't matter how benevolent that party is: it can be forced to do it by the laws of its jurisdiction. If you don't care about this, I suggest you start a new system without expensive proof of work, you can replace it with block signing (it can still be multisig). It is already coded, just fork the alpha or the blocksigning branch in elementsProject (github). [-- Attachment #2: Type: text/html, Size: 1461 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 21:24 ` Allen Piscitello 2015-08-31 21:42 ` Monarch @ 2015-08-31 23:32 ` Peter R 2015-08-31 23:47 ` s7r 2015-09-01 11:11 ` Monarch 1 sibling, 2 replies; 28+ messages in thread From: Peter R @ 2015-08-31 23:32 UTC (permalink / raw) To: Allen Piscitello; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1079 bytes --] On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Even so, decentralization is a means to an end - not an end-goal. It is essential for Bitcoin to be a useful alternative, of course. I agree. What about decentralization in development? Gavin recently said that he wants to "get to the point where there will be multiple robust implementations of the core protocol." When I look at this image (https://i.imgur.com/zivHJvY.gif) illustrating centralization in nodes, mining and development, the biggest source of concern for me is the 85% node share around Bitcoin Core. With this level of centralization, it may be possible in the future for a group of coders to prevent important changes from being made in a timely fashion (e.g., should their interests no longer align with those of the larger Bitcoin community). It is my opinion, then, that we should support multiple implementations of the Bitcoin protocol, working to reduce the network's dependency on Core. Best regards, Peter R [-- Attachment #2: Type: text/html, Size: 1682 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 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 1 sibling, 1 reply; 28+ messages in thread From: s7r @ 2015-08-31 23:47 UTC (permalink / raw) To: Peter R, Allen Piscitello; +Cc: bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Decentralization depends on the context and does not have a definition in a form that it was demanded... I can confirm we have people in our community which do understand decentralization, and quite good actually, just there is no definition if the form demanded. It is known that ~90% (at least of the nodes accepting incoming connections) are running Bitcoin Core software. This does not mean that Bitcoin is somehow less decentralized. Bitcoin Core is open source, it has many contributors from all over the world and there are many pull requests - most of them do get merged if you check the commit history. It is widely used because the quality of the code is 5 stars. There are other implementations as well, they are just not widely used. This does not mean one is not free to write his own implementation of the Bitcoin protocol (assuming he follows the consensus rules of the network). The biggest problem is convincing users to adopt that implementation, which is a normal thing which happens in general, not only related to software implementations. The problem is there is no other implementation out there which comes near the quality of the code in Bitcoin Core. I am actually eager to try other implementations as well, but something serious, because Bitcoin itself is a payment protocol not something to play with. This is the reason why a lot of developers contribute to Bitcoin Core rather than writing their own implementation. This only makes Bitcoin Core stronger, better, and obviously the result is that it has majority in the ecosystem for good reasons. If I'm experienced in a certain segment related to software developing, I am better of in contributing to Bitcoin Core just with the part I know instead of writing from scratch my own implementation. On 9/1/2015 2:32 AM, Peter R via bitcoin-dev wrote: > On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > >> Even so, *decentralization is a means to an end* - not an >> end-goal. It is essential for Bitcoin to be a useful alternative, >> of course. > > I agree. What about decentralization in development? Gavin > recently said that he wants to "get to the point where there will > be multiple robust implementations of the core protocol." > > When I look at this image (https://i.imgur.com/zivHJvY.gif) > illustrating centralization in nodes, mining and development, the > biggest source of concern for me is the 85% node share around > Bitcoin Core. With this level of centralization, it may be > possible in the future for a group of coders to prevent important > changes from being made in a timely fashion (e.g., should their > interests no longer align with those of the larger Bitcoin > community). > > It is my opinion, then, that we should support multiple > implementations of the Bitcoin protocol, working to reduce the > network's dependency on Core. > > Best regards, Peter R > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJV5OeqAAoJEIN/pSyBJlsRRsoIAMmdyeE+Sro14NIHy6jQqTH3 JdkhUg6lg7S58tqs7ahQ/U2QGMPLaQae9yv3NidKpyqzL0YXtc2+r7RDBp0p2L4O ieBJfJRBDwjjHYun+h7VTkPRbFGoBs/vwtTahd+uxUjwdEhiOxI2Q8pY8dLbdmJz 5lyA3TIcOVy3FjGYp3ji8aBQkw4o9OZbgmY/iCmVONgup96+81/FdR8P6wwdi3tg Hep+4iU5Z+RHVE0sQhJDgl8Rw2oY6cmfxOCdFalRAASfZClkMfZok7eDE5yWtUbE tn9tEP82tc3OwZCC+XvpVggVWnCp/rGZFslfTdiWXWeLXhs+JLf0hWet4/SWCT0= =zQ9s -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 23:47 ` s7r @ 2015-09-01 11:44 ` Monarch 0 siblings, 0 replies; 28+ messages in thread From: Monarch @ 2015-09-01 11:44 UTC (permalink / raw) To: bitcoin-dev On 2015-08-31 23:47, s7r via bitcoin-dev wrote: > The problem is there is no other implementation out there which comes > near the quality of the code in Bitcoin Core. I am actually eager to > try other implementations as well, but something serious, because > Bitcoin itself is a payment protocol not something to play with. > I don't think code quality is of a particular problem in alternate implementations, the difficulty of getting it right is simply astronomical. If you attempt to re-implement just transaction signature verification you run into edge cases remarkably quickly, most use of Bitcoin today barely scratches the surface of what was added to Bitcoin for future expansion. https://jonasnick.github.io/blog/2015/05/09/fuzzing-bitcoin-consensus/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-08-31 23:32 ` Peter R 2015-08-31 23:47 ` s7r @ 2015-09-01 11:11 ` Monarch 2015-09-01 15:59 ` Dave Collins 1 sibling, 1 reply; 28+ messages in thread From: Monarch @ 2015-09-01 11:11 UTC (permalink / raw) To: Peter R; +Cc: bitcoin-dev On 2015-08-31 23:32, Peter R wrote: > On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > It is my opinion, then, that we should support multiple > implementations of the Bitcoin protocol, working to reduce the > network's dependency on Core. > That would be incredibly foolish given the history, where even heroic attempts at making consensus compatible re-implementations have ended rather poorly. bitcoin-ruby and btcd have collectively had numerous consensus failures, some only recently found by fuzzing the scripting environment. There are more failures than publicly disclosed, and almost any failure can be leveraged to split the network and steal money. Ethereum attempted to create four clients, written to a defined specification, and even with all the money in the world has managed to have numerous consensus failures due to misunderstanding or implementation. > I agree. What about decentralization in development? Gavin recently > said that he wants to "get to the point where there will be multiple > robust implementations of the core protocol." > Gavin clearly hasn't kept up with the ridiculousness of that task. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-09-01 11:11 ` Monarch @ 2015-09-01 15:59 ` Dave Collins 2015-09-01 16:51 ` Monarch 0 siblings, 1 reply; 28+ messages in thread From: Dave Collins @ 2015-09-01 15:59 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2127 bytes --] I'd be interested to know about these supposed btcd mainnet forks that have occurred due to a consensus failure since it came out of alpha. I'll go ahead and save you some research time - there hasn't been one. I'm not claiming there will never be one as that would be just as foolish as claiming Bitcoin Core won't have any more either. As you alluded to, there was a _potential_ instance found due to fuzzing which prompted a thorough audit of the code base. It was fixed before any problems occurred and resulted in improved test coverage in Bitcoin Core as well. On the other hand, Bitcoin Core has had actual forks on mainnet during the same period. I'm not casting stones at Bitcoin Core here, because as I've said many times, none of us are perfect. No matter how careful everyone is, it is bound to happen from time to time. Until this community decides to get serious about facing the reality that an infrastructure built on a single implementation with no real disaster prevention measures for unintentional incompatibilities between different versions of that implementation is incredibly fragile, there will continue to be more unintentional hard forks regardless of the existence of alternative implementations. It has not ended poorly by any means. It has already led to several improvements such as improved test coverage and more robust and modular code. On 9/1/2015 6:11 AM, Monarch via bitcoin-dev wrote: > That would be incredibly foolish given the history, where even heroic > attempts at making consensus compatible re-implementations have ended > rather poorly. bitcoin-ruby and btcd have collectively had numerous > consensus failures, some only recently found by fuzzing the scripting > environment. There are more failures than publicly disclosed, and > almost any failure can be leveraged to split the network and steal > money. Ethereum attempted to create four clients, written to a > defined specification, and even with all the money in the world has > managed to have numerous consensus failures due to misunderstanding or > implementation. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 834 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-09-01 15:59 ` Dave Collins @ 2015-09-01 16:51 ` Monarch 2015-09-01 18:37 ` Eric Voskuil 0 siblings, 1 reply; 28+ messages in thread From: Monarch @ 2015-09-01 16:51 UTC (permalink / raw) To: bitcoin-dev On 2015-09-01 15:59, Dave Collins via bitcoin-dev wrote: > I'd be interested to know about these supposed btcd mainnet forks that > have occurred due to a consensus failure since it came out of alpha. > I'll go ahead and save you some research time - there hasn't been one. > I'm not claiming there will never be one as that would be just as > foolish as claiming Bitcoin Core won't have any more either. > For the purposes of the conversation this was only brought up to re- enforce my claim that this is outrageously difficult software development, irrespective of the quality of the code being produced in alternate implementations. Sorry if that came across as an attack against your software in particular, it wasn't intended. > On the other hand, Bitcoin Core has had actual forks on mainnet during > the same period. I'm not casting stones at Bitcoin Core here, because > as I've said many times, none of us are perfect. No matter how careful > everyone is, it is bound to happen from time to time. > The point I was trying to make is that this is simply a hard development situation to be working in, we don't know what behavior is inferred by the use of CPP and even more so OpenSSL (as the DER encoding consensus failure made abundantly clear). There's almost certainly more problems lying around given how generally dusty a lot of the transaction environment is, it's very easy to get off the beaten track with Bitcoin script. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-09-01 16:51 ` Monarch @ 2015-09-01 18:37 ` Eric Voskuil 2015-09-01 20:08 ` Monarch 0 siblings, 1 reply; 28+ messages in thread From: Eric Voskuil @ 2015-09-01 18:37 UTC (permalink / raw) To: Monarch, bitcoin-dev, libbitcoin [-- Attachment #1: Type: text/plain, Size: 2210 bytes --] On 09/01/2015 09:51 AM, Monarch via bitcoin-dev wrote: > On 2015-09-01 15:59, Dave Collins via bitcoin-dev wrote: >> I'd be interested to know about these supposed btcd mainnet forks that >> have occurred due to a consensus failure since it came out of alpha. >> I'll go ahead and save you some research time - there hasn't been one. >> I'm not claiming there will never be one as that would be just as >> foolish as claiming Bitcoin Core won't have any more either. > > For the purposes of the conversation this was only brought up to re- > enforce my claim that this is outrageously difficult software > development, irrespective of the quality of the code being produced in > alternate implementations. Sorry if that came across as an attack > against your software in particular, it wasn't intended. Whether intended or otherwise this is an attack on the idea of decentralized bitcoin development. The option to fork or roll your own is open source, not decentralization. Decentralization requires *actually doing so*. One step down that path, even for a fork, is a major commitment. Common consensus check code is now available in several bitcoin implementations. The claim that this is outrageously difficult is misleading. It's just engineering work that needs to get done if Bitcoin is to survive. >> On the other hand, Bitcoin Core has had actual forks on mainnet during >> the same period. I'm not casting stones at Bitcoin Core here, because >> as I've said many times, none of us are perfect. No matter how careful >> everyone is, it is bound to happen from time to time. > > The point I was trying to make is that this is simply a hard > development situation to be working in, we don't know what behavior is > inferred by the use of CPP and even more so OpenSSL (as the DER > encoding consensus failure made abundantly clear). There's almost > certainly more problems lying around given how generally dusty a lot > of the transaction environment is, it's very easy to get off the > beaten track with Bitcoin script. These are issues that affect the satoshi client as much as other implementations, and therefore don't support your premise. e [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Your Gmaxwell exchange 2015-09-01 18:37 ` Eric Voskuil @ 2015-09-01 20:08 ` Monarch 0 siblings, 0 replies; 28+ messages in thread From: Monarch @ 2015-09-01 20:08 UTC (permalink / raw) To: Eric Voskuil; +Cc: bitcoin-dev, libbitcoin On 2015-09-01 18:37, Eric Voskuil wrote: > Whether intended or otherwise this is an attack on the idea of > decentralized bitcoin development. The option to fork or roll your own > is open source, not decentralization. Decentralization requires > *actually doing so*. One step down that path, even for a fork, is a > major commitment. > > Common consensus check code is now available in several bitcoin > implementations. The claim that this is outrageously difficult is > misleading. It's just engineering work that needs to get done if > Bitcoin > is to survive. > There's no requirement for there to be multiple interpretations of the consensus code, this is why libbitcoinconsensus exists. Why do you think Bitcoins survival is predicated on reimplementation? > These are issues that affect the satoshi client as much as other > implementations, and therefore don't support your premise. > I'm aware that these problems apply to Bitcoin Core. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2015-09-02 18:58 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAEgR2PFB3h_8fr=d8HegRSD0XdooimhFKtLR4vKr2QXv+EwBfQ@mail.gmail.com>
[not found] ` <AD284610-4F40-445C-A074-CC94EDFFCBA8@gmx.com>
2015-08-30 3:25 ` [bitcoin-dev] Your Gmaxwell exchange 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
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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox