Peter Todd [ARCHIVE] on Nostr: š Original date posted:2015-06-16 š Original message:On Mon, Jun 15, 2015 at ...
š
Original date posted:2015-06-16
š Original message:On Mon, Jun 15, 2015 at 01:15:14PM -0400, Jeff Garzik wrote:
> On Mon, Jun 15, 2015 at 1:09 PM, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>
> > 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.
> >
>
> As noted to Adam last night - although I agree it adds complexity - side
> chains are one solution that will indeed help with scaling long term.
> Similar to the graph you see with git repos and merges, having aggregation
> chains that arbitrarily fork and then rejoin the main chain are both
> feasible and useful.
>
> That code & future is a ways away from production, so doesn't help us
> here. Still, let's not dismiss it as a solution either.
To be clear, it depends on what kind of sidechain.
My off-chain transaction notions are federated sidechains with an
economic incentive to not commit fraud using fidelity bonds; they were
definitely proposed as a scaling solution.
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)
Keep in mind that other than preserving mining
decentralization/resisting censorship, we've known how to scale up
blockchains for ages w/ things like (U)TXO commitments and fraud proofs.
--
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/3fa76edc/attachment.sig>;
š Original message:On Mon, Jun 15, 2015 at 01:15:14PM -0400, Jeff Garzik wrote:
> On Mon, Jun 15, 2015 at 1:09 PM, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>
> > 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.
> >
>
> As noted to Adam last night - although I agree it adds complexity - side
> chains are one solution that will indeed help with scaling long term.
> Similar to the graph you see with git repos and merges, having aggregation
> chains that arbitrarily fork and then rejoin the main chain are both
> feasible and useful.
>
> That code & future is a ways away from production, so doesn't help us
> here. Still, let's not dismiss it as a solution either.
To be clear, it depends on what kind of sidechain.
My off-chain transaction notions are federated sidechains with an
economic incentive to not commit fraud using fidelity bonds; they were
definitely proposed as a scaling solution.
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)
Keep in mind that other than preserving mining
decentralization/resisting censorship, we've known how to scale up
blockchains for ages w/ things like (U)TXO commitments and fraud proofs.
--
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/3fa76edc/attachment.sig>;