From: "Raystonn ." <raystonn@hotmail•com>
To: "Rebroad \(sourceforge\)" <rebroad+sourceforge.net@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
Date: Mon, 15 Jun 2015 10:53:17 -0700 [thread overview]
Message-ID: <COL131-DS5331AE0C03A2BF6E0553ECDB80@phx.gbl> (raw)
In-Reply-To: <CAFBxzAAExA-aE+8o-+HGQtnuwWuWpkt8Lbgxvh7hT64XkMKOPg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4890 bytes --]
> 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
[-- Attachment #2: Type: text/html, Size: 8033 bytes --]
next prev parent reply other threads:[~2015-06-15 17:53 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 . [this message]
2015-06-15 18:14 ` Adam Back
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=COL131-DS5331AE0C03A2BF6E0553ECDB80@phx.gbl \
--to=raystonn@hotmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=rebroad+sourceforge.net@gmail$(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