From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BCC4EFF for ; Thu, 30 Jul 2015 09:44:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8B17F11B for ; Thu, 30 Jul 2015 09:44:24 +0000 (UTC) Received: from cotinga.riseup.net (unknown [10.0.1.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 2D0AF41400; Thu, 30 Jul 2015 09:44:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1438249464; bh=e0JInvGykBLr9NU80IFpx6JN1QNsdZLEqOwAPdeaNOY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=eZ2XqFrhDrvekzki0Vk5HqKe/+x0l1NLfouFNO80gNJFi0zlBc9y63WGjbVYmf7SN ZJPrhLqOHgsvOuyi4gETVD5r7pkhm0HowdghZoNCgyjvLJeA9szeaiLujCDe6uivcn oDS6OwOZnLakx0FLYa3bOsqJWhldCsGluNR+UsbA= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id BB0CA1C05EB Message-ID: <55B9F1F7.7000408@riseup.net> Date: Thu, 30 Jul 2015 02:44:23 -0700 From: odinn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Raystonn ." , Gregory Maxwell References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com><37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.7 at mx1 X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 09:44:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I will jump in just because I feel like it because the questions are fun and so on. (Of course I am not Gregory) On 07/29/2015 02:28 PM, Raystonn . via bitcoin-dev wrote: > Gregory, can you please speak to the following points. I would > like a better understanding of your positions. > Note that I am not Gregory, so with that caveat... > 1) Do you believe that Bitcoin's future is as a high-value > settlement network? No, it will have multiple and diverse purposes into which it can be used for and can evolve, it would not be sufficient to state that it has "a future" merely as a high-value settlement network. > > 2) Do you believe we need an artificial limit to transaction rate, > perhaps implemented as a maximum block size limit? If so, why? If you have a proposal on this, please submit it in the formal way as a BIP draft. Enough time has been burnt on the subject, imho. > > 3) Transaction fees will fluctuate with global economic conditions > and technology. Those free-market fluctuations should equally > affect any blockchain. However, if transaction fees on the Bitcoin > network are pushed artificially high, such as with an artificial > limit to transaction rate only applicable to Bitcoin, this will > create a condition where some other blockchains will have lower > fees. How do you plan to address the bleeding of value from > Bitcoin to alternative lower-fee blockchains created by the > artificially-high bitcoin transaction fees when users begin looking > for the cheapest way to send value? Modern economic study has > shown that liquidity moves to the location of least friction. It is the market. What will happen will happen. If bitcoin development pushes fees upward as an overall trend and the overall cost to transact continues to increase, billions of people around the world will as a result be forced out from most use cases of bitcoin and the "bleeding out" will occur naturally to alts (to the extent that persons already possessed bitcoin first and need to transact). As stated above, liquidity moves to location of least friction. Bitcoin bagholders can whine all they want, but value will distribute into the alts gradually. > > 4) If you believe it's not a problem to allow alternative > blockchains to leech some of Bitcoin's value, "allow" is not a relevant term here, as it is not up to anyone what people are going to do with their crypto of any kind. Unless, of course, you are fool enough to be using Coinbase and Bitpay or something like that. They own "your" coin, and they will decide, or allow, what you do with it or whether you can even access it. As has been stated before here, I hope you are not using such services. On the other hand, the following are very interesting: https://gear.mycelium.com/ - a Payment processor http://openbazaar.org a decentralized Market https://bitsquare.io/ a decentralized Exchange https://electrum.org/ a light wallet that you manage then: > a) How much value is it acceptable to lose? Irrelevant. Better question is, How much should one give? The more you can give, the better off you will be. > b) How do you think this will affect Bitcoin miners, whose large > investments in hardware do not transfer to other blockchains? Too much attention is paid to the miners. Miners should not be butthurt when people say that we should not put them up on a pedestal. Think ahead, to when there will no longer be bitcoin mining such as there is today. > c) How do you think this will affect the investors and holders of > bitcoin in general? People will continue to buy and sell. Some major changes are in store, however. If you would like, see my reflections on what the months ahead will hold, here: http://www.twitlonger.com/show/n_1sn3lqs > > > -----Original Message----- From: Gregory Maxwell via bitcoin-dev > Sent: Wednesday, July 29, 2015 1:09 PM To: Owen Cc: Bitcoin Dev > Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam > measure isn'ttemporary > > On Wed, Jul 29, 2015 at 7:56 PM, Owen via bitcoin-dev > wrote: >> On July 29, 2015 7:15:49 AM EDT, Mike Hearn via bitcoin-dev: >>> Consider this: the highest Bitcoin tx fees can possibly go is >>> perhaps a little higher than what our competition charges. Too >>> much higher than that, and people will just say, you know what >>> .... I'll make a bank transfer. It's cheaper and not much >>> slower, sometimes no slower at all. >> >> I respectfully disagree with this analysis. The implication is >> that bitcoin is merely one of a number of payment technologies. >> It's much more than that. It's sound money, censorship >> resistance, personal control over money, programmable money, and >> more. Without these attributes it's merely a really inefficient >> way to do payments. >> >> Given these advantages, there is no reason to believe the >> marginal cost of a transaction can't far surpass that of a PayPal >> or bank transfer. I personally would pay several multiples of the >> competitors' fees to continue using bitcoin. >> >> Sure, some marginal use cases will drop off with greater fees, >> but that's normal and expected. These will be use cases where the >> user doesn't care about bitcoin's advantages. We must be willing >> to let these use cases go anyway, because we unfortunately don't >> have room on chain for everything anyone might want to do. >> >> Therefore, bitcoin tx fees can go much higher than the >> competition. >> >> Remember how Satoshi referenced the banking crisis in his early >> work? The 2008 banking crisis was about a lot of things, but high >> credit card and paypal fees wasnt one of them. There's more going >> on here than just payments. Any speculative economic analysis >> would do better to include this fact. > > Precisely. And as "just a payment system" Bitcoin is not an > especially great one: The design requirements for > decenteralization impose considerable costs. To the extent that > the technology in Bitcoin is useful at all for building "just > another payment system" this technology in in the process of being > agressively copied by parties with deep fiat relationships > (including in partnership with centeral banks). If the focus for > Bitcoin's competative advantage becomes exclusively "better" > payments then it will almost certinatly fail in the market-place > against competing systems which avoid the Bitcoin currency adoption > related obsticles (but also gain none of Bitcoin's important > social/political promise). > > Also, critically, if Bitcoin's security properties are manintained > and enhanced then Bitcoin can be used to build secure systems which > _also_ accomidate those applications and we can have both. But if > Bitcoin's security properties are not strong then then advanced > tools cannot be built for it. E.g. atomic swaps make trustless > trades with external systems possible; but they are especially > sensitive to long reorginizations by miners... so they can only be > securely used where those reorgs are infeasable. So while I agree > that we must be willing to tolerate not catching every conceivable > use case; most of the time all that means is addressing them via a > less direct but more focused solution rather than ignoring them > completely. _______________________________________________ > bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVufH2AAoJEGxwq/inSG8C1mgH/3poEpk8pDDgZ7YQlGmAZjiO MDBempLkfm1BFFoNAzjMn9mwtmL9wDfpn/sd/YbuIriJjQR2WSl6zy/sLx/uIYxd qRuSRwOzN6wN7NfAuG7Lt3NtawOjAgl87n5YhRVB/d/MAK5HAvx3L9ME1Px//qsF Czg5r0XG4ZiQnT8J30caMtooSVU9toradAmMleVbMVOi9KViyuW2IvXz5mM1jYHh h+CB+CVHlhuKubXWpnnxYtOLLRQM5QSyfQiMPimVG0QPSOC5UkXJNo5gK6YMtBkT 0FevJyoMF+0LVTTPVGms+jolxu2PX3RW59nhNKEAuxOWfeHdMFFGtPP04XbpqSo= =R3aj -----END PGP SIGNATURE-----