Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4XtO-0004TB-27 for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 17:09:50 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.51 as permitted sender) client-ip=209.85.213.51; envelope-from=pieter.wuille@gmail.com; helo=mail-yh0-f51.google.com; Received: from mail-yh0-f51.google.com ([209.85.213.51]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z4XtM-0002ye-63 for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 17:09:50 +0000 Received: by yhan67 with SMTP id n67so47183092yha.3 for ; Mon, 15 Jun 2015 10:09:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.218.86 with SMTP id k83mr35677365ykf.6.1434388182646; Mon, 15 Jun 2015 10:09:42 -0700 (PDT) Received: by 10.37.93.67 with HTTP; Mon, 15 Jun 2015 10:09:42 -0700 (PDT) Received: by 10.37.93.67 with HTTP; Mon, 15 Jun 2015 10:09:42 -0700 (PDT) In-Reply-To: References: <557D2571.601@gmail.com> Date: Mon, 15 Jun 2015 19:09:42 +0200 Message-ID: From: Pieter Wuille To: Andrew Content-Type: multipart/alternative; boundary=001a113aa82618c51b0518918676 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z4XtM-0002ye-63 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 17:09:50 -0000 --001a113aa82618c51b0518918676 Content-Type: text/plain; charset=UTF-8 If you are fine with the SPV security model, you are much better off by just increasing the Bitcoin block size and using an SPV client, as those do not care or even see the full block size by only downloading transactions they care about. Infinite scalability! The problem with scaling is that ultimately even SPV security relies on others being able to validate. Both sidechains and larger block sizes make that harder. It's simple: either you care about validation, and you must validate everything, or you don't, and you don't validate anything. Sidechains do not offer you a useful compromise here, as well as adding huge delays and conplexity. On Jun 15, 2015 7:05 PM, "Andrew" wrote: > 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 > 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 > --001a113aa82618c51b0518918676 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If you are fine with the SPV security model, you are much be= tter off by just increasing the Bitcoin block size and using an SPV client,= as those do not care or even see the full block size by only downloading t= ransactions they care about. Infinite scalability!

The problem with scaling is that ultimately even SPV securit= y relies on others being able to validate. Both sidechains and larger block= sizes make that harder.

It's simple: either you care about validation, and you m= ust validate everything, or you don't, and you don't validate anyth= ing. Sidechains do not offer you a useful compromise here, as well as addin= g huge delays and conplexity.

On Jun 15, 2015 7:05 PM, "Andrew" <= onelineproof@gmail.com> wr= ote:
Hi All,

I talked with Pie= ter 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 b= y 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 m= ined, there is nothing you can really do about it. Splitting up the transac= tions into multiple chains doesn't stop someone from validating all cha= ins, 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 bi= g blocks, and there are clear advantages. The only excuse is laziness to cr= eate a proper system.

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

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

1) Your computer could have been compromise= d when you did the=20 initial validation, so you may want to validate and see all the old=20 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=20 "archival" nodes.

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 "snapshots". 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.
5) The data is more=20 distributed thus more easy for others to download (think torrent=20 downloads vs downloading from a central server).

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.

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).

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.

This is not parano= ia. 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 i= t. 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 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'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= 's permission. That is decentralisation. Even 10 MB blocks are too much= to enable this definition of decentralisation (according to my calculation= s).

If there are people who choose to run Gavin/Mike'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= '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.

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'm still seeking more critici= sm of my proposal, because you know, I don't want to waste my time if t= here's something fundamentally wrong with it.

Cheers

On Sun, Jun 14, 2015 at 6:55 AM, Martin Schwarz <= martin.schwar= z@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 transacti= ons (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 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).

I think we should set the right incentives to invalidate these assum= ptions. 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 s= ide chain with low fees? I'd expect geographic
as well as virtual communities to be forming enjoying cheap fees on their &= #39;local' chains and expensive but comparabily rare
'long distance' fees. One would expect geographic chains (e.g. cont= inents) as well as virtual ones (e.g. the Open Bazaar
users' chain) to form. To save fees, a typical user would maintain a wa= llet 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 w= ith the right cost incentives for cross-chain
transactions would lead to a scalable and efficiently self-organizing netwo= rk of side chains.

best regards,
Martin

---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/= listinfo/bitcoin-development



--
PGP: B= 6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647
--001a113aa82618c51b0518918676--