path: root/b4/ae55a00ca642587f9377c8b6fcdb89d6949457

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <raystonn@hotmail.com>) id 1YyNKI-0001x1-Qb
	for bitcoin-development@lists.sourceforge.net;
	Fri, 29 May 2015 16:40:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of hotmail.com
	designates 65.55.34.212 as permitted sender)
	client-ip=65.55.34.212; envelope-from=raystonn@hotmail.com;
	helo=COL004-OMC4S10.hotmail.com; 
Received: from col004-omc4s10.hotmail.com ([65.55.34.212])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1YyNKH-0006lh-CR
	for bitcoin-development@lists.sourceforge.net;
	Fri, 29 May 2015 16:40:06 +0000
Received: from COL131-DS8 ([65.55.34.199]) by COL004-OMC4S10.hotmail.com over
	TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); 
	Fri, 29 May 2015 09:39:59 -0700
X-TMN: [ISpkfygm10rKeQjYrWTMyeBoXrB5zWcM]
X-Originating-Email: [raystonn@hotmail.com]
Message-ID: <COL131-DS8AE5724250D730A8B03C5CDC90@phx.gbl>
From: "Raystonn ." <raystonn@hotmail.com>
To: "Tier Nolan" <tier.nolan@gmail.com>
References: <16096345.A1MpJQQkRW@crushinator><CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com><CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com><CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com><CANEZrP2BaKwhpPgcUHWAHswOmUeFLgEk4ysrn4+73qNzWDJ=yQ@mail.gmail.com><CABsx9T3nCJ-w_v-yEbEE2Ytb+xC65mhYqhoAhoOHw9tkPpG0TA@mail.gmail.com><CANEZrP1qH+zucYsGrMgnfi99e61Edxaj+xm=u_xYXga1g0WzJQ@mail.gmail.com><CAE-z3OVmw+0doCe0hmYE6A1D61h0AUh4Mtnf5Fg1e4zQBkpraQ@mail.gmail.com><CANEZrP0psA7hcJdKdA-r01UEt7ig3O-9vjwBMqKSEq-csu0hPQ@mail.gmail.com><CABsx9T23r_y2R9OEgqb3AAZf47Hh8BUJncjxxmPp5v_9uKEiqQ@mail.gmail.com><CAE-z3OXEGcUYYAsqqrVMQw=XA=5dt9u7XHDmuzhMJ8OkZ+k3yg@mail.gmail.com>
	<CAE-z3OU8Vtmi_UK=nF1UNLsXCwd17mKDMS1qKudYB_kwDbOguA@mail.gmail.com>
In-Reply-To: <CAE-z3OU8Vtmi_UK=nF1UNLsXCwd17mKDMS1qKudYB_kwDbOguA@mail.gmail.com>
Date: Fri, 29 May 2015 09:39:29 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_006C_01D099F3.5C447F80"
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: 29 May 2015 16:39:59.0647 (UTC)
	FILETIME=[1A7012F0:01D09A2E]
X-Spam-Score: 0.5 (/)
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.212 listed in list.dnswl.org]
	-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	1.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YyNKH-0006lh-CR
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB
	stepfunction
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: Fri, 29 May 2015 16:40:06 -0000

------=_NextPart_000_006C_01D099F3.5C447F80
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Regarding Tier=E2=80=99s proposal: The lower security you mention for =
extended blocks would delay, possibly forever, the larger blocks maximum =
block size that we want for the entire network.  That doesn=E2=80=99t =
sound like an optimal solution.

Regarding consensus for larger maximum block size, what we are seeing on =
this list is typical of what we see in the U.S. Congress.  Support for =
changes by the stakeholders (support for bills by the citizens as a =
whole) has become irrelevant to the probability of these changes being =
adopted.  Lobbyists have all the sway in getting their policies enacted. =
 In our case, I would bet on some lobbying of core developers by wealthy =
miners.

Someone recently proposed that secret ballots could help eliminate the =
power of lobbyists in Congress.  Nobody invests in that which cannot be =
confirmed.  Secret ballots mean the vote you are buying cannot be =
confirmed.  Perhaps this will work for Bitcoin Core as well.


From: Tier Nolan=20
Sent: Friday, May 29, 2015 7:22 AM
Cc: Bitcoin Dev=20
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB =
stepfunction

On Fri, May 29, 2015 at 3:09 PM, Tier Nolan <tier.nolan@gmail.com> =
wrote:



  On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen =
<gavinandresen@gmail.com> wrote:

    But if there is still no consensus among developers but the "bigger =
blocks now" movement is successful, I'll ask for help getting big miners =
to do the same, and use the soft-fork block version voting mechanism to =
(hopefully) get a majority and then a super-majority willing to produce =
bigger blocks. The purpose of that process is to prove to any doubters =
that they'd better start supporting bigger blocks or they'll be left =
behind, and to give them a chance to upgrade before that happens.

  How do you define that the movement is successful?


Sorry again, I keep auto-sending from gmail when trying to delete.


In theory, using the "nuclear option", the block size can be increased =
via soft fork.


Version 4 blocks would contain the hash of the a valid extended block in =
the coinbase.


<block height> <32 byte extended hash>


To send coins to the auxiliary block, you send them to some template.


OP_P2SH_EXTENDED <scriptPubKey hash> OP_TRUE


This transaction can be spent by anyone (under the current rules).  The =
soft fork would lock the transaction output unless it transferred money =
from the extended block.


To unlock the transaction output, you need to include the txid of =
transaction(s) in the extended block and signature(s) in the scriptSig.


The transaction output can be spent in the extended block using P2SH =
against the scriptPubKey hash.


This means that people can choose to move their money to the extended =
block.  It might have lower security than leaving it in the root chain.


The extended chain could use the updated script language too.


This is obviously more complex than just increasing the size though, but =
it could be a fallback option if no consensus is reached.  It has the =
advantage of giving people a choice.  They can move their money to the =
extended chain or not, as they wish.



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



-------------------------------------------------------------------------=
-------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

------=_NextPart_000_006C_01D099F3.5C447F80
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>Regarding Tier=E2=80=99s proposal: The lower security you mention =
for extended=20
blocks would delay, possibly forever, the larger blocks maximum block =
size that=20
we want for the entire network.&nbsp; That doesn=E2=80=99t sound like an =
optimal=20
solution.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regarding consensus for larger maximum block size, what we are =
seeing on=20
this list is typical of what we see in the U.S. Congress.&nbsp; Support =
for=20
changes by the stakeholders (support for bills by the citizens as a =
whole) has=20
become irrelevant to the probability of these changes being =
adopted.&nbsp;=20
Lobbyists have all the sway in getting their policies enacted.&nbsp; In =
our=20
case, I would bet on some lobbying of core developers by wealthy =
miners.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Someone recently proposed that secret ballots could help eliminate =
the=20
power of lobbyists in Congress.&nbsp; Nobody invests in that which =
cannot be=20
confirmed.&nbsp; Secret ballots mean the vote you are buying cannot be=20
confirmed.&nbsp; Perhaps this will work for Bitcoin Core as well.</DIV>
<DIV>&nbsp;</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 style=3D"FONT: 10pt tahoma">
<DIV>&nbsp;</DIV>
<DIV style=3D"BACKGROUND: #f5f5f5">
<DIV style=3D"font-color: black"><B>From:</B> <A =
title=3Dtier.nolan@gmail.com=20
href=3D"mailto:tier.nolan@gmail.com">Tier Nolan</A> </DIV>
<DIV><B>Sent:</B> Friday, May 29, 2015 7:22 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] Proposed alternatives to =
the 20MB=20
stepfunction</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>
<DIV class=3Dgmail_extra>
<DIV class=3Dgmail_quote>On Fri, May 29, 2015 at 3:09 PM, Tier Nolan =
<SPAN=20
dir=3Dltr>&lt;<A href=3D"mailto:tier.nolan@gmail.com"=20
target=3D_blank>tier.nolan@gmail.com</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>&nbsp;</DIV>
  <DIV class=3Dgmail_extra>
  <DIV>&nbsp;</DIV>
  <DIV class=3Dgmail_quote><SPAN>On Fri, May 29, 2015 at 1:39 PM, Gavin =
Andresen=20
  <SPAN dir=3Dltr>&lt;<A href=3D"mailto:gavinandresen@gmail.com"=20
  target=3D_blank>gavinandresen@gmail.com</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></DIV>
    <DIV>But if there is still no consensus among developers but the =
"bigger=20
    blocks now" movement is successful, I'll ask for help getting big =
miners to=20
    do the same, and use the soft-fork block version voting mechanism to =

    (hopefully) get a majority and then a super-majority willing to =
produce=20
    bigger blocks. The purpose of that process is to prove to any =
doubters that=20
    they'd better start supporting bigger blocks or they'll be left =
behind, and=20
    to give them a chance to upgrade before that =
happens.</DIV></DIV></BLOCKQUOTE>
  <DIV>&nbsp;</DIV></SPAN>
  <DIV>How do you define that the movement is=20
  successful?<BR></DIV></DIV></DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>Sorry again, I keep auto-sending from gmail when trying to=20
delete.<BR><BR></DIV>
<DIV>In theory, using the "nuclear option", the block size can be =
increased via=20
soft fork.<BR></DIV>
<DIV>&nbsp;</DIV>
<DIV></DIV>
<DIV>Version 4 blocks would contain the hash of the a valid extended =
block in=20
the coinbase.<BR><BR></DIV>
<DIV>&lt;block height&gt; &lt;32 byte extended hash&gt;<BR></DIV>
<DIV>&nbsp;</DIV>
<DIV>To send coins to the auxiliary block, you send them to some=20
template.<BR><BR></DIV>
<DIV>OP_P2SH_EXTENDED &lt;scriptPubKey hash&gt; OP_TRUE<BR><BR></DIV>
<DIV>This transaction can be spent by anyone (under the current =
rules).&nbsp;=20
The soft fork would lock the transaction output unless it transferred =
money from=20
the extended block.<BR><BR></DIV>
<DIV>To unlock the transaction output, you need to include the txid of=20
transaction(s) in the extended block and signature(s) in the=20
scriptSig.<BR><BR></DIV>
<DIV>The transaction output can be spent in the extended block using =
P2SH=20
against the scriptPubKey hash.<BR></DIV>
<DIV>&nbsp;</DIV>
<DIV>This means that people can choose to move their money to the =
extended=20
block.&nbsp; It might have lower security than leaving it in the root=20
chain.<BR><BR></DIV>
<DIV>The extended chain could use the updated script language =
too.<BR><BR></DIV>
<DIV>This is obviously more complex than just increasing the size =
though, but it=20
could be a fallback option if no consensus is reached.&nbsp; It has the=20
advantage of giving people a choice.&nbsp; They can move their money to =
the=20
extended chain or not, as they wish.<BR></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_006C_01D099F3.5C447F80--