diff options
author | Raystonn . <raystonn@hotmail.com> | 2015-06-15 10:53:17 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-15 17:53:33 +0000 |
commit | 11734bdd6cd95d61d68dd6c835e2346fc5e08d4f (patch) | |
tree | de8bd01e38738715d67c8a847a9fb1b90f2827cc | |
parent | eb03cdb0c36280f6e14e9a8552b18e6c4139d3be (diff) | |
download | pi-bitcoindev-11734bdd6cd95d61d68dd6c835e2346fc5e08d4f.tar.gz pi-bitcoindev-11734bdd6cd95d61d68dd6c835e2346fc5e08d4f.zip |
Re: [Bitcoin-development] comments on BIP 100
-rw-r--r-- | de/02d8094cb52a3300554d377236ec3cd7052aed | 403 |
1 files changed, 403 insertions, 0 deletions
diff --git a/de/02d8094cb52a3300554d377236ec3cd7052aed b/de/02d8094cb52a3300554d377236ec3cd7052aed new file mode 100644 index 000000000..77a82e49a --- /dev/null +++ b/de/02d8094cb52a3300554d377236ec3cd7052aed @@ -0,0 +1,403 @@ +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 <raystonn@hotmail.com>) 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: <COL131-DS5331AE0C03A2BF6E0553ECDB80@phx.gbl> +From: "Raystonn ." <raystonn@hotmail.com> +To: "Rebroad \(sourceforge\)" <rebroad+sourceforge.net@gmail.com> +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> +In-Reply-To: <CAFBxzAAExA-aE+8o-+HGQtnuwWuWpkt8Lbgxvh7hT64XkMKOPg@mail.gmail.com> +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 <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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 ...=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 + +<HTML><HEAD></HEAD> +<BODY dir=3Dltr> +<DIV dir=3Dltr> +<DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial'; COLOR: #000000"> +<DIV>> <FONT face=3DCalibri><FONT style=3D"FONT-SIZE: 9pt">The = +solution is to=20 +hard-fork and merge-mine. This way, both can live, and mining power is = +not=20 +divided.</FONT></FONT></DIV> +<DIV><FONT face=3DCalibri></FONT> </DIV> +<DIV><FONT face=3DCalibri>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.</FONT></DIV> +<DIV> </DIV> +<DIV> +<DIV=20 +style=3D'FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: = +"Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; = +DISPLAY: inline'><FONT=20 +size=3D2 face=3DArial></FONT></DIV> +<DIV style=3D"FONT: 10pt tahoma"> +<DIV style=3D"BACKGROUND: #f5f5f5"> +<DIV style=3D"font-color: black"><B>From:</B> <A=20 +title=3Drebroad+sourceforge.net@gmail.com=20 +href=3D"mailto:rebroad+sourceforge.net@gmail.com">Rebroad = +(sourceforge)</A> </DIV> +<DIV><B>Sent:</B> Monday, June 15, 2015 4:16 AM</DIV> +<DIV><B>Cc:</B> <A title=3Dbitcoin-development@lists.sourceforge.net=20 +href=3D"mailto:bitcoin-development@lists.sourceforge.net">Bitcoin = +Dev</A> </DIV> +<DIV><B>Subject:</B> Re: [Bitcoin-development] comments on BIP=20 +100</DIV></DIV></DIV> +<DIV> </DIV></DIV> +<DIV=20 +style=3D'FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: = +"Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; = +DISPLAY: inline'> +<DIV dir=3Dltr><SPAN style=3D"FONT-SIZE: 12px">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.</SPAN>=20 +<DIV style=3D"FONT-SIZE: 12px"> </DIV> +<DIV style=3D"FONT-SIZE: 12px">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.</DIV> +<DIV style=3D"FONT-SIZE: 12px"><FONT size=3D2 = +face=3DArial></FONT> </DIV> +<DIV style=3D"FONT-SIZE: 12px">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).</DIV> +<DIV style=3D"FONT-SIZE: 12px"> </DIV> +<DIV style=3D"FONT-SIZE: 12px">What I would like to see is both being = +allowed to=20 +live. Harry Potter and Voldermort! (Except neither are evil!)</DIV> +<DIV style=3D"FONT-SIZE: 12px"> </DIV> +<DIV style=3D"FONT-SIZE: 12px">The solution is to hard-fork and = +merge-mine. This=20 +way, both can live, and mining power is not divided.</DIV> +<DIV style=3D"FONT-SIZE: 12px"> </DIV> +<DIV style=3D"FONT-SIZE: 12px">Dogecoin recently hardforked and this = +hardfork also=20 +involved switching to merge-mining, so it's been done = +successfully.</DIV> +<DIV style=3D"FONT-SIZE: 12px"> </DIV> +<DIV style=3D"FONT-SIZE: 12px">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.</DIV> +<DIV style=3D"FONT-SIZE: 12px"> </DIV> +<DIV style=3D"FONT-SIZE: 12px">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).</DIV> +<DIV style=3D"FONT-SIZE: 12px"> </DIV> +<DIV style=3D"FONT-SIZE: 12px">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).</DIV> +<DIV style=3D"FONT-SIZE: 12px"> </DIV> +<DIV style=3D"FONT-SIZE: 12px">If I'm missing something obvious please = +let me=20 +know.</DIV></DIV> +<DIV class=3Dgmail_extra> +<DIV> </DIV> +<DIV class=3Dgmail_quote>On Mon, Jun 15, 2015 at 1:50 PM, Mike Hearn = +<SPAN=20 +dir=3Dltr><<A href=3D"mailto:mike@plan99.net"=20 +target=3D_blank>mike@plan99.net</A>></SPAN> wrote:<BR> +<BLOCKQUOTE class=3Dgmail_quote=20 +style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc = +1px solid"> + <DIV dir=3Dltr> + <DIV class=3Dgmail_extra> + <DIV class=3Dgmail_quote><SPAN> + <BLOCKQUOTE class=3Dgmail_quote=20 + style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: = +#ccc 1px solid"> + <DIV dir=3Dltr> + <DIV class=3Dgmail_extra> + <DIV class=3Dgmail_quote> + <DIV>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.<BR></DIV></DIV></DIV></DIV></BLOCKQUOTE> + <DIV> </DIV></SPAN> + <DIV>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?</DIV><SPAN> + <DIV> </DIV> + <BLOCKQUOTE class=3Dgmail_quote=20 + style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: = +#ccc 1px solid"> + <DIV dir=3Dltr> + <DIV class=3Dgmail_extra> + <DIV class=3Dgmail_quote> + <DIV>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.<BR></DIV></DIV></DIV></DIV></BLOCKQUOTE> + <DIV> </DIV></SPAN> + <DIV>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?</DIV> + <DIV> </DIV> + <DIV>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.</DIV> + <DIV> </DIV> + <DIV>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.</DIV> + <DIV> </DIV> + <DIV>Now back to your regularly scheduled block size debates ...=20 + = +</DIV></DIV></DIV></DIV><BR>---------------------------------------------= +---------------------------------<BR><BR>________________________________= +_______________<BR>Bitcoin-development=20 + mailing list<BR><A=20 + = +href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develop= +ment@lists.sourceforge.net</A><BR><A=20 + = +href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development"= +=20 + rel=3Dnoreferrer=20 + = +target=3D_blank>https://lists.sourceforge.net/lists/listinfo/bitcoin-deve= +lopment</A><BR><BR></BLOCKQUOTE></DIV> +<DIV> </DIV></DIV> +<P> +<HR> +-------------------------------------------------------------------------= +-----<BR> +<P> +<HR> +_______________________________________________<BR>Bitcoin-development = +mailing=20 +list<BR>Bitcoin-development@lists.sourceforge.net<BR>https://lists.source= +forge.net/lists/listinfo/bitcoin-development<BR></DIV></DIV></DIV></BODY>= +</HTML> + +------=_NextPart_000_00EE_01D0A759.7C3217D0-- + + |