From: odinn <odinn.cyberguerrilla@riseup.net>
To: "Raystonn ." <raystonn@hotmail.com>,
Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
Date: Thu, 30 Jul 2015 02:44:23 -0700 [thread overview]
Message-ID: <55B9F1F7.7000408@riseup.net> (raw)
In-Reply-To: <COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl>
-----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
> <bitcoin-dev@lists.linuxfoundation.org> 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-----
next prev parent reply other threads:[~2015-07-30 9:44 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 22:25 [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-29 0:43 ` Jean-Paul Kogelman
2015-07-29 0:44 ` Eric Lombrozo
2015-07-29 0:46 ` Mark Friedenbach
2015-07-29 0:55 ` Eric Lombrozo
2015-07-29 2:40 ` Eric Lombrozo
2015-07-29 3:37 ` Eric Lombrozo
2015-07-29 3:46 ` Milly Bitcoin
2015-07-29 5:17 ` Eric Lombrozo
2015-07-29 11:18 ` Thomas Zander
2015-07-29 9:59 ` Mike Hearn
2015-07-29 10:43 ` Eric Lombrozo
2015-07-29 11:15 ` Mike Hearn
2015-07-29 12:03 ` Eric Lombrozo
2015-07-29 12:13 ` Thomas Zander
2015-07-29 17:17 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
2015-07-29 19:56 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Owen
2015-07-29 20:09 ` Gregory Maxwell
2015-07-29 21:28 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
2015-07-29 22:11 ` Venzen Khaosan
2015-07-29 23:10 ` Raystonn .
2015-07-30 3:49 ` Adam Back
2015-07-30 4:51 ` Andrew LeCody
2015-07-30 8:21 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-30 9:15 ` Eric Lombrozo
2015-07-30 12:29 ` Gavin
2015-07-30 12:50 ` Pieter Wuille
2015-07-30 14:03 ` Thomas Zander
2015-07-30 14:05 ` Gavin Andresen
2015-07-30 14:28 ` Pieter Wuille
2015-07-30 15:36 ` Jorge Timón
2015-07-30 23:33 ` Eric Lombrozo
2015-07-31 0:15 ` Milly Bitcoin
2015-07-31 21:30 ` Jorge Timón
2015-07-31 21:43 ` Eric Lombrozo
2015-07-31 6:42 ` Thomas Zander
2015-07-31 20:45 ` Eric Lombrozo
2015-07-31 20:57 ` Eric Lombrozo
2015-08-01 20:22 ` John T. Winslow
2015-08-01 21:05 ` Pieter Wuille
2015-07-30 9:16 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Venzen Khaosan
2015-07-30 9:38 ` Jorge Timón
2015-07-30 13:33 ` Venzen Khaosan
2015-07-30 14:10 ` Jorge Timón
2015-07-30 14:52 ` Thomas Zander
2015-07-30 15:24 ` Bryan Bishop
2015-07-30 15:55 ` Gavin Andresen
2015-07-30 17:24 ` Thomas Zander
2015-07-31 15:27 ` Bryan Bishop
2015-07-30 16:07 ` Thomas Zander
2015-07-30 17:42 ` Thomas Zander
2015-07-30 18:02 ` Mark Friedenbach
2015-07-31 0:22 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-31 8:06 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Thomas Zander
2015-07-30 15:41 ` Jorge Timón
2015-07-30 9:44 ` odinn [this message]
2015-07-29 20:23 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measureisn't temporary Raystonn .
2015-07-29 11:29 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Thomas Zander
2015-07-29 18:00 ` Jorge Timón
2015-07-30 7:08 ` Thomas Zander
2015-07-29 16:53 ` Gregory Maxwell
2015-07-29 17:30 ` Sriram Karra
2015-07-29 18:03 ` Mike Hearn
2015-07-29 19:53 ` Gregory Maxwell
2015-07-30 14:15 ` Thomas Zander
2015-07-30 9:05 ` odinn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55B9F1F7.7000408@riseup.net \
--to=odinn.cyberguerrilla@riseup.net \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=gmaxwell@gmail.com \
--cc=raystonn@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox