From: Jared Lee Richardson <jaredr26@gmail•com>
To: Luv Khemani <luvb@hotmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Date: Thu, 30 Mar 2017 10:16:41 -0700 [thread overview]
Message-ID: <CAD1TkXsj53JRYhqot2aHSQR+HEDKm7+6S5kGtaLYBCoc24PuWg@mail.gmail.com> (raw)
In-Reply-To: <SINPR04MB1949AB581C6870184445E0C4C2340@SINPR04MB1949.apcprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 9203 bytes --]
> You are only looking at technical aspects and missing the political
aspect.
Nodes don't do politics. People do, and politics is a lot larger with a
lot more moving parts than just node operation.
> full nodes protect the user from the change of any properties of Bitcoin
which they do not agree with.
Full nodes protect from nothing if the chain they attempt to use is
nonfunctional.
> The ability to retain this power for users is of prime importance and is
arguably what gives Bitcoin most of it's value
> Any increase in the cost to run a full node is an increase in cost to
maintain monetary sovereignty
This power is far more complicated than just nodes. You're implying that
node operation == political participation. Node operation is only a very
small part of the grand picture of the bitcoin balance of power.
> The ability for a user to run a node is what keeps the miners honest and
prevents them from rewriting any of Bitcoin's rules.
No, it isn't. Nodes disagreeing with miners is necessary but not
sufficient to prevent that. Nodes can't utilize a nonfunctional chain, nor
can they utilize a coin with no exchanges.
> What makes Bitcoin uncensorable
Only two things - 1. Node propagation being strong enough that a target
node can't be surrounded by attacker nodes (or so that attacker nodes can't
segment honest nodes), and 2. Miners being distributed in enough countries
and locations to avoid any single outside attacker group from having enough
leverage to prevent transaction inclusion, and miners also having enough
incentives(philosophical or economic) to refuse to collude towards
transaction exclusion.
Being able to run a node yourself has no real effect on either of the two.
Either we have enough nodes that an attacker can't segment the network or
we don't.
> What gives confidence that the 21 million limit will be upheld
What you're describing would result in a fork war. The opposition to this
would widespread and preventing an attempt relies upon mutual destruction.
If users refused to get on board, exchanges would follow users. If miners
refused to get on board, the attempt would be equally dead in the water.
It would require a majority of users, businesses and miners to change the
limit; Doing so without an overwhelming majority(90% at least) would still
result in a contentious fork that punished both sides(in price, confidence,
adoption, and possibly chain or node attacks) for refusing to agree.
Nodes have absolutely no say in the matter if they can't segment the
network, and even if they could their impact could be repaired. Users !=
Nodes.
> What makes transactions irreversible
Err, this makes me worry that you don't understand how blockchains work...
This is because miners are severely punished for attempting to mine on
anything but the longest chain. Nodes have absolutely no say in the
matter, they always follow the longest chain unless a hardfork was
applied. If the hardfork has overwhelming consensus, i.e. stopping a 51%
attack, then the attack would be handled. If the hardfork did not have
overwhelming consensus it would result in another fork war requiring users,
businesses, and miners to actively decide which to support and how, and
once again would involve mutual destruction on both forks.
Nodes don't decide any of these things. Nodes follow the longest chain,
and have no practical choices in the matter. Users not running nodes
doesn't diminish their power - Mutual destruction comes from the market
forces on the exchanges, and they could give a rats ass whether you run a
node or not.
> The market is not storing 10s of billions of dollars in Bitcoin despite
all it's risks because it is useful for everyday transactions, that is a
solved problem in every part of the world (Cash/Visa/etc..).
This is just the "bitcoin is gold" argument. Bitcoin is not gold. For
someone not already a believer, Bitcoin is a risky, speculative investment
into a promising future technology, whereas gold is a stable physical asset
with 4,000 years of acceptance history that has the same value in nearly
every city on the planet. Bitcoin is difficult to purchase and difficult
to find someone to exchange for goods or services. Literally the only
reason we have 10s of billions of dollars of value is because speculation,
which includes nearly all Bitcoin users/holders and almost all businesses
and miners. While Bitcoin borrows useful features from gold, it has more
possible uses, including uses that were never possible before Bitcoin
existed, and we believe that gives it huge potential.
The ability of other systems to do transactions, like visa or cash, come
with the limitations of those systems. Bitcoin was designed to break those
limitations and STILL provide the ability to do transactions. We might all
agree Bitcoin isn't going to ever solve the microtransaction problem, at
least not on-chain, but saying Bitcoin doesn't need utility is just
foolish. Gold doesn't need utility, gold has 4,000 years of history. We
don't.
> Even if we fork to 2MB, 5MB, 10MB. It is irrelevant in the larger
picture, transaction capacity will still be too low for global usage in the
medium-long term.
Which is why it needs to be a formula or a continuous process, not a single
number.
> Even if it fails to live up to the hype, you should not discount the
market innovating solutions when there is money to be made.
That's like saying it would be better to do nothing so someone else solves
our problem for us than it would be for us to do what we can to solve it
ourselves. Someone else solving our problem may very well be Ethereum, and
"solving it for us" is pulling Bitcoin investments, users and nodes away
into Ethereum.
> The additional capacity from blocksize increases are linear improvements
with very large systemic costs compared with the userbase and usage which
is growing exponentially.
The capacity increases do not have to be linear. The increases in utility
are linear with blocksize increases, but so are the costs. There's no
reason those blocksize increases can't be tied to or related to usage
increases, so long as the concerns about having too few nodes (or too few
fees) for security are handled.
On Thu, Mar 30, 2017 at 12:11 AM, Luv Khemani <luvb@hotmail•com> wrote:
>
> >> If home users are not running their own full nodes, then home users
> have to trust and rely on other, more powerful nodes to represent them. Of
> course, the more powerful nodes, simply by nature of having more power, are
> going to have different opinions and objectives from the users.
>
> >I think you're conflating mining with node operation here. Node users
> only power is to block the propagation of certain things. Since miners
> also have a node endpoint, they can cut the node users out of the equation
> by linking with eachother directly - something they already do out of
> practicality for propagation. Node users do not have the power to
> arbitrate consensus, that is why we have blocks and PoW.
>
> You are only looking at technical aspects and missing the political aspect.
>
> Node users decide what a Bitcoin is. It matters not how much hash power is
> behind a inflationary supply chain fork, full nodes protect the user from
> the change of any properties of Bitcoin which they do not agree with. The
> ability to retain this power for users is of prime importance and is
> arguably what gives Bitcoin most of it's value. Any increase in the cost to
> run a full node is an increase in cost to maintain monetary sovereignty.
> The ability for a user to run a node is what keeps the miners honest and
> prevents them from rewriting any of Bitcoin's rules.
>
> If it's still difficult to grasp the above paragraph, ask yourself the
> following questions,
> - What makes Bitcoin uncensorable
> - What gives confidence that the 21 million limit will be upheld
> - What makes transactions irreversible
> - If hashpower was king as you make it to be, why havn't miners making up
> majority hashrate who want bigger blocks been able to change the blocksize?
>
> The market is not storing 10s of billions of dollars in Bitcoin despite
> all it's risks because it is useful for everyday transactions, that is a
> solved problem in every part of the world (Cash/Visa/etc..).
>
> Having said that, i fully empathise with your view that increasing
> transaction fees might allow competitors to gain marketshare for low value
> use cases. By all means, we should look into ways of solving the problem.
> But all these debates around blocksize is a total waste of time. Even if we
> fork to 2MB, 5MB, 10MB. It is irrelevant in the larger picture, transaction
> capacity will still be too low for global usage in the medium-long term.
> The additional capacity from blocksize increases are linear improvements
> with very large systemic costs compared with the userbase and usage which
> is growing exponentially. Lightning potentially offers a couple or orders
> of magnitude of scaling and will make blocksize a non-issue for years to
> come. Even if it fails to live up to the hype, you should not discount the
> market innovating solutions when there is money to be made.
>
>
[-- Attachment #2: Type: text/html, Size: 15954 bytes --]
next prev parent reply other threads:[~2017-03-30 17:16 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 19:33 Daniele Pinna
2017-03-29 20:28 ` Peter R
2017-03-29 22:17 ` Jared Lee Richardson
2017-03-29 20:28 ` David Vorick
2017-03-29 22:08 ` Jared Lee Richardson
2017-03-30 7:11 ` Luv Khemani
2017-03-30 17:16 ` Jared Lee Richardson [this message]
2017-03-31 4:21 ` Luv Khemani
2017-03-31 5:28 ` Jared Lee Richardson
2017-03-31 8:19 ` Luv Khemani
2017-03-31 15:59 ` Jared Lee Richardson
2017-03-31 16:14 ` David Vorick
2017-03-31 16:46 ` Jared Lee Richardson
2017-03-31 18:23 ` David Vorick
2017-03-31 18:58 ` Eric Voskuil
2017-04-01 6:15 ` Jared Lee Richardson
-- strict thread matches above, loose matches on Subject: below --
2017-03-31 21:23 Rodney Morris
2017-03-31 23:13 ` Eric Voskuil
[not found] ` <CABerxhGeofH4iEonjB1xKOkHcEVJrR+D4QhHSw5cWYsjmW4JpQ@mail.gmail.com>
2017-04-01 1:41 ` Rodney Morris
2017-04-01 6:18 ` Jared Lee Richardson
2017-04-01 7:41 ` Eric Voskuil
[not found] ` <CAAt2M1_sHsCD_AX-vm-oy-4tY+dKoDAJhfVUc4tnoNBFn-a+Dg@mail.gmail.com>
[not found] ` <CAAt2M19Gt8PmcPUGUHKm2kpMskpN4soF6M-Rb46HazKMV2D9mg@mail.gmail.com>
2017-04-01 14:45 ` Natanael
[not found] ` <CAD1TkXusCe-O3CGQkXyRw_m3sXS9grGxMqkMk8dOvFNXeV5zGQ@mail.gmail.com>
2017-04-01 18:42 ` Jared Lee Richardson
[not found] ` <CAAt2M1_kuCBQWd9dis5UwJX8+XGVPjjiOA54aD74iS2L0cYcTQ@mail.gmail.com>
[not found] ` <CAAt2M19Nr2KdyRkM_arJ=LBnqDQQyLQ2QQ-UBC8=gFnemCdPMg@mail.gmail.com>
2017-04-01 13:26 ` Natanael
2017-03-29 19:50 Raystonn .
2017-03-30 10:34 ` Tom Zander
2017-03-30 11:19 ` David Vorick
2017-03-30 21:42 ` Jared Lee Richardson
2017-03-30 11:24 ` Aymeric Vitte
2017-03-28 19:56 Paul Iverson
2017-03-28 20:16 ` Pieter Wuille
2017-03-28 20:43 ` Tom Zander
2017-03-28 20:53 ` Alphonse Pace
2017-03-28 21:06 ` Luke Dashjr
2017-03-28 16:59 Wang Chun
2017-03-28 17:13 ` Matt Corallo
2017-03-29 8:45 ` Jared Lee Richardson
2017-03-28 17:23 ` Alphonse Pace
2017-03-28 17:31 ` Wang Chun
2017-03-28 17:33 ` Jeremy
2017-03-28 17:50 ` Douglas Roark
2017-03-28 17:33 ` Juan Garavaglia
2017-03-28 17:53 ` Alphonse Pace
2017-03-28 22:36 ` Juan Garavaglia
2017-03-29 2:59 ` Luv Khemani
2017-03-29 6:24 ` Emin Gün Sirer
2017-03-29 15:34 ` Johnson Lau
2017-04-01 16:15 ` Leandro Coutinho
2017-03-29 9:16 ` Jared Lee Richardson
2017-03-29 16:00 ` Aymeric Vitte
2017-03-28 17:34 ` Johnson Lau
2017-03-28 17:46 ` Luke Dashjr
2017-03-28 20:50 ` Tom Zander
2017-03-29 4:21 ` Johnson Lau
2017-03-28 20:48 ` Tom Zander
2017-03-29 6:32 ` Bram Cohen
2017-03-29 9:37 ` Jorge Timón
2017-03-29 19:07 ` Jared Lee Richardson
2017-04-02 19:02 ` Staf Verhaegen
2017-03-29 7:49 ` Martin Lízner
2017-03-29 15:57 ` David Vorick
2017-03-29 16:08 ` Aymeric Vitte
[not found] ` <CAFVRnyo1XGNbq_F8UfqqJWHCVH14iMCUMU-R5bOh+h3mtwSUJg@mail.gmail.com>
2017-03-29 16:18 ` David Vorick
2017-03-29 16:20 ` Andrew Johnson
2017-03-29 16:25 ` David Vorick
2017-03-29 16:41 ` Andrew Johnson
2017-03-29 17:14 ` Aymeric Vitte
2017-03-29 20:53 ` Jared Lee Richardson
2017-03-29 20:32 ` Jared Lee Richardson
2017-03-29 21:36 ` praxeology_guy
2017-03-29 22:33 ` Aymeric Vitte
2017-03-30 5:23 ` Ryan J Martin
2017-03-30 10:30 ` Tom Zander
2017-03-30 16:44 ` Jared Lee Richardson
2017-03-30 20:51 ` Jared Lee Richardson
2017-03-30 21:57 ` Tom Zander
[not found] ` <CAD1TkXvx=RKvjC8BUstwtQxUUQwG4eiU9XmF1wr=bU=xcVg5WQ@mail.gmail.com>
2017-03-30 10:13 ` Aymeric Vitte
2017-03-29 19:46 ` Jared Lee Richardson
2017-03-29 19:10 ` Jared Lee Richardson
2017-03-29 19:36 ` praxeology_guy
2017-04-02 19:12 ` Staf Verhaegen
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=CAD1TkXsj53JRYhqot2aHSQR+HEDKm7+6S5kGtaLYBCoc24PuWg@mail.gmail.com \
--to=jaredr26@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luvb@hotmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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