From: Adam Back <adam@cypherspace•org>
To: "Raystonn ." <raystonn@hotmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
Date: Mon, 15 Jun 2015 20:14:56 +0200 [thread overview]
Message-ID: <CALqxMTF2T0Wgt15bmjkpMK199vhwH+ufYw+LJU7AEzx4X7dykQ@mail.gmail.com> (raw)
In-Reply-To: <COL131-DS5331AE0C03A2BF6E0553ECDB80@phx.gbl>
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
>
next prev parent reply other threads:[~2015-06-15 18:15 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-14 21:23 Adam Back
2015-06-14 22:23 ` Mike Hearn
2015-06-14 23:58 ` Adam Back
2015-06-15 0:53 ` Eric Lombrozo
2015-06-15 0:55 ` Eric Lombrozo
2015-06-15 4:11 ` Peter Todd
2015-06-15 4:43 ` Eric Lombrozo
2015-06-15 9:27 ` Mike Hearn
2015-06-15 9:39 ` Eric Lombrozo
2015-06-15 10:24 ` Pieter Wuille
2015-06-15 10:36 ` Mike Hearn
2015-06-15 10:40 ` Pieter Wuille
2015-06-15 10:50 ` Mike Hearn
2015-06-15 11:16 ` Rebroad (sourceforge)
2015-06-15 17:53 ` Raystonn .
2015-06-15 18:14 ` Adam Back [this message]
2015-06-15 18:57 ` [Bitcoin-development] The Bitcoin Node Market Raystonn .
2015-06-15 19:18 ` sickpig
2015-06-15 19:36 ` Raystonn .
2015-06-15 20:12 ` sickpig
2015-06-16 3:30 ` Kevin Greene
2015-06-16 3:41 ` Luke Dashjr
2015-06-16 3:49 ` Kevin Greene
2015-06-16 4:05 ` Kevin Greene
2015-06-16 4:12 ` Aaron Voisine
2015-06-16 5:28 ` justusranvier
2015-06-16 5:30 ` Potter QQ
2015-06-16 7:55 ` Aaron Voisine
2015-06-16 13:32 ` justusranvier
2015-06-16 17:04 ` Aaron Voisine
2015-06-16 17:22 ` Aaron Voisine
2015-06-16 15:52 ` devrandom
2015-06-15 4:43 ` [Bitcoin-development] comments on BIP 100 Peter Todd
2015-06-15 9:06 ` Mike Hearn
2015-06-15 2:28 ` Jeff Garzik
2015-06-15 2:44 ` 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=CALqxMTF2T0Wgt15bmjkpMK199vhwH+ufYw+LJU7AEzx4X7dykQ@mail.gmail.com \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=raystonn@hotmail$(echo .)com \
/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