path: root/de/02d8094cb52a3300554d377236ec3cd7052aed

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>&gt; <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>&nbsp;</DIV>
<DIV><FONT face=3DCalibri>No, this would essentially be blessing an =
increase to=20
42M bitcoins, half on each chain.&nbsp; You could expect a severe market =
price=20
correction if this were to happen.</FONT></DIV>
<DIV>&nbsp;</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>&nbsp;</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">&nbsp;</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>&nbsp;</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">&nbsp;</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">&nbsp;</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">&nbsp;</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">&nbsp;</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">&nbsp;</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">&nbsp;</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">&nbsp;</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>&nbsp;</DIV>
<DIV class=3Dgmail_quote>On Mon, Jun 15, 2015 at 1:50 PM, Mike Hearn =
<SPAN=20
dir=3Dltr>&lt;<A href=3D"mailto:mike@plan99.net"=20
target=3D_blank>mike@plan99.net</A>&gt;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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--