public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 22:28:33 -0700	[thread overview]
Message-ID: <CAD1TkXtPZ7w+qYqr_hvyeq95aJ2ge1YYkoC1taDkzv1vEMKpog@mail.gmail.com> (raw)
In-Reply-To: <SINPR04MB1949A0AF3AD33B4664417068C2370@SINPR04MB1949.apcprd04.prod.outlook.com>

> Node operation is making a stand on what money you will accept.

> Ie Your local store will only accept US Dollars and not Japanese Yen. Without being able to run a node, you have no way to independently determine what you are receiving, you could be paid Zimbawe Dollars and wouldn't know any better.

Err, no, that's what happens when you double click the Ethereum icon
instead of the Bitcoin icon.  Just because you run "Bitcoin SPV"
instead of "Bitcoin Verify Everyone's Else's Crap" doesn't mean you're
somehow going to get Ethereum payments.  Your verification is just
different and the risks that come along with that are different.  It's
only confusing if you make it confusing.

> This is highly subjective.
> Just because it is nonfunctional to you, does not mean it is nonfunctional to existing users.

If every block that is mined for them is deliberately empty because of
an attacker, that's nonfunctional.  You can use whatever semantics you
want to describe that situation, but that's clearly what I meant.

> Ofcourse it is. Try paying for my goods using BU/Ehtereum/Dash/etc.. or a Bitcoin forked with inflation, you will not get any goods regardless of how much hashrate those coins have.

As above, if someone operates Bitcoin in SPV mode they are not
magically at risk of getting Dashcoins.  They send and receive
Bitcoins just like everyone else running Bitcoin software.  There's no
confusion about it and it doesn't have anything to do with hashrates
of anyone.  It is just a different method of verification with
corresponding different costs of use and different security
guarantees.

> You should also take into consideration the number of independent mining entities it takes to achieve 51% hashrate. It will be of little use to have thousands on independent miners/pools  if 3 large pools make up 51% of hash rate and collude to attack the network.

We're already fucked, China has 61% of the hashrate and the only thing
we can do about it is to wait for the Chinese electrical
supply/demand/transmission system to rebalance itself.  Aside from
that little problem, mining distributions and pool distributions don't
significantly factor into the blocksize debate.  The debate is a
choice between nodes paying more to allow greater growth and adoption,
or nodes constraining adoption in favor of debatable security
concerns.

> Nodes define which network they want to follow.

Do you really consider it choosing when there is only a single option?
 And even if there was, the software would choose it for you?  If it
is a Bitcoin client, it follows the Bitcoin blockchain.  There is no
BU blockchain at the moment, and Bitcoin software can't possibly start
following Ethereum blockchains.

> Without a Node, you don't even get to decide which segement you are on.

Yes you do, if the segment options are known (and if they aren't,
running a node likely won't help you choose either, it will choose by
accident and you'll have no idea).  You would get to choose whose
verifications to request/check from, and thus choose which segment to
follow, if any.

> Ability to run a node and validate rules => Confidence in currency

This is only true for the small minority that actually need that added
level of security & confidence, and the paranoid people who believe
they need it when they really, really don't.  Some guy on reddit
spouted off the same garbage logic, but was much quieter when I got
him to admit that he didn't actually read the code of Bitcoin that he
downloaded and ran, nor any of the code of the updates.  He trusted.
*gasp*

The average person doesn't need that level of security.  They do
however need to be able to use it, which they cannot right now if you
consider "average" to be at least 50% of the population.

> Higher demand => Higher exchange rate

Demand comes from usage and adoption.  Neither can happen us being
willing to give other people the option to trade security features for
lower costs.

> I would not be holding any Bitcoins if it was unfeasible for me to run a Node and instead had to trust some 3rd party that the currency was not being inflated/censored.

Great.  Somehow I think Bitcoin's future involves very few more people
like you, and very many people who aren't paranoid and just want to be
able to send and receive Bitcoins.

> Bitcoin has value because of it's trustless properties. Otherwise, there is no difference between cryptocurrencies and fiat.

No, it has its value for many, many reasons, trustless properties is
only one of them.  What I'm suggesting doesn't involve giving up
trustless properties except in your head (And not even then, since you
would almost certainly be able to afford to run a node for the rest of
your life if Bitcoin's value continues to rise as it has in the past).
And even if it did, there's a lot more reasons that a lot more people
than you would use it.

> Blocksize has nothing to do with utility, only cost of on-chain transactions.

Are you really this dense?  If the cost of on-chain transactions
rises, numerous use cases get killed off.  At $0.10 per tx you
probably won't buy in-game digital microtransactions with it, but you
might buy coffee with it.  At $1 per tx, you probably won't buy coffee
with it but you might pay your ISP bill with it.  At $20 per tx, you
probably won't pay your ISP bill with it, but you might pay your rent.
At $300 per tx you probably won't use it for anything, but a company
purchasing goods from China might.  At $4000 per tx that company
probably won't use it, but international funds settlement for
million-dollar transactions might use it.

At each fee step along the way you kill of hundreds or thousands of
possible uses of Bitcoin.  Killing those off means fewer people will
use it, so they will use something else instead.

> OTOH increasing the blocksize has alot to do with introducing the very limitations that Visa/Cash have.

No they don't.  They only give people the option to pay more for
higher security or to accept lower security and use Bitcoin anyway.

> Why would you risk destroying Bitcoin's primary proposition (removing limitations of Cash/Visa) for insignificant capacity increase?

So far as anyone has presented actual numbers, there's no reason to
believe larger blocksizes endanger anything of the sort, even if I
agreed that that was Bitcoin's primary proposition.  And I don't
believe we need an insignificant capacity increase, I used to think
that way though.  I strongly believe we can handle massive increases
by adjusting our expectations of what nodes do, how they operate, how
they justify the price of their services, and what levels of security
are available and appropriate for various levels of transaction risk.

> Who says nothing is being done? Segwit, Lightning, pre-loaded wallets like Coinbase are all solutions.

Segwit is a miniscule blocksize increase and wholly inadequate
compared to the scope of the problem.  Good for other reasons, though.
Lightning is not Bitcoin, it is something different(but not bad IMO)
that has different features and different consequences.  I guess you
think it is ok that if your lightning node goes offline at the wrong
time, you could lose funds you never transacted with in the first
place?  No?  Oh, then you must be ok with lightning hub centralization
then as well as paying a monthly fee to lightning hubs for their
services.  Wait, that sounds an awful lot like visa....

I have no idea what you're referring to with the pre-loaded wallets point.


On Thu, Mar 30, 2017 at 9:21 PM, Luv Khemani <luvb@hotmail.com> wrote:
>
> > Nodes don't do politics.  People do, and politics is a lot larger with a lot more moving parts than just node operation.
>
>
> Node operation is making a stand on what money you will accept.
>
> Ie Your local store will only accept US Dollars and not Japanese Yen. Without being able to run a node, you have no way to independently determine what you are receiving, you could be paid Zimbawe Dollars and wouldn't know any better.
>
>
> > Full nodes protect from nothing if the chain they attempt to use is nonfunctional.
>
> This is highly subjective.
> Just because it is nonfunctional to you, does not mean it is nonfunctional to existing users.
>
> > This power is far more complicated than just nodes.
>
> I never implied otherwise.
>
> > You're implying that node operation == political participation.
>
> Ofcourse it is. Try paying for my goods using BU/Ehtereum/Dash/etc.. or a Bitcoin forked with inflation, you will not get any goods regardless of how much hashrate those coins have.
>
> > 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.
>
> It's good that you see the importance of this. You should also take into consideration the number of independent mining entities it takes to achieve 51% hashrate. It will be of little use to have thousands on independent miners/pools  if 3 large pools make up 51% of hash rate and collude to attack the network.
>
> >  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;
>
> > 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.
>
> Nodes define which network they want to follow. Without a Node, you don't even get to decide which segement you are on. Either miners decide( for SPV wallets) or your wallet's server decides(Node). You have no control without a
>
> >> What makes transactions irreversible
> >Nodes have absolutely no say in the matter, they always follow the longest chain unless a hardfork was applied.
>
> My bad here, hashpower decides order. This is the sole reason we have mining, to order transactions.
>
> > Mutual destruction comes from the market forces on the exchanges, and they could give a rats ass whether you run a node or not.
>
> Ability to run a node and validate rules => Confidence in currency => Higher demand => Higher exchange rate
>
> I would not be holding any Bitcoins if it was unfeasible for me to run a Node and instead had to trust some 3rd party that the currency was not being inflated/censored. Bitcoin has value because of it's trustless properties. Otherwise, there is no difference between cryptocurrencies and fiat.
>
> > 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.
> > There's no reason those blocksize increases can't be tied to or related to usage increases
>
> Blocksize has nothing to do with utility, only cost of on-chain transactions.
> OTOH increasing the blocksize has alot to do with introducing the very limitations that Visa/Cash have.
> Why would you risk destroying Bitcoin's primary proposition (removing limitations of Cash/Visa) for insignificant capacity increase?
>
> > 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.
>
> Who says nothing is being done? Segwit, Lightning, pre-loaded wallets like Coinbase are all solutions.
>
>
>
>
> 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.
>>
>


  reply	other threads:[~2017-03-31  5:28 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 19:33 [bitcoin-dev] Hard fork proposal from last week's meeting 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
2017-03-31  4:21         ` Luv Khemani
2017-03-31  5:28           ` Jared Lee Richardson [this message]
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=CAD1TkXtPZ7w+qYqr_hvyeq95aJ2ge1YYkoC1taDkzv1vEMKpog@mail.gmail.com \
    --to=jaredr26@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luvb@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