Adam Back [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-15 📝 Original message:I think he's more talking ...
📅 Original date posted:2015-06-15
📝 Original message: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 at 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 at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ________________________________
> ------------------------------------------------------------------------------
>
> ________________________________
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
📝 Original message: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 at 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 at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ________________________________
> ------------------------------------------------------------------------------
>
> ________________________________
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>