diff options
| author | Andrew <onelineproof@gmail.com> | 2015-06-15 18:00:17 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-15 18:00:25 +0000 |
| commit | 81d7ac00c31c28cc1b22f549355f9d54738ca2c2 (patch) | |
| tree | 75883238dad7ca8e11ffb701403c99d95f8afc35 /c8 | |
| parent | 11734bdd6cd95d61d68dd6c835e2346fc5e08d4f (diff) | |
| download | pi-bitcoindev-81d7ac00c31c28cc1b22f549355f9d54738ca2c2.tar.gz pi-bitcoindev-81d7ac00c31c28cc1b22f549355f9d54738ca2c2.zip | |
Re: [Bitcoin-development] Scaling Bitcoin with Subchains
Diffstat (limited to 'c8')
| -rw-r--r-- | c8/5fa713c1828057756dcd76f3ec2340b3131c2b | 170 |
1 files changed, 170 insertions, 0 deletions
diff --git a/c8/5fa713c1828057756dcd76f3ec2340b3131c2b b/c8/5fa713c1828057756dcd76f3ec2340b3131c2b new file mode 100644 index 000000000..fcb99f7d4 --- /dev/null +++ b/c8/5fa713c1828057756dcd76f3ec2340b3131c2b @@ -0,0 +1,170 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <akaramaoun@gmail.com>) id 1Z4YgL-0002KQ-2y + for bitcoin-development@lists.sourceforge.net; + Mon, 15 Jun 2015 18:00:25 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.213.182 as permitted sender) + client-ip=209.85.213.182; envelope-from=akaramaoun@gmail.com; + helo=mail-ig0-f182.google.com; +Received: from mail-ig0-f182.google.com ([209.85.213.182]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Z4YgJ-0004bb-9C + for bitcoin-development@lists.sourceforge.net; + Mon, 15 Jun 2015 18:00:25 +0000 +Received: by igblz2 with SMTP id lz2so56301176igb.1 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 15 Jun 2015 11:00:18 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.50.132.33 with SMTP id or1mr22730574igb.31.1434391217984; + Mon, 15 Jun 2015 11:00:17 -0700 (PDT) +Sender: akaramaoun@gmail.com +Received: by 10.64.20.229 with HTTP; Mon, 15 Jun 2015 11:00:17 -0700 (PDT) +In-Reply-To: <CANEZrP1D0AN_iRobD2RYXHCCWhU7Vk6yZ35+ytsQ0zonSCG_HQ@mail.gmail.com> +References: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com> + <CAPg+sBjqQ66f1Rmhi9HOBYP5BDjBHvTNPpUN-y3o-KX8dXBMhg@mail.gmail.com> + <557D2571.601@gmail.com> + <CAL8tG=kEv9AfQM+1Rv+tqBujFEjCp+BsjQ-1s7eJC-usogFFqw@mail.gmail.com> + <CAPg+sBjrSed4r+8-d2RGBVhbzaXxX+o=qqw2u-2jpF2RUqmEmA@mail.gmail.com> + <CANEZrP1D0AN_iRobD2RYXHCCWhU7Vk6yZ35+ytsQ0zonSCG_HQ@mail.gmail.com> +Date: Mon, 15 Jun 2015 18:00:17 +0000 +X-Google-Sender-Auth: _0oag2jWAH5voaBhzh94Hk7ssWA +Message-ID: <CAL8tG=k90nzt9w99QjSx5R=+LeBxkfVvcEvcNAyVkJHkaQZAgg@mail.gmail.com> +From: Andrew <onelineproof@gmail.com> +To: Mike Hearn <mike@plan99.net> +Content-Type: multipart/alternative; boundary=047d7b1636e10470d40518923be6 +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 + (akaramaoun[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 +X-Headers-End: 1Z4YgJ-0004bb-9C +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 15 Jun 2015 18:00:25 -0000 + +--047d7b1636e10470d40518923be6 +Content-Type: text/plain; charset=UTF-8 + +Pieter: I kind of see your point (but I think you're missing some key +points). You mean just download all the headers and then just verify the +transactions you filter out by using their corresponding merkle trees, +right? But still, I don't think that would scale as well as with the tree +structure I propose. Because, firstly, you don't really need the headers of +the sibling chains. You just need the headers of the parent chains since +the parent verifies all the siblings. All you really need in a typical +(non-mining) situation is the headers or full blocks in one path going down +the tree starting from the root chain. So that means O(log n) needs to be +stored (headers or blocks) (n the number of transaction on the network). +With big blocks, you still need O(n) headers. I know headers are small, but +still they take up space and verification time. Also, since you are storing +the full blocks on the chains you want, you are validating the headers of +those blocks and you are sure that you are seeing all transactions on those +blocks. And if certain addresses must stay on those blocks, you will know +that you are catching all of the transactions corresponding to those +blocks. If you just filter out based on addresses or other criteria, you +can be denied some of those transactions by full nodes, and you may not +know about it. Say for example, your government representative publishes on +of his public addresses that is used for paying for expenses. Then with my +system, you can be sure to catch every transaction being spent from that +address (or UTXO or whatever you want to call it). If you just filter on +any transaction that includes that address, you may not catch all of those +transactions. Same with incoming funds. + +There are also advantages for mining decentralization as I have explained +in my previous posts. So still not sure you are right here... + +Thanks + +On Mon, Jun 15, 2015 at 5:18 PM, Mike Hearn <mike@plan99.net> wrote: + +> It's simple: either you care about validation, and you must validate +>> everything, or you don't, and you don't validate anything. +>> +> Pedantically: you could validate a random subset of all scripts, to give +> yourself probabilistic verification rather than full vs SPV. If enough +> people do it with a large enough subset the probability of a problem being +> detected goes up a lot. You still pay the cost of the database updates. +> +> But your main point is of course completely right, that side chains are +> not a way to scale up. +> + + + +-- +PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 + +--047d7b1636e10470d40518923be6 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Pieter: I kind of see your point (but I think you're m= +issing some key points). You mean just download all the headers and then ju= +st verify the transactions you filter out by using their corresponding merk= +le trees, right? But still, I don't think that would scale as well as w= +ith the tree structure I propose. Because, firstly, you don't really ne= +ed the headers of the sibling chains. You just need the headers of the pare= +nt chains since the parent verifies all the siblings. All you really need i= +n a typical (non-mining) situation is the headers or full blocks in one pat= +h going down the tree starting from the root chain. So that means O(log n) = +needs to be stored (headers or blocks) (n the number of transaction on the = +network). With big blocks, you still need O(n) headers. I know headers are = +small, but still they take up space and verification time. Also, since you = +are storing the full blocks on the chains you want, you are validating the = +headers of those blocks and you are sure that you are seeing all transactio= +ns on those blocks. And if certain addresses must stay on those blocks, you= + will know that you are catching all of the transactions corresponding to t= +hose blocks. If you just filter out based on addresses or other criteria, y= +ou can be denied some of those transactions by full nodes, and you may not = +know about it. Say for example, your government representative publishes on= + of his public addresses that is used for paying for expenses. Then with my= + system, you can be sure to catch every transaction being spent from that a= +ddress (or UTXO or whatever you want to call it). If you just filter on any= + transaction that includes that address, you may not catch all of those tra= +nsactions. Same with incoming funds.<br><br>There are also advantages for m= +ining decentralization as I have explained in my previous posts. So still n= +ot sure you are right here...<br><br>Thanks<br></div><div class=3D"gmail_ex= +tra"><br><div class=3D"gmail_quote">On Mon, Jun 15, 2015 at 5:18 PM, Mike H= +earn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_bl= +ank">mike@plan99.net</a>></span> wrote:<br><blockquote class=3D"gmail_qu= +ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= +"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><s= +pan class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= +;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">It's simpl= +e: either you care about validation, and you must validate everything, or y= +ou don't, and you don't validate anything.</p></blockquote></span><= +div>Pedantically: you could validate a random subset of all scripts, to giv= +e yourself probabilistic verification rather than full vs SPV. If enough pe= +ople do it with a large enough subset the probability of a problem being de= +tected goes up a lot. You still pay the cost of the database updates.</div>= +<div><br></div><div>But your main point is of course completely right, that= + side chains are not a way to scale up.=C2=A0<br></div></div></div></div> +</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig= +nature">PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647</div> +</div> + +--047d7b1636e10470d40518923be6-- + + |