Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EB167A7B for ; Fri, 13 Oct 2017 12:27:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 88272A4 for ; Fri, 13 Oct 2017 12:27:19 +0000 (UTC) Received: by mail-it0-f53.google.com with SMTP id p138so11057152itp.2 for ; Fri, 13 Oct 2017 05:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1NseTJpwmlJk5xICprhqDvOqlCTkQm9ZpnlnnQBj3J0=; b=UZ78CHYu2T5IW3vVXzoj0VuXq+rRyVtIdnB6LWlPZ9xVr2t7DcuVd6F2FJq5rBMEiR 5e9WcvLGEfIC4X+EVkjbEVSSSWHnEZPNOCpy0OLXipBTffZX3lYeKsM/Rbazs3gyHIkD WHVNr+e+hLJJHmjxEAt4YZwFD0NiBCrCO0fRZXTCxjGT5FrdWTYSRe/gzHFbewyCu/vy 2mPN5QRIK//I3OiV56BNlld3PVpOv/OEMKHeCoERnXuXNGkiGh7rgamAtJbRIwZkK+KX 87Hdvvcr7T6h/9W2Z/1t1es0p8aewIrfTUCrbM3fYEg/GfSTIfU2/be3FyGW82Xa5+5Q 6EkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=1NseTJpwmlJk5xICprhqDvOqlCTkQm9ZpnlnnQBj3J0=; b=jv4doZL1R3sQrfg0o6TUvQhI0pNE1IluxvEhv9IXqd2P59FcjSxd+/Wdp8Z7Q/rjKp /7aeKtCYUB1mby65nc/r76OXpFg75alD/eHTN5lFnCEzHL0fS8kuHzG6IF/H0pvJhTgx ideHAG0pS7OjAFKKRGxF29G+P+TsTTw2sMbZk08AOzw7ZTdG2hVZz3dLA2yaIaNRKCG2 UHEEOKAwzlY+i8gYbfsVlGReKohFw8PkkMPPsw/AKOiVfvbQ2NAv13euemt5DcNVexjU f4HIXqV2LXjtMWolwPF29ChLERD4RXazkDIF8iSkivzA6v813fYQ+I2RA+qq2Tn21O1h pvLA== X-Gm-Message-State: AMCzsaWc7yIRKK2BZcaKRZC7eZFXim+9hyv8fWqwF0pWg+QrrwDAhbNa NxdHR0jlr7xAXvFLGn37xQIJPJN2YdgT2fE1IHc= X-Google-Smtp-Source: AOwi7QBSmTQayvsUHH/jbcJppeFZZRn4NURY+BIQyNVZ5Dz4rOGrfovvR+d4wlPRQ3YDsMNfMGYZq/HgIn2xP/FIix4= X-Received: by 10.36.184.193 with SMTP id m184mr375373ite.82.1507897638437; Fri, 13 Oct 2017 05:27:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.28.135 with HTTP; Fri, 13 Oct 2017 05:27:17 -0700 (PDT) Received: by 10.2.28.135 with HTTP; Fri, 13 Oct 2017 05:27:17 -0700 (PDT) In-Reply-To: References: From: Ilan Oh Date: Fri, 13 Oct 2017 14:27:17 +0200 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="94eb2c1144e818c7d2055b6cc76c" X-Spam-Status: No, score=-0.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, LOTS_OF_MONEY, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM,T_MONEY_PERCENT autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 13 Oct 2017 12:28:00 +0000 Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 21 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 12:27:22 -0000 --94eb2c1144e818c7d2055b6cc76c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Mining infrastructure follows price. If bitcoins were still trading at 1 USD per coin, nobody will build mining infrastructure to the same level as today, with 5000 USD per coin. In the case of bitcoin, it is the price that follows mining infrastructures. The price is at 5000 because it is difficult to mine bitcoin not the other way around, like you mention it. Even with a fixed demand, price would go up as difficulty grow, the supply guide the market. There is a strong incentive to mine blindly as it is difficult to estimate for a miner where is the actual demand, with a start up currency without actual economic support. Indeed at the genesis of this "mining-price" cycle the incentive was to contribute to a network and create ones own supply, and not respond to a demand. Ilansky Le 13 oct. 2017 13:55, a =C3=A9crit : > Send bitcoin-dev mailing list submissions to > bitcoin-dev@lists.linuxfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > or, via email, send a message with subject or body 'help' to > bitcoin-dev-request@lists.linuxfoundation.org > > You can reach the person managing the list at > bitcoin-dev-owner@lists.linuxfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bitcoin-dev digest..." > > > Today's Topics: > > 1. Re: New difficulty algorithm part 2 (ZmnSCPxj) > 2. Re: New difficulty algorithm part 2 (Scott Roberts) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 13 Oct 2017 00:45:33 -0400 > From: ZmnSCPxj > To: Scott Roberts > Cc: "bitcoin-dev@lists.linuxfoundation.org" > > Subject: Re: [bitcoin-dev] New difficulty algorithm part 2 > Message-ID: > rkbdukpk9eyoPx1ReOZSUsNrcowRU9gL5UbKtblkQn2SUo06BHE=3D@protonmail.com> > > Content-Type: text/plain; charset=3D"utf-8" > > Good morning, > > >ZmnSCPxj wrote: > >> Thus even if the unwanted chain provides 2 tokens as fee per block, > >> whereas the wanted chain provides 1 token as fee per block, if the > >> unwanted chain tokens are valued at 1/4 the wanted chain tokens, miner= s > >> will still prefer the wanted chain regardless. > > > >This is a good point I was not thinking about, but your math assumes > >1/2 price for a coin that can do 2x more transactions. Holders like > >Roger Ver have an interest in low price and more transactions. A coin > >with 2x more transactions, 22% lower price, and 22% lower fees per > >coin transferred will attract more merchants, customers, and miners > >(they get 50% more total fees) and this will in turn attract more > >hodlers and devs. This assumes it outweighs hodler security concerns. > >Merchants and customers, to the extent they are not long term hodlers, > >are not interested in price as much as stability, so they are somewhat > >at odds with hodlers. > > As of this moment, BT1 / BT2 price ratio in BitFinex is slightly higher > than 7 : 1. Twice the transaction rate cannot overcome this price ratio > difference. Even if you were to claim that the BitFinex data is off by a > factor of 3, twice the transaction rate still cannot overcome the price > ratio difference. Do you have stronger data than what is available on > BitFinex? If not, your assumptions are incorrect and all conclusions > suspect. > > >Bitcoin consensus truth is based on "might is right". Buyers and > >sellers of goods and services ("users") can shift some might to miners > >via fees, to the chagrin of hodlers who have more interest in security > >and price increases. Some hodlers think meeting user needs is the > >source of long term value. Others think mining infrastructure is. > > Mining infrastructure follows price. If bitcoins were still trading at 1 > USD per coin, nobody will build mining infrastructure to the same level a= s > today, with 5000 USD per coin. > > Price will follow user needs, i.e. demand. > > >You > >seem to require hodlers to correctly identify and rely solely on good > >developers. > > For the very specific case of 2X, it is very easy to make this > identification. Even without understanding the work being done, one can > reasonably say that it is far more likely that a loose group of 100 or mo= re > developers will contain a few good or excellent developers, than a group = of > a few developers containing a similar number of good or excellent > developers. > > User needs will get met only on the chain that good developers work on. > Bitcoin today has too many limitations: viruses on Windows can steal all > your money, fee estimates consistently overestimate, fees rise during > spamming attacks, easy to lose psuedonymity, tiny UTXOs are infeasible to > spend, cannot support dozens of thousands of transactions per second. > Rationally, long-term hodlers will select a chain with better developers > who are more likely to discover or innovate methods to reduce, eliminate, > or sidestep those limitations. Perhaps the balance will change in the > future, but it is certainly not the balance now, and thus any difficulty > algorithm change in response to the current situation will be premature, > and far more likely to cause disaster than avert one. > > >Whatever combination of these is the case, bad money can > >still drive out good, especially if the market determination is not > >efficient. > > > >A faster measurement of hashrate for difficulty enables the economic > >determination to be more efficient and correct. It prevents the > >biggest coin from bullying forks that have better ideas. Conversely, > >it prevents miners from switching to an inferior coin simply because > >it provides them with more "protection money" from fees that enables > >them to bully Bitcoin Core out of existence, even in the presence of a > >slightly larger hodler support. > > This requires that all chains follow the same difficulty adjustment: afte= r > all, it is also entirely the possibility that 2X will be the lower-hashra= te > coin in a few months, with the Core chain bullying them out of existence. > Perhaps you should cross-post your analysis to bitcoin-segwit2x also. > After all, the 2X developers should also want to have faster price > discovery of the true price of 2X, away from the unfavorable (incorrect?) > pricing on BitFinex. > > >Devs are a governing authority under the influence of users, hodlers, > >and miners. Miners are like banks lobbying government for higher total > >fees. Hodlers are the new 1%, holding 90% of the coin, lobbying both > >devs and users for security, but equally interested in price > >increases. Users are "the people" that devs need to protect against > >both hodlers and miners. They do not care about price as long as it is > >stable. They do not want to become the 99% owning 10% of the coin or > >have to pay unecessary fees merely for their coin to be the biggest > >bully on the block. A faster responding difficulty will take a lot of > >hot air out of the bully. It prevents miners from being able to > >dictate that only coins with high fees are allowed. They are less > >able to destroy small coins that have a fast defense. > > > >The 1% and banks would starve the people that feed them to death if > >they were allowed complete control of the government. Are hodlers and > >miners any wiser? > > Are developers any wiser, either? > > Then consider this wisdom: The fewer back-incompatible changes to a coin, > the better. Hardforks of any kind are an invitation to disaster and, at > this point, require massive coordination effort which cannot be feasibly > done within a month. Fast market determination can be done using off-cha= in > methods (such as on-exchange trades), and are generally robust against > temporary problems on-chain, although admittedly there is a counterparty > risk involved. The coin works, and in general there is usually very litt= le > need to fix it, especially using dangerous hardforks. > > >Devs need to strive for an expansion of the coin > >quantity to keep value constant which is the foundation of the 5 > >characteristics of an ideal currency. > > Is that your goal? This is a massive departure from the conception of > Bitcoin as having a fixed limit and effectively becoming deflationary. I= t > will also lead to massive economic distortions in favor of those who > receive newly-minted coins. I doubt any developer would want to have thi= s > property. > > Regards, > ZmnSCPxj > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20171013/1afdebf0/attachment.html> > > ------------------------------ > > Message: 2 > Date: Fri, 13 Oct 2017 07:35:09 -0400 > From: Scott Roberts > To: ZmnSCPxj > Cc: "bitcoin-dev@lists.linuxfoundation.org" > > Subject: Re: [bitcoin-dev] New difficulty algorithm part 2 > Message-ID: > gmail.com> > Content-Type: text/plain; charset=3D"UTF-8" > > Yes, the current price ratio indicates there is no need for a new > difficulty algorithm. I do not desire to fork before a disaster, or to > otherwise employ a new difficulty before a fork is otherwise needed. > > A 2-week delay in difficulty response is a 2 week error in > measurement. Slow response generally means less intelligence. > > My goal is not to have a bunch of BTC clones that merchants and buyers > use equally, but to have a better difficulty algorithm in place to be > used in the next BTC "Core" fork. If not for the current situation, > then for future security. > > > This is a massive departure from the conception of Bitcoin as having a > fixed limit and effectively becoming deflationary. > > You mean multiple forks is inflationary. The current limit in quantity > is deflationary because the use of the coin is rising faster than its > mining is producing (see velocity of money). Constant value is defined > as being neither. Bitcoin's deflationary quality created a massive > marketing advantage as well as paid the creator about million dollars > an hour. If it suddenly were able to be a constant value coin, its use > in the marketplace and as a real store of value would skyrocket and > the cries of "Ponzi scheme" would stop. The trick is in determining > constant value without a 3rd party such as an index of a basket of > commodities (which both Keynes and von Mises wanted, but was scuttled > by the U.S. at Bretton Woods). > > On Fri, Oct 13, 2017 at 12:45 AM, ZmnSCPxj > wrote: > > Good morning, > > > > > >>ZmnSCPxj wrote: > >>> Thus even if the unwanted chain provides 2 tokens as fee per block, > >>> whereas the wanted chain provides 1 token as fee per block, if the > >>> unwanted chain tokens are valued at 1/4 the wanted chain tokens, mine= rs > >>> will still prefer the wanted chain regardless. > >> > >>This is a good point I was not thinking about, but your math assumes > >>1/2 price for a coin that can do 2x more transactions. Holders like > >>Roger Ver have an interest in low price and more transactions. A coin > >>with 2x more transactions, 22% lower price, and 22% lower fees per > >>coin transferred will attract more merchants, customers, and miners > >>(they get 50% more total fees) and this will in turn attract more > >>hodlers and devs. This assumes it outweighs hodler security concerns. > >>Merchants and customers, to the extent they are not long term hodlers, > >>are not interested in price as much as stability, so they are somewhat > >>at odds with hodlers. > > > > As of this moment, BT1 / BT2 price ratio in BitFinex is slightly higher > than > > 7 : 1. Twice the transaction rate cannot overcome this price ratio > > difference. Even if you were to claim that the BitFinex data is off by= a > > factor of 3, twice the transaction rate still cannot overcome the price > > ratio difference. Do you have stronger data than what is available on > > BitFinex? If not, your assumptions are incorrect and all conclusions > > suspect. > > > > > >>Bitcoin consensus truth is based on "might is right". Buyers and > >>sellers of goods and services ("users") can shift some might to miners > >>via fees, to the chagrin of hodlers who have more interest in security > >>and price increases. Some hodlers think meeting user needs is the > >>source of long term value. Others think mining infrastructure is. > > > > Mining infrastructure follows price. If bitcoins were still trading at= 1 > > USD per coin, nobody will build mining infrastructure to the same level > as > > today, with 5000 USD per coin. > > > > Price will follow user needs, i.e. demand. > > > >>You > >>seem to require hodlers to correctly identify and rely solely on good > >>developers. > > > > For the very specific case of 2X, it is very easy to make this > > identification. Even without understanding the work being done, one ca= n > > reasonably say that it is far more likely that a loose group of 100 or > more > > developers will contain a few good or excellent developers, than a grou= p > of > > a few developers containing a similar number of good or excellent > > developers. > > > > User needs will get met only on the chain that good developers work on. > > Bitcoin today has too many limitations: viruses on Windows can steal al= l > > your money, fee estimates consistently overestimate, fees rise during > > spamming attacks, easy to lose psuedonymity, tiny UTXOs are infeasible = to > > spend, cannot support dozens of thousands of transactions per second. > > Rationally, long-term hodlers will select a chain with better developer= s > who > > are more likely to discover or innovate methods to reduce, eliminate, o= r > > sidestep those limitations. Perhaps the balance will change in the > future, > > but it is certainly not the balance now, and thus any difficulty > algorithm > > change in response to the current situation will be premature, and far > more > > likely to cause disaster than avert one. > > > >>Whatever combination of these is the case, bad money can > >>still drive out good, especially if the market determination is not > >>efficient. > >> > >>A faster measurement of hashrate for difficulty enables the economic > >>determination to be more efficient and correct. It prevents the > >>biggest coin from bullying forks that have better ideas. Conversely, > >>it prevents miners from switching to an inferior coin simply because > >>it provides them with more "protection money" from fees that enables > >>them to bully Bitcoin Core out of existence, even in the presence of a > >>slightly larger hodler support. > > > > This requires that all chains follow the same difficulty adjustment: > after > > all, it is also entirely the possibility that 2X will be the > lower-hashrate > > coin in a few months, with the Core chain bullying them out of existenc= e. > > Perhaps you should cross-post your analysis to bitcoin-segwit2x also. > After > > all, the 2X developers should also want to have faster price discovery = of > > the true price of 2X, away from the unfavorable (incorrect?) pricing on > > BitFinex. > > > >>Devs are a governing authority under the influence of users, hodlers, > >>and miners. Miners are like banks lobbying government for higher total > >>fees. Hodlers are the new 1%, holding 90% of the coin, lobbying both > >>devs and users for security, but equally interested in price > >>increases. Users are "the people" that devs need to protect against > >>both hodlers and miners. They do not care about price as long as it is > >>stable. They do not want to become the 99% owning 10% of the coin or > >>have to pay unecessary fees merely for their coin to be the biggest > >>bully on the block. A faster responding difficulty will take a lot of > >>hot air out of the bully. It prevents miners from being able to > >>dictate that only coins with high fees are allowed. They are less > >>able to destroy small coins that have a fast defense. > >> > >>The 1% and banks would starve the people that feed them to death if > >>they were allowed complete control of the government. Are hodlers and > >>miners any wiser? > > > > Are developers any wiser, either? > > > > Then consider this wisdom: The fewer back-incompatible changes to a coi= n, > > the better. Hardforks of any kind are an invitation to disaster and, a= t > > this point, require massive coordination effort which cannot be feasibl= y > > done within a month. Fast market determination can be done using > off-chain > > methods (such as on-exchange trades), and are generally robust against > > temporary problems on-chain, although admittedly there is a counterpart= y > > risk involved. The coin works, and in general there is usually very > little > > need to fix it, especially using dangerous hardforks. > > > >>Devs need to strive for an expansion of the coin > >>quantity to keep value constant which is the foundation of the 5 > >>characteristics of an ideal currency. > > > > Is that your goal? This is a massive departure from the conception of > > Bitcoin as having a fixed limit and effectively becoming deflationary. > It > > will also lead to massive economic distortions in favor of those who > receive > > newly-minted coins. I doubt any developer would want to have this > property. > > > > Regards, > > ZmnSCPxj > > > ------------------------------ > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > End of bitcoin-dev Digest, Vol 29, Issue 21 > ******************************************* > --94eb2c1144e818c7d2055b6cc76c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Mining infrastructure follows price.=C2=A0 If bitcoins were still tra= ding at 1 USD per coin, nobody will build mining infrastructure to the same= level as today, with 5000 USD per coin.

In the case of bitcoin, it i= s the price that follows mining infrastructures. The price is at 5000 becau= se it is difficult to mine bitcoin not the other way around, like you menti= on it. Even with a fixed demand, price would go up as difficulty grow, the = supply guide the market. There is a strong incentive to mine blindly as it = is difficult to estimate for a miner where is the actual demand, with a sta= rt up currency without actual economic support. Indeed at the genesis of th= is "mining-price" cycle the incentive was to contribute to a netw= ork and create ones own supply, and not respond to a demand.=C2=A0

Ilansky

Le=C2=A013 oct. 2017 13:55, <bitcoin-dev-request@= lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
Send bitcoin-dev mailing list submissions= to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev@lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://li= sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev-request@lists.linuxfoundation.org
You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev-owner@lists.linuxfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: New difficulty algorithm part 2 (ZmnSCPxj)
=C2=A0 =C2=A02. Re: New difficulty algorithm part 2 (Scott Roberts)


-----------------------------------------------------------------= -----

Message: 1
Date: Fri, 13 Oct 2017 00:45:33 -0400
From: ZmnSCPxj <ZmnSCPxj@prot= onmail.com>
To: Scott Roberts <wordsgalore@= gmail.com>
Cc: "bitcoin-= dev@lists.linuxfoundation.org"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New difficulty algorithm part 2
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <Hr8ORNHzR76wNhJHoagwXi2ewQ1qYSZSc= H0xeltVnqid2ljOowc2bj8-rkbdukpk9eyoPx1ReOZSUsNrcowRU9gL5UbKtblkQn= 2SUo06BHE=3D@protonmail.com>

Content-Type: text/plain; charset=3D"utf-8"

Good morning,

>ZmnSCPxj wrote:
>> Thus even if the unwanted chain provides 2 tokens as fee per block= ,
>> whereas the wanted chain provides 1 token as fee per block, if the=
>> unwanted chain tokens are valued at 1/4 the wanted chain tokens, m= iners
>> will still prefer the wanted chain regardless.
>
>This is a good point I was not thinking about, but your math assumes >1/2 price for a coin that can do 2x more transactions. Holders like
>Roger Ver have an interest in low price and more transactions. A coin >with 2x more transactions, 22% lower price, and 22% lower fees per
>coin transferred will attract more merchants, customers, and miners
>(they get 50% more total fees) and this will in turn attract more
>hodlers and devs. This assumes it outweighs hodler security concerns. >Merchants and customers, to the extent they are not long term hodlers,<= br> >are not interested in price as much as stability, so they are somewhat<= br> >at odds with hodlers.

As of this moment, BT1 / BT2 price ratio in BitFinex is slightly higher tha= n 7 : 1.=C2=A0 Twice the transaction rate cannot overcome this price ratio = difference.=C2=A0 Even if you were to claim that the BitFinex data is off b= y a factor of 3, twice the transaction rate still cannot overcome the price= ratio difference.=C2=A0 Do you have stronger data than what is available o= n BitFinex?=C2=A0 If not, your assumptions are incorrect and all conclusion= s suspect.

>Bitcoin consensus truth is based on "might is right". Buyers = and
>sellers of goods and services ("users") can shift some might = to miners
>via fees, to the chagrin of hodlers who have more interest in security<= br> >and price increases. Some hodlers think meeting user needs is the
>source of long term value. Others think mining infrastructure is.

Mining infrastructure follows price.=C2=A0 If bitcoins were still trading a= t 1 USD per coin, nobody will build mining infrastructure to the same level= as today, with 5000 USD per coin.

Price will follow user needs, i.e. demand.

>You
>seem to require hodlers to correctly identify and rely solely on good >developers.

For the very specific case of 2X, it is very easy to make this identificati= on.=C2=A0 Even without understanding the work being done, one can reasonabl= y say that it is far more likely that a loose group of 100 or more develope= rs will contain a few good or excellent developers, than a group of a few d= evelopers containing a similar number of good or excellent developers.

User needs will get met only on the chain that good developers work on.=C2= =A0 Bitcoin today has too many limitations: viruses on Windows can steal al= l your money, fee estimates consistently overestimate, fees rise during spa= mming attacks, easy to lose psuedonymity, tiny UTXOs are infeasible to spen= d, cannot support dozens of thousands of transactions per second.=C2=A0 Rat= ionally, long-term hodlers will select a chain with better developers who a= re more likely to discover or innovate methods to reduce, eliminate, or sid= estep those limitations.=C2=A0 Perhaps the balance will change in the futur= e, but it is certainly not the balance now, and thus any difficulty algorit= hm change in response to the current situation will be premature, and far m= ore likely to cause disaster than avert one.

>Whatever combination of these is the case, bad money can
>still drive out good, especially if the market determination is not
>efficient.
>
>A faster measurement of hashrate for difficulty enables the economic >determination to be more efficient and correct. It prevents the
>biggest coin from bullying forks that have better ideas. Conversely, >it prevents miners from switching to an inferior coin simply because >it provides them with more "protection money" from fees that = enables
>them to bully Bitcoin Core out of existence, even in the presence of a<= br> >slightly larger hodler support.

This requires that all chains follow the same difficulty adjustment: after = all, it is also entirely the possibility that 2X will be the lower-hashrate= coin in a few months, with the Core chain bullying them out of existence.= =C2=A0 Perhaps you should cross-post your analysis to bitcoin-segwit2x also= .=C2=A0 After all, the 2X developers should also want to have faster price = discovery of the true price of 2X, away from the unfavorable (incorrect?) p= ricing on BitFinex.

>Devs are a governing authority under the influence of users, hodlers, >and miners. Miners are like banks lobbying government for higher total<= br> >fees. Hodlers are the new 1%, holding 90% of the coin, lobbying both >devs and users for security, but equally interested in price
>increases. Users are "the people" that devs need to protect a= gainst
>both hodlers and miners. They do not care about price as long as it is<= br> >stable. They do not want to become the 99% owning 10% of the coin or >have to pay unecessary fees merely for their coin to be the biggest
>bully on the block. A faster responding difficulty will take a lot of >hot air out of the bully. It prevents miners from being able to
>dictate that only coins with high fees are allowed. They are less
>able to destroy small coins that have a fast defense.
>
>The 1% and banks would starve the people that feed them to death if
>they were allowed complete control of the government. Are hodlers and >miners any wiser?

Are developers any wiser, either?

Then consider this wisdom: The fewer back-incompatible changes to a coin, t= he better.=C2=A0 Hardforks of any kind are an invitation to disaster and, a= t this point, require massive coordination effort which cannot be feasibly = done within a month.=C2=A0 Fast market determination can be done using off-= chain methods (such as on-exchange trades), and are generally robust agains= t temporary problems on-chain, although admittedly there is a counterparty = risk involved.=C2=A0 The coin works, and in general there is usually very l= ittle need to fix it, especially using dangerous hardforks.

>Devs need to strive for an expansion of the coin
>quantity to keep value constant which is the foundation of the 5
>characteristics of an ideal currency.

Is that your goal?=C2=A0 This is a massive departure from the conception of= Bitcoin as having a fixed limit and effectively becoming deflationary.=C2= =A0 It will also lead to massive economic distortions in favor of those who= receive newly-minted coins.=C2=A0 I doubt any developer would want to have= this property.

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/a= ttachments/20171013/1afdebf0/attachment.html>

------------------------------

Message: 2
Date: Fri, 13 Oct 2017 07:35:09 -0400
From: Scott Roberts <wordsgalor= e@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@proton= mail.com>
Cc: "bitcoin-= dev@lists.linuxfoundation.org"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New difficulty algorithm part 2
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CADtTMvnrZp=3DJD4rkXQOZAPNS9BMNMqnTyf= A65PRzZhWs+VxgHA@mail.gmail.com>
Content-Type: text/plain; charset=3D"UTF-8"

Yes, the current price ratio indicates there is no need for a new
difficulty algorithm. I do not desire to fork before a disaster, or to
otherwise employ a new difficulty before a fork is otherwise needed.

A 2-week delay in difficulty response is a 2 week error in
measurement. Slow response generally means less intelligence.

My goal is not to have a bunch of BTC clones that merchants and buyers
use equally, but to have a=C2=A0 better difficulty algorithm in place to be=
used in the next BTC "Core" fork. If not for the current situatio= n,
then for future security.

>=C2=A0 This is a massive departure from the conception of Bitcoin as ha= ving a fixed limit and effectively becoming deflationary.

You mean multiple forks is inflationary. The current limit in quantity
is deflationary because the use of the coin is rising faster than its
mining is producing (see velocity of money). Constant value is defined
as being neither. Bitcoin's deflationary quality created a massive
marketing advantage as well as paid the creator about million dollars
an hour. If it suddenly were able to be a constant value coin, its use
in the marketplace and as a real store of value would skyrocket and
the cries of "Ponzi scheme" would stop. The trick is in determini= ng
constant value without a 3rd party such as an index of a basket of
commodities (which both Keynes and von Mises wanted, but was scuttled
by the U.S. at Bretton Woods).

On Fri, Oct 13, 2017 at 12:45 AM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning,
>
>
>>ZmnSCPxj wrote:
>>> Thus even if the unwanted chain provides 2 tokens as fee per b= lock,
>>> whereas the wanted chain provides 1 token as fee per block, if= the
>>> unwanted chain tokens are valued at 1/4 the wanted chain token= s, miners
>>> will still prefer the wanted chain regardless.
>>
>>This is a good point I was not thinking about, but your math assume= s
>>1/2 price for a coin that can do 2x more transactions. Holders like=
>>Roger Ver have an interest in low price and more transactions. A co= in
>>with 2x more transactions, 22% lower price, and 22% lower fees per<= br> >>coin transferred will attract more merchants, customers, and miners=
>>(they get 50% more total fees) and this will in turn attract more >>hodlers and devs. This assumes it outweighs hodler security concern= s.
>>Merchants and customers, to the extent they are not long term hodle= rs,
>>are not interested in price as much as stability, so they are somew= hat
>>at odds with hodlers.
>
> As of this moment, BT1 / BT2 price ratio in BitFinex is slightly highe= r than
> 7 : 1.=C2=A0 Twice the transaction rate cannot overcome this price rat= io
> difference.=C2=A0 Even if you were to claim that the BitFinex data is = off by a
> factor of 3, twice the transaction rate still cannot overcome the pric= e
> ratio difference.=C2=A0 Do you have stronger data than what is availab= le on
> BitFinex?=C2=A0 If not, your assumptions are incorrect and all conclus= ions
> suspect.
>
>
>>Bitcoin consensus truth is based on "might is right". Buy= ers and
>>sellers of goods and services ("users") can shift some mi= ght to miners
>>via fees, to the chagrin of hodlers who have more interest in secur= ity
>>and price increases. Some hodlers think meeting user needs is the >>source of long term value. Others think mining infrastructure is. >
> Mining infrastructure follows price.=C2=A0 If bitcoins were still trad= ing at 1
> USD per coin, nobody will build mining infrastructure to the same leve= l as
> today, with 5000 USD per coin.
>
> Price will follow user needs, i.e. demand.
>
>>You
>>seem to require hodlers to correctly identify and rely solely on go= od
>>developers.
>
> For the very specific case of 2X, it is very easy to make this
> identification.=C2=A0 Even without understanding the work being done, = one can
> reasonably say that it is far more likely that a loose group of 100 or= more
> developers will contain a few good or excellent developers, than a gro= up of
> a few developers containing a similar number of good or excellent
> developers.
>
> User needs will get met only on the chain that good developers work on= .
> Bitcoin today has too many limitations: viruses on Windows can steal a= ll
> your money, fee estimates consistently overestimate, fees rise during<= br> > spamming attacks, easy to lose psuedonymity, tiny UTXOs are infeasible= to
> spend, cannot support dozens of thousands of transactions per second.<= br> > Rationally, long-term hodlers will select a chain with better develope= rs who
> are more likely to discover or innovate methods to reduce, eliminate, = or
> sidestep those limitations.=C2=A0 Perhaps the balance will change in t= he future,
> but it is certainly not the balance now, and thus any difficulty algor= ithm
> change in response to the current situation will be premature, and far= more
> likely to cause disaster than avert one.
>
>>Whatever combination of these is the case, bad money can
>>still drive out good, especially if the market determination is not=
>>efficient.
>>
>>A faster measurement of hashrate for difficulty enables the economi= c
>>determination to be more efficient and correct. It prevents the
>>biggest coin from bullying forks that have better ideas. Conversely= ,
>>it prevents miners from switching to an inferior coin simply becaus= e
>>it provides them with more "protection money" from fees t= hat enables
>>them to bully Bitcoin Core out of existence, even in the presence o= f a
>>slightly larger hodler support.
>
> This requires that all chains follow the same difficulty adjustment: a= fter
> all, it is also entirely the possibility that 2X will be the lower-has= hrate
> coin in a few months, with the Core chain bullying them out of existen= ce.
> Perhaps you should cross-post your analysis to bitcoin-segwit2x also.= =C2=A0 After
> all, the 2X developers should also want to have faster price discovery= of
> the true price of 2X, away from the unfavorable (incorrect?) pricing o= n
> BitFinex.
>
>>Devs are a governing authority under the influence of users, hodler= s,
>>and miners. Miners are like banks lobbying government for higher to= tal
>>fees. Hodlers are the new 1%, holding 90% of the coin, lobbying bot= h
>>devs and users for security, but equally interested in price
>>increases. Users are "the people" that devs need to prote= ct against
>>both hodlers and miners. They do not care about price as long as it= is
>>stable. They do not want to become the 99% owning 10% of the coin o= r
>>have to pay unecessary fees merely for their coin to be the biggest=
>>bully on the block. A faster responding difficulty will take a lot = of
>>hot air out of the bully. It prevents miners from being able to
>>dictate that only coins with high fees are allowed. They are less >>able to destroy small coins that have a fast defense.
>>
>>The 1% and banks would starve the people that feed them to death if=
>>they were allowed complete control of the government. Are hodlers a= nd
>>miners any wiser?
>
> Are developers any wiser, either?
>
> Then consider this wisdom: The fewer back-incompatible changes to a co= in,
> the better.=C2=A0 Hardforks of any kind are an invitation to disaster = and, at
> this point, require massive coordination effort which cannot be feasib= ly
> done within a month.=C2=A0 Fast market determination can be done using= off-chain
> methods (such as on-exchange trades), and are generally robust against=
> temporary problems on-chain, although admittedly there is a counterpar= ty
> risk involved.=C2=A0 The coin works, and in general there is usually v= ery little
> need to fix it, especially using dangerous hardforks.
>
>>Devs need to strive for an expansion of the coin
>>quantity to keep value constant which is the foundation of the 5 >>characteristics of an ideal currency.
>
> Is that your goal?=C2=A0 This is a massive departure from the concepti= on of
> Bitcoin as having a fixed limit and effectively becoming deflationary.= =C2=A0 It
> will also lead to massive economic distortions in favor of those who r= eceive
> newly-minted coins.=C2=A0 I doubt any developer would want to have thi= s property.
>
> Regards,
> ZmnSCPxj


------------------------------

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


End of bitcoin-dev Digest, Vol 29, Issue 21
*******************************************
--94eb2c1144e818c7d2055b6cc76c--