Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.175 as permitted sender)
	client-ip=209.85.213.175; envelope-from=akaramaoun@gmail.com;
	helo=mail-ig0-f175.google.com; 
MIME-Version: 1.0
Sender: akaramaoun@gmail.com
In-Reply-To: <557D2571.601@gmail.com>
References: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com>
	<CAPg+sBjqQ66f1Rmhi9HOBYP5BDjBHvTNPpUN-y3o-KX8dXBMhg@mail.gmail.com>
	<557D2571.601@gmail.com>
Date: Mon, 15 Jun 2015 17:05:05 +0000
Message-ID: <CAL8tG=kEv9AfQM+1Rv+tqBujFEjCp+BsjQ-1s7eJC-usogFFqw@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Martin Schwarz <martin.schwarz@gmail.com>
Content-Type: multipart/alternative; boundary=001a113fadb6985b3305189175e2
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains
Precedence: list

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

Hi All,

I talked with Pieter off-list. And I guess the main opposition is that
coins that are coming from chains that you are not directly validating are
not fully validated by you in the sense that you only get an SPV type proof
to prove that miners have accepted those coins. Yes, it's true, but once
blocks have been mined, there is nothing you can really do about it.
Splitting up the transactions into multiple chains doesn't stop someone
from validating all chains, which results in the same validation workload
as a full node with one chain and big blocks that store the same number of
transactions per second. So there is no disadvantage from using this method
compared with having big blocks, and there are clear advantages. The only
excuse is laziness to create a proper system.

Martin: I'm not sure if random independent chains would be so useful since
there are delays with cross chain transfers and you would not be sure if
those chains will be maintained in the future. My idea is more the idea of
extension blocks, i.e. synchronised chains.

Also, some people think that CPU speed and memory size are the only
limitations to running a full node, and they think that it is ok to just
run a heavily pruned node. Pruned nodes (nodes that have less than 10 years
of transactions on their hard drives) are bad for the network. Reasons why
you would want the long term history of transactions on your hard drive:

1) Your computer could have been compromised when you did the initial
validation, so you may want to validate and see all the old transactions
again.

2) You don't have to spend much time to download transactions that you want
to analyze but have already pruned.

3) Risk of denial of service attack from the "archival" nodes.

4) There is less of an inequality between the big data centers and regular
people. We can analyze the history of the transactions that are relevant to
us just as effectively as the data centers. With the pruning model, it will
be more like NSA-style nodes watching our transaction history, while
regular people can only see "snapshots". Remember how the Bitcoin community
was analysing the old Mt Gox transactions using the blockchain? This kind
of stuff will no longer be possible if most people can only run pruned
nodes.

5) The data is more distributed thus more easy for others to download
(think torrent downloads vs downloading from a central server).

6) Again being distributed, more eyes will be looking at the long term
data, thus people can more easily investigate scandals and things like that.

7) Without the full history of blocks people cannot really give a proof to
others that what they noticed with their pruned nodes is actually what
happened (if they spot something interesting).

8) The time for a new user to start fresh and sync a full node with a long
term history of transactions is much more accessible (17 days for 100 years
of transactions with 1 MB blocks on high-end computers). Same with the time
needed to perform any kind of analysis on the old transactions. And
remember, any new transactions likely depend on old transactions, so yes
they are very relevant.

This is not paranoia. These are real security risks. So don't tell me that
you are really running a full node with the same level of security when you
are pruning it. Also, don't tell me that the security of running a full
node remains the same when centralization is increased (like with bigger
block sizes). Centralisation is a security risk.

Some people think that decentralisation means you have to run a possibly
noisy desktop in a possible space restricted home, which can be annoying.
No, you don't have to. You can run a full node (or an almost full node on
the chains you are interested in) in a shack in the middle of nowhere and
you can monitor it remotely with cameras or whatever. The point is that it
is easy for a regular person to run one and they can do so without causing
attention and without anyone's permission. That is decentralisation. Even
10 MB blocks are too much to enable this definition of decentralisation
(according to my calculations).

If there are people who choose to run Gavin/Mike's hard fork of Bitcoin
because they are uniformed or mentally challenged or have bad intentions,
then there is not much I can do (I try to inform but I don't have such a
high popularity level to be effective there), but I will surely not accept
any bitcoin that is only valid on blocks with size greater than 1 million
bytes. Such coins will have 0 or even negative value to me, and I expect
others to do the same.

In the meantime, I will start the development process of my proposed
scaling methods using bitcoin-core and possibly the sidechains code from
Blockstream as a base. I don't have much free time, so progress will likely
be slow, but if I believe in something, I will keep working on it. I'm
still seeking more criticism of my proposal, because you know, I don't want
to waste my time if there's something fundamentally wrong with it.

Cheers

On Sun, Jun 14, 2015 at 6:55 AM, Martin Schwarz <martin.schwarz@gmail.com>
wrote:

> Pieter,
>
> Am 13.06.2015 um 16:39 schrieb Pieter Wuille:
> > We can reasonably assume that different people's wallet will tend to be
> distributed uniformly over several sidechains to hold their transactions
> (if they're not, there is no scaling benefit anyway...). That means that
> for an average transaction, you will need a cross-chain transfer in order
> to get the money to the recipient (as their wallet will usually be
> associated to a chain that is different from your own).
>
> I think we should set the right incentives to invalidate these
> assumptions. If the fees as well as the security guarantees
> on the main chain are highest and fees are dropping with the distance from
> the main chain on each level of side chains,
> wouldn't communities with many internal transactions create their own side
> chain with low fees? I'd expect geographic
> as well as virtual communities to be forming enjoying cheap fees on their
> 'local' chains and expensive but comparabily rare
> 'long distance' fees. One would expect geographic chains (e.g. continents)
> as well as virtual ones (e.g. the Open Bazaar
> users' chain) to form. To save fees, a typical user would maintain a
> wallet in each of her communities which are loaded
> and drained with rare expensive transacations, whereas daily business with
> many transactions is done cheaply within
> each community chain. So, indeed, I would argue that side chains equipped
> with the right cost incentives for cross-chain
> transactions would lead to a scalable and efficiently self-organizing
> network of side chains.
>
> best regards,
> Martin
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>


-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647

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

<div dir=3D"ltr"><div><div><div><div><div><div>Hi All,<br></div><div><br>I =
talked with Pieter off-list. And I guess the main opposition is that coins =
that are coming from chains that you are not directly validating are not fu=
lly validated by you in the sense that you only get an SPV type proof to pr=
ove that miners have accepted those coins. Yes, it&#39;s true, but once blo=
cks have been mined, there is nothing you can really do about it. Splitting=
 up the transactions into multiple chains doesn&#39;t stop someone from val=
idating all chains, which results in the same validation workload as a full=
 node with one chain and big blocks that store the same number of transacti=
ons per second. So there is no disadvantage from using this method compared=
 with having big blocks, and there are clear advantages. The only excuse is=
 laziness to create a proper system.<br><br></div><div>Martin: I&#39;m not =
sure if random independent chains would be so useful since there are delays=
 with cross chain transfers and you would not be sure if those chains will =
be maintained in the future. My idea is more the idea of extension blocks, =
i.e. synchronised chains.<br></div><div><br></div>Also, some people think t=
hat CPU speed and memory size are the only limitations to running a full no=
de, and they think that it is ok to just run a heavily pruned node. Pruned =
nodes (nodes that have less than 10 years of transactions on their hard dri=
ves) are bad for the network. Reasons why you would want the long term hist=
ory of transactions on your hard drive:<br><br>1) Your computer could have =
been compromised when you did the=20
initial validation, so you may want to validate and see all the old=20
transactions again.<br><br>2) You don&#39;t have to spend much time to
 download transactions that you want to analyze but have already pruned.<br=
><br>3) Risk of denial of service attack from the=20
&quot;archival&quot; nodes.<br><br><div>4) There is less of an inequality=
=20
between the big data centers and regular people. We can analyze the=20
history of the transactions that are relevant to us just as effectively=20
as the data centers. With the pruning model, it will be more like=20
NSA-style nodes watching our transaction history, while regular people=20
can only see &quot;snapshots&quot;. Remember how the Bitcoin community was =
analysing the old Mt Gox transactions using the blockchain? This kind of st=
uff will no longer be possible if most people can only run pruned nodes.<br=
><br></div><div>5) The data is more=20
distributed thus more easy for others to download (think torrent=20
downloads vs downloading from a central server).<br><br></div><div>6)=20
Again being distributed, more eyes will be looking at the long term=20
data, thus people can more easily investigate scandals and things like=20
that.<br><br></div>7) Without the full history of blocks people=20
cannot really give a proof to others that what they noticed with their=20
pruned nodes is actually what happened (if they spot something=20
interesting).<br><br></div>8) The time for a new user to start fresh and sy=
nc a full node with a long term history of transactions is much more access=
ible (17 days for 100 years of transactions with 1 MB blocks on high-end co=
mputers). Same with the time needed to perform any kind of analysis on the =
old transactions. And remember, any new transactions likely depend on old t=
ransactions, so yes they are very relevant.<br><br></div>This is not parano=
ia. These are real security risks. So don&#39;t tell me that you are really=
 running a full node with the same level of security when you are pruning i=
t. Also, don&#39;t tell me that the security of running a full node remains=
 the same when centralization is increased (like with bigger block sizes). =
Centralisation is a security risk.<br><br></div>Some people think that dece=
ntralisation means you have to run a possibly noisy desktop in a possible s=
pace restricted home, which can be annoying. No, you don&#39;t have to. You=
 can run a full node (or an almost full node on the chains you are interest=
ed in) in a shack in the middle of nowhere and you can monitor it remotely =
with cameras or whatever. The point is that it is easy for a regular person=
 to run one and they can do so without causing attention and without anyone=
&#39;s permission. That is decentralisation. Even 10 MB blocks are too much=
 to enable this definition of decentralisation (according to my calculation=
s).<br><br></div>If there are people who choose to run Gavin/Mike&#39;s har=
d fork of Bitcoin because they are uniformed or mentally challenged or have=
 bad intentions, then there is not much I can do (I try to inform but I don=
&#39;t have such a high popularity level to be effective there), but I will=
 surely not accept any bitcoin that is only valid on blocks with size great=
er than 1 million bytes. Such coins will have 0 or even negative value to m=
e, and I expect others to do the same.<br><br></div>In the meantime, I will=
 start the development process of my proposed scaling methods using bitcoin=
-core and possibly the sidechains code from Blockstream as a base. I don=
9;t have much free time, so progress will likely be slow, but if I believe =
in something, I will keep working on it. I&#39;m still seeking more critici=
sm of my proposal, because you know, I don&#39;t want to waste my time if t=
here&#39;s something fundamentally wrong with it.<br><div><div><div><div><d=
iv><div><div><div><br></div><div>Cheers<br></div></div></div></div></div></=
div></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Sun, Jun 14, 2015 at 6:55 AM, Martin Schwarz <span dir=3D"ltr">&lt;=
<a href=3D"mailto:martin.schwarz@gmail.com" target=3D"_blank">martin.schwar=
z@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Pieter,=
<br>
<span class=3D""><br>
Am 13.06.2015 um 16:39 schrieb Pieter Wuille:<br>
&gt; We can reasonably assume that different people&#39;s wallet will tend =
to be distributed uniformly over several sidechains to hold their transacti=
ons (if they&#39;re not, there is no scaling benefit anyway...). That means=
 that for an average transaction, you will need a cross-chain transfer in o=
rder to get the money to the recipient (as their wallet will usually be ass=
ociated to a chain that is different from your own).<br>
<br>
</span>I think we should set the right incentives to invalidate these assum=
ptions. If the fees as well as the security guarantees<br>
on the main chain are highest and fees are dropping with the distance from =
the main chain on each level of side chains,<br>
wouldn&#39;t communities with many internal transactions create their own s=
ide chain with low fees? I&#39;d expect geographic<br>
as well as virtual communities to be forming enjoying cheap fees on their &=
#39;local&#39; chains and expensive but comparabily rare<br>
&#39;long distance&#39; fees. One would expect geographic chains (e.g. cont=
inents) as well as virtual ones (e.g. the Open Bazaar<br>
users&#39; chain) to form. To save fees, a typical user would maintain a wa=
llet in each of her communities which are loaded<br>
and drained with rare expensive transacations, whereas daily business with =
many transactions is done cheaply within<br>
each community chain. So, indeed, I would argue that side chains equipped w=
ith the right cost incentives for cross-chain<br>
transactions would lead to a scalable and efficiently self-organizing netwo=
rk of side chains.<br>
<br>
best regards,<br>
Martin<br>
<br>
---------------------------------------------------------------------------=
---<br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=
=3D"gmail_signature">PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53=
B 5647</div>
</div>

--001a113fadb6985b3305189175e2--