Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

From: "Jorge Timón" <jtimon@jtimon•cc>
To: Jonathan Toomim <j@toom•im>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Date: Wed, 9 Dec 2015 00:50:35 +0100	[thread overview]
Message-ID: <CABm2gDoUiYb1giLd+=8a-tm+0P0+PLJQpQkffe2DZbN0z887Ww@mail.gmail.com> (raw)
In-Reply-To: <2030FF3C-4F65-44E6-A9D5-9CD144179994@toom.im>

[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]

On Dec 9, 2015 7:41 AM, "Jonathan Toomim via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> I also think that a hard fork is better for SegWit, as it reduces the
size of fraud proofs considerably, makes the whole design more elegant and
less kludgey, and is safer for clients who do not upgrade in a timely
fashion.

I agree, although I disagree with the last reason.

> I don't like the idea that SegWit would invalidate the security
assumptions of non-upgraded clients (including SPV wallets). I think that
for these clients, no data is better than invalid data. Better to force
them to upgrade by cutting them off the network than to let them think
they're validating transactions when they're not.

I don't undesrtand. SPV nodes won't think they are validating transactions
with the new version unless they adapt to the new format. They will be
simply unable to receive payments using the new format if it is a softfork
(although as said I agree with making it a hardfork on the simpler design
and smaller fraud proofs grounds alone).

>
> On Dec 8, 2015, at 11:55 PM, Justus Ranvier via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> > If such a change is going to be deployed via a soft fork instead of a
> > hard fork, then the coinbase is the worst place to put the segwitness
> > merkle root.
> >
> > Instead, put it in the first output of the generation transaction as an
> > OP_RETURN script.
> >
> > This is a better pattern because coinbase space is limited while output
> > space is not. The next time there's a good reason to tie another merkle
> > tree to a block, that proposal can be designated for the second output
> > of the generation transaction.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2509 bytes --]