📅 Original date posted:2015-07-30
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jorge,
You know, it is always insightful to get the perspective of active
participants and Core developers like yourself. As Adam pointed out
earlier, the developers have done mileage in this space and have
already considered most of the conceptual issues and technical
challenges that must resurface in waves as new interested parties join
the list. Allow me, in this response to your message, to make a
proposal to those who may be interested:
Bitcoin's protocol functions and the implications of this innovation
for the future are difficult to grasp, even for the smartest among us.
Then there are also the words of Niels Bohr:
"Prediction is difficult, especially about the future."
They say a lot of time and energy is wasted because we don't know what
we don't know. Years of discussion among those in the list has
established certain axioms that determine the options for Bitcoin
going forward. According to my comprehension, the following are some
of the most relevant for the present discussion (please correct me
where I'm off the mark):
1. A high degree of decentralization is prima optima.
2. Bitcoin is much more than a payment network. A lot of the
non-payment features are, arguably, what gives Bitcoin most of its
value. Yet, the payment functionality is a major design feature and
all agree that it should scale - subject to axiom 1.
3. The Bitcoin payment network ("Layer 1"), due to technical
constraints imposed by its p2p design, cannot compete with Visa and
other centralized transmission channels for speed or transaction
volume. Nor can it handle the transaction requirements of the world's
population - the scaling required would necessarily render Bitcoin
centralized, insecure and, therefore, worthless.
4. The addition of "layer 2" protocols (such as Lightning and other
sidechains) will allow fast, low-fee (and with virtually instant
confirmation) bitcoin transactions within two years, according to the
developers active in that:
http://www.youtube.com/watch?v=jE_elgnIw3M
http://www.youtube.com/watch?v=fBS_ieDwQ9k
5. This "layering of protocols" simplifies the scaling (blocksize)
debate because it separates
A) the primary concern for security and fidelity via
decentralization, and
B) the ideal of universal accessibility via fast, low-fee transactions.
Discussion about scalability can therefore proceed with the knowledge
that Lightning and other "layer 2" sidechains will make Bitcoin
accessible to the global majority - and be fast like Bruce Lee - while
the Bitcoin developers can focus on making Bitcoin Core protocol
(layer 1) the world heavyweight champion - Muhammad Ali.
Since I've maintained your interest up to the final sentence, I say:
as an insurance against a capacity crisis before layer 2 is deployed,
why not implement bip100's 2MB blocksize proposals in a testnet?
On 07/30/2015 04:38 PM, Jorge Timón wrote:
> It is important ro note that even if lightning was never developed,
> the block size remains at 1 MB forever and fees rise to 10 usd per
> transaction, such "high fees" are still extremely competitive with
> non-decentralized payment systems that have proportional fees. For
> example, 10 usd is still lower than 1% when you are moving more
> than 1000 usd. I know, this doesn't work for micro-transactions,
> but I don't think Bitcoin can be useful for micro-transactions in
> the long term unless something like lightning payment channels is
> deployed. Until we accept the second fact, it will be very hard to
> discuss any projection of future usage. I think that believing that
> all the transactions of the entire world population can be made
> in-chain while keeping bitcoin decentralized is incredibly naive.
> Not even nasdaq has that capacity (and if full node's require
> nasdaq's capacity, I don't think we can talk about a decentralized
> system anymore).
>
> On Jul 30, 2015 11:16 AM, "Venzen Khaosan via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Adam,
>
> - From your explanation it is evident that fast, cheap bitcoin
> transactions are possible. It is encouraging that Bitcoin _can_
> indeed compete with Visa, Paypal, et al. via Layer 2 protocols such
> as Lightning.
>
> The youtube interview with you and Greg re: Lightning requires
> some concentration and I'll have to watch it another couple of
> times to better grasp everything that is explained about the
> protocol and its interaction with Bitcoin.
>
> Thank you for your considered and informative response, else
> Raystonn and I might have gotten in an unnecessary scrap about
> fees, economics and what not.
>
> regards, Venzen Khaosan
>
>
>
> On 07/30/2015 10:49 AM, Adam Back wrote:
>> I dont think people consider other blockchains as a competitive
>> threat. A PoW-blockchain is a largely singleton data structure
>> for security reasons (single highest hashrate), it is hard for
>> an alternative chain to bootstrap or provide meaningful
>> security. Secondly the world largely lacks expertise to maintain
>> a blockchain to bitcoin's security level, perhaps you can see a
>> hint of this in the recently disclosed security vulnerability by
>> Pieter Wuille and Gregory Maxwell. Calls to this as an argument
>> are not resonating and probably not helping your argument.
>> Bitcoin has security properties, and a competing system cant
>> achieve better properties by bypassing security, any blockchain
>> faces the same fundamental security / decentralisation
>> limitations.
>
>> Secondly Bitcoin can obviously compete with itself with
>> different parameters and defacto *does* today. I think it is a
>> safe estimate that > 99% of Bitcoin transactions right now are
>> happening in Bitcoin related systems with various degrees of
>> audit, reconciliation, provable reserves etc. I think we can
>> expect this to continue and become more secure via more
>> reconciliation, and longer term via lightning or Bitcoin
>> sidechains with different parameters. It is a different story to
>> have a single central system (Bitcoin with parameters changed to
>> the point of centralisation failure) vs having multiple choices,
>> because some transactions can more easily use relatively
>> centralised systems (eg micropayments), and more interestingly
>> the combination of a secure and decentralised layer 1 plus
>> choices of less decentralised layer 2 options, can be interesting
>> because the layer 2 is provided cover from attack. There is less
>> to be gained by attacking relatively centralised layer 2 because
>> any payments at risk of policy abuse (which is typically a small
>> subset) can easily switch to layer 1. That in itself makes layer
>> 2 transactions also less susceptible to policy abuse. Further
>> lightning it appears from work so far should add significant
>> scale while retaining trustlessness and a good degree of
>> decentralisation.
>
>> Finally you seem to be focusing on "artificial" limits where
>> that is not the issue under consideration. The limits are
>> technical and relating to decentralisation and security. I wont
>> go over them again as this topic has been covered many times in
>> recent months. Any chain that tried to go to extreme parameters
>> (very low block intervals, or very large blocksizes) would have
>> the same decentralisation problems as Bitcoin would if it did the
>> same thing. There are a number of alt coins that have failed as
>> a result of poor parameter choices, there are inherent security
>> limits.
>
>> Adam
>
>> ps Etiquette note for yourself and others: please dont be
>> repetitive or attempt to be forceful. Many people have spent
>> many years understanding this very complex system, from my own
>> experience it is rare indeed to think of an entirely new concept
>> or analysis, that hasnt' been long considered and put to bed 3 or
>> 4 years ago. Thoughtful polite and constructive comments are
>> welcome but I recommend to not start from an assumption that you
>> have a clear and better insight than the entire technical
>> community, because I have to say from my own experience that is
>> very rarely the case. It can be useful to test theories on
>> #bitcoin IRC channel to find out what has been already concluded,
>> find the references and avoid having to have that hashed out on
>> this list which is trying to be focussed on technical solutions.
>
>
>> On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>> Cheapest way to send value? Is this what Bitcoin is trying
>>>> to do? So all of the smart contract, programmable money,
>>>> consensus coding and tremendous developer effort is bent to
>>>> the consumer demand for cheaper fees. Surely thou jests!
>>>
>>>
>>> These other features can be replicated into any alternative
>>> blockchain, including those with lower fees. In the
>>> open-source world of cryptocurrency, no feature will remain a
>>> value-add for very long after it has been identified to be
>>> such. Anything adding value will quickly be absorbed into
>>> competing alternative blockchains. That will leave economic
>>> policy as the distinguishing factor.
>>>
>>>> ... it is not the case ... that reluctance to concede
>>>> blocksize is an attempt to constrain capacity. Greg Maxwell
>>>> thoroughly explained in this thread that the protocol's
>>>> current state of development relies on blocksize for
>>>> security and, ultimately, as a means of protecting its degree
>>>> of decentralization.
>>>
>>>
>>> A slow or lack of increase to maximum transaction rate will
>>> cause pressure on fees. Whether this is the desired goal is
>>> not relevant. Everyone has agreed this will be the outcome.
>>> As to a smaller block size being needed for additional
>>> decentralization, one must simply ask how much we are all
>>> willing to pay for that additional decentralization. It is
>>> likely that the benefit thereto will have to be demonstrated by
>>> some power attacking and destroying a less decentralized
>>> currency before the benefit of this feature is given monetary
>>> value by the market. Until then, value will bleed to the
>>> network with the least friction, because it will have the
>>> greatest ability to grow its network effect. That means the
>>> blockchain with adequate features and cheapest fees will
>>> eventually have the largest market share.
>>>
>>>
>>> -----Original Message----- From: Venzen Khaosan Sent:
>>> Wednesday, July 29, 2015 3:11 PM To: Raystonn . Cc:
>>> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org> Subject: Re:
> [bitcoin-dev]
>>> Why Satoshi's temporary anti-spam measure isn'ttemporary
>>>
>> Raystonn, I'm aware that you're addressing your question to Greg
>> Maxwell, however a point you keep stating as fact calls for
>> reference:
>
>> On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote: [snip]
>>>>>
>>>>> 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?
>
>> Cheapest way to send value? Is this what Bitcoin is trying to
>> do? So all of the smart contract, programmable money, consensus
>> coding and tremendous developer effort is bent to the consumer
>> demand for cheaper fees. Surely thou jests!
>
>>>>> Modern economic study has shown that liquidity moves to
>>>>> the location of least friction.
>
>> Modern economic study? Can you please provide a link or
>> reference to the study you are referring to.
>
>> "liquidity moves to the location of least friction"
>
>> This sounds like "econo-speak" and makes no sense. The
>> definition of Liquidity is the degree to which an asset/security
>> can be bought or sold in the market without affecting the price.
>
>> That is why bitcoin is said to have low liquidity: buying or
>> selling only 100 BTC visibly affects the exchange price. You
>> probably mean "people like cheap fees", which is true, but as
>> others have said, because of Bitcoin's powerful features, they
>> are willing to pay higher fees and wait longer for transactions
>> to execute.
>
>> As for your public cross-examination of Greg Maxwell, your case
>> seems to be made on the assumption that limiting the size of
>> the blockchain is an attempt to artificially raise tx fees, but
>> it is not the case (as you and others repeatedly argue) that
>> reluctance to concede blocksize is an attempt to constrain
>> capacity. Greg Maxwell thoroughly explained in this thread that
>> the protocol's current state of development relies on blocksize
>> for security and, ultimately, as a means of protecting its degree
>> of decentralization.
>
>> Surely, this is an obvious concern even for those who are
>> campaigning for the hare-brained ideal of making Bitcoin a
>> "faster, cheaper alternative" to visa or paypal? If we lose
>> decentralization, we lose the whole thing, right? Incorrect or
>> correct?
>>> _______________________________________________ bitcoin-dev
>>> mailing list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuieTAAoJEGwAhlQc8H1meAIH/RHUV72bbMItZOT7rvhEU56r
lqEcvwXBSCYgsh1ieVeTdC/ydJnRSzWsdZxM3D7PEOzutlG+VaJQVSJREItGb2GW
PYiZ3uwSwF64nRq5bZ7aS2pT/Zo1a1yAf4H5rbeyxxoWC+zkmSsmcf73MgmslIuU
7XXHNztCX3glfOctr+J61WEKBw0ItQCTsp9J08yVlj/gvKTi3U2jDcYV5mf/3D0j
pvXl244DG4b+nYetRyyonYbZelSUYfCghNBJhUYZApVmcgfKDRPeX1uWfkl0HuUd
Kc+uZtrhJaUXdRlqc50nOsRSCAK+d4PGClF8JFlzI65+SG7VzkVqc8SkSDfNXfY=
=r4SA
-----END PGP SIGNATURE-----
Venzen Khaosan [ARCHIVE] /
npub1uu…r4rpf
2023-06-07 15:44:00
in reply to nevent1q…zy4r
Author Public Key
npub1uu2fve28mkg68uequseraz8gee7qg64733lr9r2g4c0xs5pmqnuslr4rpfPublished at
2023-06-07 15:44:00Event JSON
{
"id": "ab8e83c9d8635d920d63962d14bb07bfa480f155f8778ce28984c025f0b32635",
"pubkey": "e714966547dd91a3f320e4323e88e8ce7c046abe8c7e328d48ae1e68503b04f9",
"created_at": 1686152640,
"kind": 1,
"tags": [
[
"e",
"6c35032431244726c153d1a10f0c8b9388f3e47774968a06a7b1ffa60bbaccd9",
"",
"root"
],
[
"e",
"a186f8251f62b84e31c641c6284a21f683c316fc384b07c7f9ed989d194e6f3a",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-07-30\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJorge,\n\nYou know, it is always insightful to get the perspective of active\nparticipants and Core developers like yourself. As Adam pointed out\nearlier, the developers have done mileage in this space and have\nalready considered most of the conceptual issues and technical\nchallenges that must resurface in waves as new interested parties join\nthe list. Allow me, in this response to your message, to make a\nproposal to those who may be interested:\n\n\nBitcoin's protocol functions and the implications of this innovation\nfor the future are difficult to grasp, even for the smartest among us.\nThen there are also the words of Niels Bohr:\n\n\"Prediction is difficult, especially about the future.\"\n\nThey say a lot of time and energy is wasted because we don't know what\nwe don't know. Years of discussion among those in the list has\nestablished certain axioms that determine the options for Bitcoin\ngoing forward. According to my comprehension, the following are some\nof the most relevant for the present discussion (please correct me\nwhere I'm off the mark):\n\n1. A high degree of decentralization is prima optima.\n\n2. Bitcoin is much more than a payment network. A lot of the\nnon-payment features are, arguably, what gives Bitcoin most of its\nvalue. Yet, the payment functionality is a major design feature and\nall agree that it should scale - subject to axiom 1.\n\n3. The Bitcoin payment network (\"Layer 1\"), due to technical\nconstraints imposed by its p2p design, cannot compete with Visa and\nother centralized transmission channels for speed or transaction\nvolume. Nor can it handle the transaction requirements of the world's\npopulation - the scaling required would necessarily render Bitcoin\ncentralized, insecure and, therefore, worthless.\n\n4. The addition of \"layer 2\" protocols (such as Lightning and other\nsidechains) will allow fast, low-fee (and with virtually instant\nconfirmation) bitcoin transactions within two years, according to the\ndevelopers active in that:\nhttp://www.youtube.com/watch?v=jE_elgnIw3M\nhttp://www.youtube.com/watch?v=fBS_ieDwQ9k\n\n5. This \"layering of protocols\" simplifies the scaling (blocksize)\ndebate because it separates\n A) the primary concern for security and fidelity via\ndecentralization, and\n B) the ideal of universal accessibility via fast, low-fee transactions.\nDiscussion about scalability can therefore proceed with the knowledge\nthat Lightning and other \"layer 2\" sidechains will make Bitcoin\naccessible to the global majority - and be fast like Bruce Lee - while\nthe Bitcoin developers can focus on making Bitcoin Core protocol\n(layer 1) the world heavyweight champion - Muhammad Ali.\n\nSince I've maintained your interest up to the final sentence, I say:\nas an insurance against a capacity crisis before layer 2 is deployed,\nwhy not implement bip100's 2MB blocksize proposals in a testnet?\n\n\n\nOn 07/30/2015 04:38 PM, Jorge Timón wrote:\n\u003e It is important ro note that even if lightning was never developed,\n\u003e the block size remains at 1 MB forever and fees rise to 10 usd per \n\u003e transaction, such \"high fees\" are still extremely competitive with \n\u003e non-decentralized payment systems that have proportional fees. For \n\u003e example, 10 usd is still lower than 1% when you are moving more\n\u003e than 1000 usd. I know, this doesn't work for micro-transactions,\n\u003e but I don't think Bitcoin can be useful for micro-transactions in\n\u003e the long term unless something like lightning payment channels is\n\u003e deployed. Until we accept the second fact, it will be very hard to\n\u003e discuss any projection of future usage. I think that believing that\n\u003e all the transactions of the entire world population can be made\n\u003e in-chain while keeping bitcoin decentralized is incredibly naive.\n\u003e Not even nasdaq has that capacity (and if full node's require\n\u003e nasdaq's capacity, I don't think we can talk about a decentralized\n\u003e system anymore).\n\u003e \n\u003e On Jul 30, 2015 11:16 AM, \"Venzen Khaosan via bitcoin-dev\" \n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e Adam,\n\u003e \n\u003e - From your explanation it is evident that fast, cheap bitcoin \n\u003e transactions are possible. It is encouraging that Bitcoin _can_\n\u003e indeed compete with Visa, Paypal, et al. via Layer 2 protocols such\n\u003e as Lightning.\n\u003e \n\u003e The youtube interview with you and Greg re: Lightning requires\n\u003e some concentration and I'll have to watch it another couple of\n\u003e times to better grasp everything that is explained about the\n\u003e protocol and its interaction with Bitcoin.\n\u003e \n\u003e Thank you for your considered and informative response, else\n\u003e Raystonn and I might have gotten in an unnecessary scrap about\n\u003e fees, economics and what not.\n\u003e \n\u003e regards, Venzen Khaosan\n\u003e \n\u003e \n\u003e \n\u003e On 07/30/2015 10:49 AM, Adam Back wrote:\n\u003e\u003e I dont think people consider other blockchains as a competitive \n\u003e\u003e threat. A PoW-blockchain is a largely singleton data structure \n\u003e\u003e for security reasons (single highest hashrate), it is hard for\n\u003e\u003e an alternative chain to bootstrap or provide meaningful\n\u003e\u003e security. Secondly the world largely lacks expertise to maintain\n\u003e\u003e a blockchain to bitcoin's security level, perhaps you can see a\n\u003e\u003e hint of this in the recently disclosed security vulnerability by\n\u003e\u003e Pieter Wuille and Gregory Maxwell. Calls to this as an argument\n\u003e\u003e are not resonating and probably not helping your argument.\n\u003e\u003e Bitcoin has security properties, and a competing system cant\n\u003e\u003e achieve better properties by bypassing security, any blockchain\n\u003e\u003e faces the same fundamental security / decentralisation\n\u003e\u003e limitations.\n\u003e \n\u003e\u003e Secondly Bitcoin can obviously compete with itself with\n\u003e\u003e different parameters and defacto *does* today. I think it is a\n\u003e\u003e safe estimate that \u003e 99% of Bitcoin transactions right now are\n\u003e\u003e happening in Bitcoin related systems with various degrees of\n\u003e\u003e audit, reconciliation, provable reserves etc. I think we can\n\u003e\u003e expect this to continue and become more secure via more\n\u003e\u003e reconciliation, and longer term via lightning or Bitcoin\n\u003e\u003e sidechains with different parameters. It is a different story to\n\u003e\u003e have a single central system (Bitcoin with parameters changed to\n\u003e\u003e the point of centralisation failure) vs having multiple choices,\n\u003e\u003e because some transactions can more easily use relatively\n\u003e\u003e centralised systems (eg micropayments), and more interestingly\n\u003e\u003e the combination of a secure and decentralised layer 1 plus\n\u003e\u003e choices of less decentralised layer 2 options, can be interesting\n\u003e\u003e because the layer 2 is provided cover from attack. There is less\n\u003e\u003e to be gained by attacking relatively centralised layer 2 because\n\u003e\u003e any payments at risk of policy abuse (which is typically a small\n\u003e\u003e subset) can easily switch to layer 1. That in itself makes layer\n\u003e\u003e 2 transactions also less susceptible to policy abuse. Further\n\u003e\u003e lightning it appears from work so far should add significant\n\u003e\u003e scale while retaining trustlessness and a good degree of\n\u003e\u003e decentralisation.\n\u003e \n\u003e\u003e Finally you seem to be focusing on \"artificial\" limits where\n\u003e\u003e that is not the issue under consideration. The limits are\n\u003e\u003e technical and relating to decentralisation and security. I wont\n\u003e\u003e go over them again as this topic has been covered many times in\n\u003e\u003e recent months. Any chain that tried to go to extreme parameters\n\u003e\u003e (very low block intervals, or very large blocksizes) would have\n\u003e\u003e the same decentralisation problems as Bitcoin would if it did the\n\u003e\u003e same thing. There are a number of alt coins that have failed as\n\u003e\u003e a result of poor parameter choices, there are inherent security \n\u003e\u003e limits.\n\u003e \n\u003e\u003e Adam\n\u003e \n\u003e\u003e ps Etiquette note for yourself and others: please dont be \n\u003e\u003e repetitive or attempt to be forceful. Many people have spent\n\u003e\u003e many years understanding this very complex system, from my own \n\u003e\u003e experience it is rare indeed to think of an entirely new concept\n\u003e\u003e or analysis, that hasnt' been long considered and put to bed 3 or\n\u003e\u003e 4 years ago. Thoughtful polite and constructive comments are\n\u003e\u003e welcome but I recommend to not start from an assumption that you\n\u003e\u003e have a clear and better insight than the entire technical\n\u003e\u003e community, because I have to say from my own experience that is\n\u003e\u003e very rarely the case. It can be useful to test theories on\n\u003e\u003e #bitcoin IRC channel to find out what has been already concluded,\n\u003e\u003e find the references and avoid having to have that hashed out on\n\u003e\u003e this list which is trying to be focussed on technical solutions.\n\u003e \n\u003e \n\u003e\u003e On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev \n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e\u003e\u003e Cheapest way to send value? Is this what Bitcoin is trying\n\u003e\u003e\u003e\u003e to do? So all of the smart contract, programmable money,\n\u003e\u003e\u003e\u003e consensus coding and tremendous developer effort is bent to\n\u003e\u003e\u003e\u003e the consumer demand for cheaper fees. Surely thou jests!\n\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e\u003e These other features can be replicated into any alternative \n\u003e\u003e\u003e blockchain, including those with lower fees. In the\n\u003e\u003e\u003e open-source world of cryptocurrency, no feature will remain a\n\u003e\u003e\u003e value-add for very long after it has been identified to be\n\u003e\u003e\u003e such. Anything adding value will quickly be absorbed into\n\u003e\u003e\u003e competing alternative blockchains. That will leave economic\n\u003e\u003e\u003e policy as the distinguishing factor.\n\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e ... it is not the case ... that reluctance to concede\n\u003e\u003e\u003e\u003e blocksize is an attempt to constrain capacity. Greg Maxwell\n\u003e\u003e\u003e\u003e thoroughly explained in this thread that the protocol's\n\u003e\u003e\u003e\u003e current state of development relies on blocksize for\n\u003e\u003e\u003e\u003e security and, ultimately, as a means of protecting its degree\n\u003e\u003e\u003e\u003e of decentralization.\n\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e\u003e A slow or lack of increase to maximum transaction rate will\n\u003e\u003e\u003e cause pressure on fees. Whether this is the desired goal is\n\u003e\u003e\u003e not relevant. Everyone has agreed this will be the outcome.\n\u003e\u003e\u003e As to a smaller block size being needed for additional\n\u003e\u003e\u003e decentralization, one must simply ask how much we are all\n\u003e\u003e\u003e willing to pay for that additional decentralization. It is\n\u003e\u003e\u003e likely that the benefit thereto will have to be demonstrated by\n\u003e\u003e\u003e some power attacking and destroying a less decentralized\n\u003e\u003e\u003e currency before the benefit of this feature is given monetary\n\u003e\u003e\u003e value by the market. Until then, value will bleed to the\n\u003e\u003e\u003e network with the least friction, because it will have the\n\u003e\u003e\u003e greatest ability to grow its network effect. That means the\n\u003e\u003e\u003e blockchain with adequate features and cheapest fees will\n\u003e\u003e\u003e eventually have the largest market share.\n\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e\u003e -----Original Message----- From: Venzen Khaosan Sent:\n\u003e\u003e\u003e Wednesday, July 29, 2015 3:11 PM To: Raystonn . Cc: \n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e Subject: Re: \n\u003e [bitcoin-dev]\n\u003e\u003e\u003e Why Satoshi's temporary anti-spam measure isn'ttemporary\n\u003e\u003e\u003e \n\u003e\u003e Raystonn, I'm aware that you're addressing your question to Greg \n\u003e\u003e Maxwell, however a point you keep stating as fact calls for \n\u003e\u003e reference:\n\u003e \n\u003e\u003e On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote: [snip]\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e How do you plan to address the bleeding of value from\n\u003e\u003e\u003e\u003e\u003e Bitcoin to alternative lower-fee blockchains created by\n\u003e\u003e\u003e\u003e\u003e the artificially-high bitcoin transaction fees when users\n\u003e\u003e\u003e\u003e\u003e begin looking for the cheapest way to send value?\n\u003e \n\u003e\u003e Cheapest way to send value? Is this what Bitcoin is trying to\n\u003e\u003e do? So all of the smart contract, programmable money, consensus\n\u003e\u003e coding and tremendous developer effort is bent to the consumer\n\u003e\u003e demand for cheaper fees. Surely thou jests!\n\u003e \n\u003e\u003e\u003e\u003e\u003e Modern economic study has shown that liquidity moves to\n\u003e\u003e\u003e\u003e\u003e the location of least friction.\n\u003e \n\u003e\u003e Modern economic study? Can you please provide a link or\n\u003e\u003e reference to the study you are referring to.\n\u003e \n\u003e\u003e \"liquidity moves to the location of least friction\"\n\u003e \n\u003e\u003e This sounds like \"econo-speak\" and makes no sense. The\n\u003e\u003e definition of Liquidity is the degree to which an asset/security\n\u003e\u003e can be bought or sold in the market without affecting the price.\n\u003e \n\u003e\u003e That is why bitcoin is said to have low liquidity: buying or \n\u003e\u003e selling only 100 BTC visibly affects the exchange price. You \n\u003e\u003e probably mean \"people like cheap fees\", which is true, but as \n\u003e\u003e others have said, because of Bitcoin's powerful features, they\n\u003e\u003e are willing to pay higher fees and wait longer for transactions\n\u003e\u003e to execute.\n\u003e \n\u003e\u003e As for your public cross-examination of Greg Maxwell, your case \n\u003e\u003e seems to be made on the assumption that limiting the size of\n\u003e\u003e the blockchain is an attempt to artificially raise tx fees, but\n\u003e\u003e it is not the case (as you and others repeatedly argue) that\n\u003e\u003e reluctance to concede blocksize is an attempt to constrain\n\u003e\u003e capacity. Greg Maxwell thoroughly explained in this thread that\n\u003e\u003e the protocol's current state of development relies on blocksize\n\u003e\u003e for security and, ultimately, as a means of protecting its degree\n\u003e\u003e of decentralization.\n\u003e \n\u003e\u003e Surely, this is an obvious concern even for those who are \n\u003e\u003e campaigning for the hare-brained ideal of making Bitcoin a\n\u003e\u003e \"faster, cheaper alternative\" to visa or paypal? If we lose \n\u003e\u003e decentralization, we lose the whole thing, right? Incorrect or \n\u003e\u003e correct?\n\u003e\u003e\u003e _______________________________________________ bitcoin-dev \n\u003e\u003e\u003e mailing list bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________ bitcoin-dev mailing\n\u003e list bitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVuieTAAoJEGwAhlQc8H1meAIH/RHUV72bbMItZOT7rvhEU56r\nlqEcvwXBSCYgsh1ieVeTdC/ydJnRSzWsdZxM3D7PEOzutlG+VaJQVSJREItGb2GW\nPYiZ3uwSwF64nRq5bZ7aS2pT/Zo1a1yAf4H5rbeyxxoWC+zkmSsmcf73MgmslIuU\n7XXHNztCX3glfOctr+J61WEKBw0ItQCTsp9J08yVlj/gvKTi3U2jDcYV5mf/3D0j\npvXl244DG4b+nYetRyyonYbZelSUYfCghNBJhUYZApVmcgfKDRPeX1uWfkl0HuUd\nKc+uZtrhJaUXdRlqc50nOsRSCAK+d4PGClF8JFlzI65+SG7VzkVqc8SkSDfNXfY=\n=r4SA\n-----END PGP SIGNATURE-----",
"sig": "a487110c67b9b74fadb48f39568005453689778b933f79ba701bd36383824d4def051ad9cfc334d529e9c0607dc9b98daf4aed107dcc561ef965009e96c6492a"
}