MIME-Version: 1.0
In-Reply-To: <1164261435450448@web14h.yandex.ru>
References: <1164261435450448@web14h.yandex.ru>
Date: Sat, 27 Jun 2015 18:52:55 -0700
Message-ID: <CACq0ZD6PUXbfWHABj8TKrQKJpKb3HOENVzaqRMMATk266Hokpw@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Santino Napolitano <santino.napolitano@yandex.com>
Content-Type: multipart/alternative; boundary=001a1147ff42579e3005198a3b52
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Original Vision
Precedence: list

--001a1147ff42579e3005198a3b52
Content-Type: text/plain; charset=UTF-8

This is a reasonable vision, but I think we can do better. We can easily
achieve the goal of letting hobbyists with very limited resources and
connectivity run full nodes. The way to do this is to limit growth of the
blockchain, and the right way to do that is to have fees that reflect the
costs of having large numbers of people validating, storing, and serving
transactions.

I think we're all agreed that decentralization is priority #1. It's what
makes bitcoin unique from everything else. So what then is the best way to
have fees reflect the costs? Having a fixed blocksize (fixed production
quotas) is one very disruptive option that would be a significant departure
from what we have today. The way the network today discourages spam and
other low value uses of the blockchain is with minimum relay fees and
transaction selection rules for blocks. This technique is proven, safe, and
can easily be tuned and experimented with. It's also what all bitcoin
software today is designed to work with.


Aaron Voisine
co-founder and CEO
breadwallet.com

On Sat, Jun 27, 2015 at 5:14 PM, Santino Napolitano <
santino.napolitano@yandex.com> wrote:

>
> There is much heated debate going on right now and I know it can be very
> stressful but I'd like to point out that it is really amazing how
> passionately so many feel about this once very small project. Let's not
> forget there is something really special going on here and we're all part
> of it.
>
> The current debate has little to do with block size or hard-forks, IMO.
> It's about the nature of Bitcoin and what it means to people and how it
> will grow. I would like to take a moment to share my interpretation of the
> original author's intent based on everything I could find and read from
> this person. This is not to say their original vision is paramount-- or
> even that I got it completely correct but I think it might do us some good
> to think about.
>
> It seems as though the incentive conceived of for running a full network
> node was that it would enable mining. The proceeds from mining (new coins
> and transaction fees) would be the reward and provide a reason to continue
> operating these nodes. If fees are ever to be a sufficient reward and still
> allow for a practical and useful system the size of the blocks must grow
> significantly as must the user base. I'm not sure that this is really
> contested but I haven't exhaustively reviewed everyone's opinion so please
> excuse me if I have marginalized you. If you do contest that I would be
> interested in hearing it.
>
> Further, it appears clear that the original author intended organizations
> operating full network nodes would provide connectivity to light clients
> and these light clients would make up the majority of the user base. This
> is completely consistent with current trends in Internet consumption, e.g.
> tablets and phones are becoming more preferred to even owning a traditional
> computer. Having the system be entirely decentralized and trustless for
> every client does not appear to me to be the original design goal. Yes, the
> whitepaper speaks of the design goal as not having a need for a trusted
> third party but it does not say that some amount of trust won't be
> preferred by a majority of users. In fact, in the SPV section it implies
> some amount of localized trust is perhaps a necessary trade-off and maybe
> businesses should still run their own full network node if they want the
> stronger completely trustless guarantee. The global decentralized consensus
> appears meant to make the network r
>  esilient to a single government or other adversary's ability to shut the
> network down. If you really want to trust no one it is your option at a
> cost and should be possible by design. The author further gives evidence
> that they believe Moore's observation would keep the idea of running a full
> network node a practical one at global scale for perpetuity. It does not
> appear as if they intended for every individual to run one at home nor in
> their pocket.
>
> If my interpretation seems incorrect please do point it out. I hope this
> hasn't been too off-topic and distracting. The original author's
> engineering ingenuity is what gave me any interest in this project so
> re-visiting their design and scaling intentions might be helpful for us to
> move forward-- together.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a1147ff42579e3005198a3b52
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This is a reasonable vision, but I think we can do better.=
 We can easily achieve the goal of letting hobbyists with very limited reso=
urces and connectivity run full nodes. The way to do this is to limit growt=
h of the blockchain, and the right way to do that is to have fees that refl=
ect the costs of having large numbers of people validating, storing, and se=
rving transactions.<div><br></div><div>I think we&#39;re all agreed that de=
centralization is priority #1. It&#39;s what makes bitcoin unique from ever=
ything else. So what then is the best way to have fees reflect the costs? H=
aving a fixed blocksize (fixed production quotas) is one very disruptive op=
tion that would be a significant departure from what we have today. The way=
 the network today discourages spam and other low value uses of the blockch=
ain is with minimum relay fees and transaction selection rules for blocks. =
This technique is proven, safe, and can easily be tuned and experimented wi=
th. It&#39;s also what all bitcoin software today is designed to work with.=
</div><div><br></div></div><div class=3D"gmail_extra"><br clear=3D"all"><di=
v><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><di=
v><br>Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"http://bread=
wallet.com" target=3D"_blank">breadwallet.com</a></div></div></div></div></=
div></div>
<br><div class=3D"gmail_quote">On Sat, Jun 27, 2015 at 5:14 PM, Santino Nap=
olitano <span dir=3D"ltr">&lt;<a href=3D"mailto:santino.napolitano@yandex.c=
om" target=3D"_blank">santino.napolitano@yandex.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><br>
There is much heated debate going on right now and I know it can be very st=
ressful but I&#39;d like to point out that it is really amazing how passion=
ately so many feel about this once very small project. Let&#39;s not forget=
 there is something really special going on here and we&#39;re all part of =
it.<br>
<br>
The current debate has little to do with block size or hard-forks, IMO. It&=
#39;s about the nature of Bitcoin and what it means to people and how it wi=
ll grow. I would like to take a moment to share my interpretation of the or=
iginal author&#39;s intent based on everything I could find and read from t=
his person. This is not to say their original vision is paramount-- or even=
 that I got it completely correct but I think it might do us some good to t=
hink about.<br>
<br>
It seems as though the incentive conceived of for running a full network no=
de was that it would enable mining. The proceeds from mining (new coins and=
 transaction fees) would be the reward and provide a reason to continue ope=
rating these nodes. If fees are ever to be a sufficient reward and still al=
low for a practical and useful system the size of the blocks must grow sign=
ificantly as must the user base. I&#39;m not sure that this is really conte=
sted but I haven&#39;t exhaustively reviewed everyone&#39;s opinion so plea=
se excuse me if I have marginalized you. If you do contest that I would be =
interested in hearing it.<br>
<br>
Further, it appears clear that the original author intended organizations o=
perating full network nodes would provide connectivity to light clients and=
 these light clients would make up the majority of the user base. This is c=
ompletely consistent with current trends in Internet consumption, e.g. tabl=
ets and phones are becoming more preferred to even owning a traditional com=
puter. Having the system be entirely decentralized and trustless for every =
client does not appear to me to be the original design goal. Yes, the white=
paper speaks of the design goal as not having a need for a trusted third pa=
rty but it does not say that some amount of trust won&#39;t be preferred by=
 a majority of users. In fact, in the SPV section it implies some amount of=
 localized trust is perhaps a necessary trade-off and maybe businesses shou=
ld still run their own full network node if they want the stronger complete=
ly trustless guarantee. The global decentralized consensus appears meant to=
 make the network r<br>
=C2=A0esilient to a single government or other adversary&#39;s ability to s=
hut the network down. If you really want to trust no one it is your option =
at a cost and should be possible by design. The author further gives eviden=
ce that they believe Moore&#39;s observation would keep the idea of running=
 a full network node a practical one at global scale for perpetuity. It doe=
s not appear as if they intended for every individual to run one at home no=
r in their pocket.<br>
<br>
If my interpretation seems incorrect please do point it out. I hope this ha=
sn&#39;t been too off-topic and distracting. The original author&#39;s engi=
neering ingenuity is what gave me any interest in this project so re-visiti=
ng their design and scaling intentions might be helpful for us to move forw=
ard-- together.<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>

--001a1147ff42579e3005198a3b52--