From: Andrew <onelineproof@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains
Date: Tue, 16 Jun 2015 19:04:44 +0000 [thread overview]
Message-ID: <CAL8tG=m6qgANCunZAnm8m_r_tBYq9Kw3XgA7s_ZzKkyCyCEd8w@mail.gmail.com> (raw)
In-Reply-To: <CAL8tG==iJwqPBVTDap=8TC9eCUz4ExfxtGz6p75FXbQJXaByMQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]
Actually, I have to think about this merge-mining thing a bit more. I'm
starting to think it's better to do without merge-mining at all. As I
explained in the forum post, the parent will put the hashes of its children
headers as transactions inside its blocks. Thus parents will have an
incentive to validate the children not by merge mining, but by collecting
fees from the children for putting those transactions inside (fees that can
be spent at the children chains). So, ya no merge mining needed for my
proposal. But I will think about it a bit more :)
On Tue, Jun 16, 2015 at 6:43 PM, Andrew <onelineproof@gmail•com> wrote:
>
>
> On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd <pete@petertodd•org> wrote:
>
>> Merge-mined sidechains are not a scaling solution any more than SPV is a
>> scaling solution because they don't solve the scaling problem for
>> miners.
>>
>> Some kind of treechain like sidechain / subchains where what part of the
>> tree miners can mine is constrained to preserve fairness could be both a
>> scaling solution, and decentralized, but no-one has come up with a solid
>> design yet that's ready for production. (my treechains don't qualify for
>> transactions yet; maybe for other proof-of-publication uses)
>>
>>
> Well doesn't my proposal solve the miner decentralization problem. Only
> the direct parent and children chains are merge mined. To be more clear,
> let the top chain to have level 1. Each chain that is a child of a chain of
> level n has level n+1. For any chain C, a block is accepted if the hash of
> its header has an appropriate number of trailing zeros (as usual). It can
> also be accepted with special transactions as I will explain. Let C be a
> chain of level n. Let C0,C1,....,C9 be its children (each of level n+1).
> For any i in {0,1,...,9}, any solution to the mining problem of C can be
> inserted as a special transaction inside Ci and this enables the block to
> be accepted in Ci (so C and C0,C1,...,C9 are merge mined. But, for any i in
> {0,1,...,9} and any j in {0,1,...,9}, any solution to the mining problem of
> C cannot be inserted as a special transaction inside of child Cij of Ci. So
> that means all of the chains are not merge mined, only localised parts,
> right?
>
> By the way, we can eventually get rid of the block size 1 MB limit by
> requiring more than just the header to be hashed, but that can be done in
> the future as soft fork with sidechains, and is a side topic.
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
>
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
[-- Attachment #2: Type: text/html, Size: 3422 bytes --]
next prev parent reply other threads:[~2015-06-16 19:04 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 [this message]
2015-06-15 17:18 ` Mike Hearn
2015-06-15 18:00 ` Andrew
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=m6qgANCunZAnm8m_r_tBYq9Kw3XgA7s_ZzKkyCyCEd8w@mail.gmail.com' \
--to=onelineproof@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/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