Re: [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 21

[Scott Roberts via bitcoin-dev]

> ZmnSCPxj wrote
>> Mining infrastructure follows price.

Ilansky wrote:
> In the case of bitcoin, it is the price that follows mining infrastructures.

I generally agree with ZmnSCPxj that
good ideas => good devs => hodlers => price => mining

Except that each step is not an absolute, and can be biased by things
like miners who seek profit via fees and other means that are not good
for everyone else. Llansky's belief itself influences price away from
the ideal. Marketing "easy profits for hodlers!" and first-to-market
monopoly are other elements that influence price and thereby guide
mining away from good ideas (like a constant value currency). Then
price pulls in good devs that pulls in more mining. So it can snowball
into a monster.

We need not debate cause and effect since it's distant from the list's
goals. The relevance to me is that the biases away from ZmnSCPxj's
ideal are a reason a more responsive difficulty is needed.

Mining is for determining truth of the blockchain, not to make sure
there is only 1 blockchain. ZmnSCPxj indicates we should not do
anything that has more precision or speed in determining the correct
difficulty if it reduces Bitcoin's ability to be a monopoly. Not
coincidentally, the monopoly helps ensure hodlers become the new 1%. A
fork clone that uses the faster difficulty would attack BTC's slow
difficulty if it achieves a comparable price. All other things being
equal, it would lower BTC's value until it forks to fix the
difficulty.

On Fri, Oct 13, 2017 at 8:27 AM, Ilan Oh via bitcoin-dev
 wrote:
>> 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
> écrit :
>>
>> 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-requ...@lists.linuxfoundation.org
>>
>> You can reach the person managing the list at
>> bitcoin-dev-ow...@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:
>>
>> 

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 21

[Ilan Oh via bitcoin-dev]

> 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
écrit :

> 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-requ...@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-ow...@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=@protonmail.com>
>
> Content-Type: text/plain; charset="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, miners
> >> 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 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 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.
>