From: Andrew <onelineproof@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains
Date: Mon, 15 Jun 2015 18:00:17 +0000 [thread overview]
Message-ID: <CAL8tG=k90nzt9w99QjSx5R=+LeBxkfVvcEvcNAyVkJHkaQZAgg@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP1D0AN_iRobD2RYXHCCWhU7Vk6yZ35+ytsQ0zonSCG_HQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3192 bytes --]
next prev parent reply other threads:[~2015-06-15 18:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 2:55 Andrew
2015-05-25 18:15 ` Mike Hearn
2015-05-28 2:16 ` Andrew
2015-05-28 2:34 ` Bryan Bishop
2015-06-13 14:39 ` Pieter Wuille
2015-06-13 17:55 ` Andrew
2015-06-14 6:55 ` Martin Schwarz
2015-06-15 17:05 ` Andrew
2015-06-15 17:09 ` Pieter Wuille
2015-06-15 17:15 ` Jeff Garzik
2015-06-16 18:17 ` Peter Todd
2015-06-16 18:43 ` Andrew
2015-06-16 19:04 ` Andrew
2015-06-15 17:18 ` Mike Hearn
2015-06-15 18:00 ` Andrew [this message]
2015-06-16 15:23 ` Andrew
2015-06-15 18:01 ` Jeff Garzik
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='CAL8tG=k90nzt9w99QjSx5R=+LeBxkfVvcEvcNAyVkJHkaQZAgg@mail.gmail.com' \
--to=onelineproof@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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