path: root/07/de9cf74e8ae87783798124d986e0fe2e09ffc2

Return-Path: <venzen@mail.bihthai.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B8A2F282
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 09:16:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bihthai.net (unknown [5.255.87.165])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6D81D112
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 09:16:30 +0000 (UTC)
Received: from [10.8.0.6] (unknown [10.8.0.6])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested) (Authenticated sender: venzen)
	by mail.bihthai.net (Postfix) with ESMTPSA id C824320C01;
	Thu, 30 Jul 2015 11:18:06 +0200 (CEST)
Message-ID: <55B9EB68.9020703@mail.bihthai.net>
Date: Thu, 30 Jul 2015 16:16:24 +0700
From: Venzen Khaosan <venzen@mail.bihthai.net>
Reply-To: venzen@mail.bihthai.net
Organization: Bihthai Bai Mai
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Adam Back <adam@cypherspace.org>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>	<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>	<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>	<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>	<37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org>	<CAAS2fgSaRqxi3X0J3F05nA-tyRRikY1whkpAOuGJJpFSAR017w@mail.gmail.com>	<COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl>	<55B94FAD.7040205@mail.bihthai.net>	<COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
	<CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
In-Reply-To: <CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
OpenPGP: id=1CF07D66;
	url=pool.sks-keyservers.net
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE
	autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2015 09:16:31 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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@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@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@lists.linuxfoundation.org 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVuetlAAoJEGwAhlQc8H1m2TkH/jKx7V9vCZbOjbxAlfjnR0ai
+QDxMm0K0sL/MlsLVm0FAHwGiKhYJnEeXiZJlXu0eiUz35JALDMtSQiVbQzcHAc2
GvyW3tWUh6+uSfYhsnImQXxlDgCUKIgZvtTM900OWcGXZeLU3W5UdUK5+ietHK0/
1HbZgcljqke+nSsH2aCagd/iNdwCIUcfapsUgB6iPWtZQfLg6SHi8CjbG/Th5Na7
fpA5yJlO4N+Q2JpOVId/LfC7loDCEZtPtYA5NZAsDcEcSIXUycCoGL8LNMIFGJNe
Ko2RNqGeIkb/x8T2USxlkrNUZx/CCF201MMClPLC/LXX1bEMDvO8F0m1TBR1ptg=
=106o
-----END PGP SIGNATURE-----