From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4YZh-0006Dc-3x for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 17:53:33 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of hotmail.com designates 65.55.34.216 as permitted sender) client-ip=65.55.34.216; envelope-from=raystonn@hotmail.com; helo=COL004-OMC4S14.hotmail.com; Received: from col004-omc4s14.hotmail.com ([65.55.34.216]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z4YZf-0006xH-Jn for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 17:53:33 +0000 Received: from COL131-DS5 ([65.55.34.201]) by COL004-OMC4S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 15 Jun 2015 10:53:25 -0700 X-TMN: [1sJllhT9HMAxM1t92dQ4Ab0c8lpzmIkd] X-Originating-Email: [raystonn@hotmail.com] Message-ID: From: "Raystonn ." To: "Rebroad \(sourceforge\)" References: In-Reply-To: Date: Mon, 15 Jun 2015 10:53:17 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01D0A759.7C3217D0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-OriginalArrivalTime: 15 Jun 2015 17:53:25.0836 (UTC) FILETIME=[2DC0E8C0:01D0A794] X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raystonn[at]hotmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.55.34.216 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 HTML_MESSAGE BODY: HTML included in message 1.0 FREEMAIL_REPLY From and body contain different freemails -0.1 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z4YZf-0006xH-Jn Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] comments on BIP 100 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 17:53:33 -0000 ------=_NextPart_000_00EE_01D0A759.7C3217D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > 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)=20 Sent: Monday, June 15, 2015 4:16 AM Cc: Bitcoin Dev=20 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.=20 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 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 ...=20 = -------------------------------------------------------------------------= ----- _______________________________________________ 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 ------=_NextPart_000_00EE_01D0A759.7C3217D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
> The = solution is to=20 hard-fork and merge-mine. This way, both can live, and mining power is = not=20 divided.
 
No, this would essentially be blessing an = increase to=20 42M bitcoins, half on each chain.  You could expect a severe market = price=20 correction if this were to happen.
 
From: Rebroad = (sourceforge)
Sent: Monday, June 15, 2015 4:16 AM
Subject: Re: [Bitcoin-development] comments on BIP=20 100
 
My understanding of this = debate is=20 that there are some people who want to keep Bitcoin at 1MB block limit, = and=20 there are some who want to increase it.=20
 
I for one am curious to see how 1MB = limited bitcoin=20 evolves, and I believe we can all have a chance to see this AND = hard-fork=20 bitcoin to remove the block size restriction.
 
To remove the 1MB limit required a hard = fork. This=20 is not disputed. It's what we do with the original (1MB limit) bitcoin = that=20 concerns me (and other's I am sure).
 
What I would like to see is both being = allowed to=20 live. Harry Potter and Voldermort! (Except neither are evil!)
 
The solution is to hard-fork and = merge-mine. This=20 way, both can live, and mining power is not divided.
 
Dogecoin recently hardforked and this = hardfork also=20 involved switching to merge-mining, so it's been done = successfully.
 
So, simply, bitcoin as it is doesn't need = to=20 actually fork, but instead, at a certain block size, a forked bitcoin = with the=20 blocksize lmit removed will start to be merge-mined alongside bitcoin. = Miners=20 can be ready for this. Wallets can be ready for this - in fact, for most = wallets=20 and merchants they will possibly want to default to the bigger blocksize = fork=20 since this caters for more transactions per block.
 
We still don't know how removing the = block limit=20 will pan out and what other problems with scalability will arise in the = future,=20 so by preserving the original bitcoin, we keep diversity, and people = won't feel=20 their investments in bitcoin are being unnecessarily put at risk (as = their=20 investments will stay in both the new and the old bitcoin).
 
The bitcoin core developers can implement = a patch=20 like the one recently used for dogecoin, to allow the chain to fork at a = set=20 point, where at which point, bitcoins will be split into the new and the = old.=20 Branding will be an important issue here I think, so that there is as = little=20 confusion as possible. I think this is a small price to pay in return = for not=20 killing the original bitcoin (even if it's true that Satoshi did intend = to=20 remove the 1MB limit at some point).
 
If I'm missing something obvious please = let me=20 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=20 IMHO. It disregards the long-term, and introduces systemic=20 risk.
 
Well sure, that's easy for you to say, but you have a salary :) = Other=20 developers may find the incremental benefits of decentralisation low = vs adding=20 additional features, for instance, and who is to say they are=20 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=20 getutxos in the P2P = protocol.
 
It does add something though! It means, amongst other things, I = can=20 switch of all my servers, walk away for good, discard this Mike Hearn=20 pseudonym I invented for Bitcoin and the app will still work :) Surely = that is=20 an important part of being decentralised?
 
It also means that as the underlying protocol evolves over time, = getutxos=20 can evolve along side it. P2P protocol gets encrypted/authenticated? = Great,=20 one more additional bit of security. If one day miners commit to UTXO = sets,=20 great, one more additional bit of security. When we start including = input=20 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=20 third party services are quite happy to provide whatever developers = need to=20 build great apps, even if doing so fails to meet some kind of perfect=20 cryptographic ideal. And that's why they're winning devs.
 
Now back to your regularly scheduled block size debates ...=20 =

---------------------------------------------= ---------------------------------

________________________________= _______________
Bitcoin-development=20 mailing list
Bitcoin-develop= ment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-deve= lopment

 

-------------------------------------------------------------------------= -----

_______________________________________________
Bitcoin-development = mailing=20 list
Bitcoin-development@lists.sourceforge.net
https://lists.source= forge.net/lists/listinfo/bitcoin-development
= ------=_NextPart_000_00EE_01D0A759.7C3217D0--