MIME-Version: 1.0
In-Reply-To: <COL131-DS5331AE0C03A2BF6E0553ECDB80@phx.gbl>
References: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
	<CANEZrP1nx9rNf1q-nubP77U8RMABuLtmEB_P7UpY2zyFf-Ns-w@mail.gmail.com>
	<CALqxMTENbj+E7ypJASrM1r04eW3kYe+afwy+Rt3i9ubeT-=2mA@mail.gmail.com>
	<CANEZrP0Z_EOmVgbvVmYDvegm6jfd1cKB52acXHocjRuM-qGEog@mail.gmail.com>
	<CAPg+sBgc0i-XsN=g0V4Y0bko-Xb1AT5x=UWDa+opL3eFbBmJfA@mail.gmail.com>
	<CANEZrP0eGDTafK+ZUBNcQBOe2JU_PqZVXMt0Ds-b8Ley7kbGrA@mail.gmail.com>
	<CAPg+sBiPhhrBh8f3QxJLtoysfywtVFSo2RH0WXVR+vpX9z6+HQ@mail.gmail.com>
	<CANEZrP10gn+969d-oe-8Em9ipe4DOP9q0WkNtL6u-6V5aphkPQ@mail.gmail.com>
	<CAFBxzAAExA-aE+8o-+HGQtnuwWuWpkt8Lbgxvh7hT64XkMKOPg@mail.gmail.com>
	<COL131-DS5331AE0C03A2BF6E0553ECDB80@phx.gbl>
Date: Mon, 15 Jun 2015 20:14:56 +0200
Message-ID: <CALqxMTF2T0Wgt15bmjkpMK199vhwH+ufYw+LJU7AEzx4X7dykQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: "Raystonn ." <raystonn@hotmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
Precedence: list

I think he's more talking about like extension-blocks, however they
are actually soft-forkable even (and keep the 21m coins obviously)

See  See https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07937.html

and Tier Nolan tech detail
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07927.html

Discussion / claimed properties on

https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/

Adam

On 15 June 2015 at 19:53, Raystonn . <raystonn@hotmail.com> wrote:
>> The solution is to hard-fork and merge-mine. This way, both can live, and
>> mining power is not divided.
>
> No, this would essentially be blessing an increase to 42M bitcoins, half on
> each chain.  You could expect a severe market price correction if this were
> to happen.
>
> From: Rebroad (sourceforge)
> Sent: Monday, June 15, 2015 4:16 AM
> Cc: Bitcoin Dev
> Subject: Re: [Bitcoin-development] comments on BIP 100
>
> My understanding of this debate is that there are some people who want to
> keep Bitcoin at 1MB block limit, and there are some who want to increase it.
>
> I for one am curious to see how 1MB limited bitcoin evolves, and I believe
> we can all have a chance to see this AND hard-fork bitcoin to remove the
> block size restriction.
>
> To remove the 1MB limit required a hard fork. This is not disputed. It's
> what we do with the original (1MB limit) bitcoin that concerns me (and
> other's I am sure).
>
> What I would like to see is both being allowed to live. Harry Potter and
> Voldermort! (Except neither are evil!)
>
> The solution is to hard-fork and merge-mine. This way, both can live, and
> mining power is not divided.
>
> Dogecoin recently hardforked and this hardfork also involved switching to
> merge-mining, so it's been done successfully.
>
> So, simply, bitcoin as it is doesn't need to actually fork, but instead, at
> a certain block size, a forked bitcoin with the blocksize lmit removed will
> start to be merge-mined alongside bitcoin. Miners can be ready for this.
> Wallets can be ready for this - in fact, for most wallets and merchants they
> will possibly want to default to the bigger blocksize fork since this caters
> for more transactions per block.
>
> We still don't know how removing the block limit will pan out and what other
> problems with scalability will arise in the future, so by preserving the
> original bitcoin, we keep diversity, and people won't feel their investments
> in bitcoin are being unnecessarily put at risk (as their investments will
> stay in both the new and the old bitcoin).
>
> The bitcoin core developers can implement a patch like the one recently used
> for dogecoin, to allow the chain to fork at a set point, where at which
> point, bitcoins will be split into the new and the old. Branding will be an
> important issue here I think, so that there is as little confusion as
> possible. I think this is a small price to pay in return for not killing the
> original bitcoin (even if it's true that Satoshi did intend to remove the
> 1MB limit at some point).
>
> If I'm missing something obvious please let me know.
>
> On Mon, Jun 15, 2015 at 1:50 PM, Mike Hearn <mike@plan99.net> wrote:
>>>
>>> The fact that using a centralized service is easier isn't a good reason
>>> IMHO. It disregards the long-term, and introduces systemic risk.
>>
>>
>> Well sure, that's easy for you to say, but you have a salary :) Other
>> developers may find the incremental benefits of decentralisation low vs
>> adding additional features, for instance, and who is to say they are wrong?
>>
>>>
>>> But in cases where using a decentralized approach doesn't *add* anything,
>>> I cannot reasonably promote it, and that's why I was against getutxos in the
>>> P2P protocol.
>>
>>
>> It does add something though! It means, amongst other things, I can switch
>> of all my servers, walk away for good, discard this Mike Hearn pseudonym I
>> invented for Bitcoin and the app will still work :) Surely that is an
>> important part of being decentralised?
>>
>> It also means that as the underlying protocol evolves over time, getutxos
>> can evolve along side it. P2P protocol gets encrypted/authenticated? Great,
>> one more additional bit of security. If one day miners commit to UTXO sets,
>> great, one more additional bit of security. When we start including input
>> values in the signature hash, great ... one more step up in security.
>>
>> Anyway, I didn't really want to reopen this debate. I just point out that
>> third party services are quite happy to provide whatever developers need to
>> build great apps, even if doing so fails to meet some kind of perfect
>> cryptographic ideal. And that's why they're winning devs.
>>
>> Now back to your regularly scheduled block size debates ...
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ________________________________
> ------------------------------------------------------------------------------
>
> ________________________________
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>