path: root/0f/ed2b0221484f0a8171db0ae2b5a06f83b16346

Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 05973BC8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  7 Dec 2017 21:40:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com
	[209.85.128.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6C92179
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  7 Dec 2017 21:39:58 +0000 (UTC)
Received: by mail-wr0-f181.google.com with SMTP id x49so8927923wrb.13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 07 Dec 2017 13:39:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=EzU7AcGxPP+NzKHAe0avWU5gunfw7DjYn8nxNLW4gkk=;
	b=DMkq+RdOba7E4SJkyN2JdrFYd/xFZ878WBjzcDL+bULG7cOTBAfv5k2jMwkPgjEmcC
	cZJCudX1gh0Y84DRcrVPIR9R5E9yHgwJJ2t/HDuk4aICcs5DpEkKVt8GtQsZX3l7828F
	bPDwYO+g+OKng7QLzJwVG8lKl9SdHye7pON+UysFHwAY6CfGFaiazJxfU+0pFYBHxmc6
	5w2fnyfIIyUfxjK/m+AqiB0JQOkr9dFfIuHnkxHaNAmmwqxUTPxebSF/6WcY+UvGSP7L
	FB2Y6hBQYwGgcjghki0+ilWjXTz/h924nO40QzibWxFRzgMWd8VkFSYfcyX0a1WI/L7u
	COBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=EzU7AcGxPP+NzKHAe0avWU5gunfw7DjYn8nxNLW4gkk=;
	b=QRaJfaROhod5p97jy/s4awzOptA77EmVfSECqaPCjmd+/mhqbprdnbSHYyvpl1OZtb
	k0xfx/GZ1+KSupVSTBrX3y/6WkmhnYjStJybPMwMGkwcUoVx6vwocPpSyCxPQ12Xht4S
	IarZaSbSrV30RCiAorJtOFauHsTP2aeBdaCKo+KKggm+76FNt+0oa+JSzq9aZcxl5CT0
	Xj2b/nRemxiEJa8N7tcZN0MmLJt7DatD2KjAIp+oss1kugxeTCTx7NQD7CC/6xm2yV1u
	ySVQOkqYz1PVKUiJYB588Bqr2qTE+ypwPXATvHXEiW/qL7gkqyhe9BfT2DDQaIOiuS7/
	Fk0A==
X-Gm-Message-State: AJaThX50MJ9kySu3mAqyohZkKi3r7lpPfJat4YZwVe290m5swkI76ED4
	ngqp0h/8T8Xc5B46DLripJUs037G+TKsRzFndUigmUA=
X-Google-Smtp-Source: AGs4zMaNiXFNTNWTPNnr9Slqg6RZMKYXr3JxIhVuultpryYq9raQScIilEM5AwEqokUDyNna0HVRTGWK+JEh/wGGN8o=
X-Received: by 10.223.170.193 with SMTP id i1mr24540577wrc.218.1512682796806; 
	Thu, 07 Dec 2017 13:39:56 -0800 (PST)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.28.68.212 with HTTP; Thu, 7 Dec 2017 13:39:56 -0800 (PST)
In-Reply-To: <PS2P216MB0179E4F0C7612263A59A20339D330@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
References: <PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<TUV8ZuUkjBRWx-C9y-MOdLBBzWKRLd9TalfSPE1qN6oEvup6uAeGVUUlabCDDHKvWh1GZXTPgj6eOjPngN4ACLX2vIoXcjICy2s8tZfh7JQ=@protonmail.com>
	<PS2P216MB0179BC1CDE30F00D73DAA10F9D320@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<oVWjxK8fBoFl02giOtDPEQ7kAnp9TIRlAJKT14xJ6-VRRVJhT6-UsYLXqBARKUZi-fgRuKgymoTpHuQB5pluZRauX9dPOniJLAC5F6d0jo4=@protonmail.com>
	<PS2P216MB0179DD143E0558194295ADCC9D330@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<PS2P216MB0179E4F0C7612263A59A20339D330@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 7 Dec 2017 16:39:56 -0500
X-Google-Sender-Auth: S962zdWu_jhICd9Q9wFuChQK6ao
Message-ID: <CAJowKgKkao0dmfwNfxm4tNLsNRQ=TuHk3wTxgs5W1-NX5evfRw@mail.gmail.com>
To: Damian Williamson <willtech@live.com.au>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c1b6438c2f8c9055fc6e891"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 07 Dec 2017 23:12:39 +0000
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight
 For Ordering Transactions In Blocks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Dec 2017 21:40:00 -0000

--94eb2c1b6438c2f8c9055fc6e891
Content-Type: text/plain; charset="UTF-8"

You can feel free to write this version and try to get miners to use it.
 That's the nice thing about Bitcoin.

On Thu, Dec 7, 2017 at 3:49 PM, Damian Williamson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning ZmnSCPxj,
>
>
> Actually, there is no incentive to cheat target block size by providing a
> next block size that is higher or lower than the proposal would give. Under
> the proposal the transaction pool can grow quite large. A low next block
> size just defers collecting transaction fees, while a high next block size
> shrinks the transaction pool and thereby lowers fees. It seems like a
> standoff. This is especially true if the curve for time waiting in the
> transaction pool is extended beyond n days, since it is a curve, after
> waiting longer than 60 days (if n = 60 days) a transaction would have a
> priority greater than one-hundred and would therfore be the first
> transaction included with no possibility of failing the likelihood, so,
> even low fee paying transactions would be included first if the pool size
> is growing through incorrectly providing the next block size.
>
>
> As it is now, I presume, a miner could include exactly one transaction in
> a block and pad?
>
>
> Regards,
>
> Damian Williamson
> ------------------------------
> *From:* Damian Williamson <willtech@live.com.au>
> *Sent:* Thursday, 7 December 2017 7:13:14 PM
> *To:* ZmnSCPxj
>
> *Cc:* bitcoin-dev@lists.linuxfoundation.org
> *Subject:* Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction
> Weight For Ordering Transactions In Blocks
>
>
> Good morning ZmnSCPxj, it must be where you are,
>
>
> I suppose that we are each missing each other's point some.
>
>
> I understand that nodes would not be expected to agree on the transaction
> pool and do not propose validating that the correct transactions are
> included in a block. I speak of probability and likelihood of a transaction
> being included in a block, implying a random element. I do not propose
> rejecting blocks on the basis that the next block size is stated too large
> or too small for the transaction pool, only that the block received
> conforms to the next block size given on the previous block. Yes, it could
> be cheated. Also, various nodes may have at times wildly different amounts
> of transactions waiting in the transaction pool compared to each other and
> there could be a great disparity between them. It would not be possible in
> any case I can think of to validate the next block size is correct for the
> current transaction pool. Even as it is now, nodes may include transactions
> in a block that no other nodes have even heard of, nodes have no way to
> validate that either. If the block is built on sufficiently, it is the
> blockchain.
>
>
> I will post back the revised proposal to the list. I have fleshed parts of
> it out more, given more explanation and, tried this time not to recycle
> terminology.
>
>
> Regards,
>
> Damian Williamson
> ------------------------------
> *From:* ZmnSCPxj <ZmnSCPxj@protonmail.com>
> *Sent:* Thursday, 7 December 2017 5:46:08 PM
> *To:* Damian Williamson
> *Cc:* bitcoin-dev@lists.linuxfoundation.org
> *Subject:* Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction
> Weight For Ordering Transactions In Blocks
>
> Good morning Damian,
>
> >As I understand it, each node would be aware independently of x
> transactions waiting for confirmation, the transaction pool.
>
> Each long-running node would have a view that is roughly the same as the
> view of every other long-running node.
>
> However, suppose a node, Sleeping Beauty, was temporarily stopped for a
> day (for various reasons) then is started again.  That node cannot verify
> what the "consensus" transaction pool was during the time it was stopped --
> it has no view of that.  It can only trust that the longest chain is valid
> -- but that means it is SPV for this particular rule.
>
> >If next blocksize is broadcast with the completed block it would be a
> simple matter to back confirm that.
>
> It would not. Suppose Sleeping Beauty slept at block height 500,000.  On
> awakening, some node provides some purported block at height 500,001.  This
> block indicates some "next blocksize" for the block at height 500,002.  How
> does Sleeping Beauty know that the transaction pool at block 500,001 was of
> the correct size to provide the given "next blocksize"?  The only way,
> would be to look if there is some other chain with greater height that
> includes or does not include that block: that is, SPV confirmation.
>
> How does Sleeping Beauty know it has caught up, and that its transaction
> pool is similar to that of its neighbors (who might be lying to it, for
> that matter), and that it should therefore stop using SPV confirmation and
> switch to strict fullnode rejection of blocks that indicate a "next
> blocksize" that is too large or too small according to your equation?  OR
> will it simply follow the longest chain always, in which case, it trusts
> miners to be honest about how loaded (or unloaded) the transaction pool is?
>
> -------
>
> As a general rule, consensus rules should restrict themselves to:
>
> 1.  The characteristics of the block.
> 2.  The characteristics of the transactions within the block.
>
> The transaction pool is specifically those transaction that are NOT in any
> block, and thus, are not safe to depend on for any consensus rules.
>
> Regards,
> ZmnSCPxj
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c1b6438c2f8c9055fc6e891
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You can feel free to write this version and try to get min=
ers to use it.=C2=A0 =C2=A0That&#39;s the nice thing about Bitcoin.</div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Dec 7, 2017=
 at 3:49 PM, Damian Williamson via bitcoin-dev <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">




<div dir=3D"ltr">
<div id=3D"m_594504094707906846divtagdefaultwrapper" style=3D"font-size:12p=
t;color:#000000;font-family:Calibri,Helvetica,sans-serif" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0"><span>Good morning ZmnSCPxj,</spa=
n></p>
<p style=3D"margin-top:0;margin-bottom:0"><span><br>
</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span>Actually, there is no incen=
tive to cheat target block size by providing a next block size that is high=
er or lower than the proposal would give. Under the proposal the transactio=
n pool can grow quite large. A low
 next block size just defers collecting transaction fees, while a high next=
 block size shrinks the transaction pool and thereby lowers fees. It seems =
like a standoff. This is especially true if the curve for time waiting in t=
he transaction pool is extended
 beyond n days, since it is a curve, after waiting longer than 60 days (if =
n =3D 60 days) a transaction would have a priority greater than one-hundred=
 and would therfore be the first transaction included with no possibility o=
f failing the likelihood, so, even
 low fee paying transactions would be included first if the pool size is gr=
owing through incorrectly providing the next block size.</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span><br>
</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span>As it is now, I presume, a =
miner could include exactly one transaction in a block and pad?</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span><br>
</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span>Regards,</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span>Damian Williamson</span><br=
>
</p>
</div>
<hr style=3D"display:inline-block;width:98%">
<div id=3D"m_594504094707906846divRplyFwdMsg" dir=3D"ltr"><font face=3D"Cal=
ibri, sans-serif" style=3D"font-size:11pt" color=3D"#000000"><b>From:</b> D=
amian Williamson &lt;<a href=3D"mailto:willtech@live.com.au" target=3D"_bla=
nk">willtech@live.com.au</a>&gt;<br>
<b>Sent:</b> Thursday, 7 December 2017 7:13:14 PM<br>
<b>To:</b> ZmnSCPxj<div><div class=3D"h5"><br>
<b>Cc:</b> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<b>Subject:</b> Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction =
Weight For Ordering Transactions In Blocks</div></div></font>
<div>=C2=A0</div>
</div><div><div class=3D"h5">

<div dir=3D"ltr">
<div id=3D"m_594504094707906846x_divtagdefaultwrapper" dir=3D"ltr" style=3D=
"font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif">
<p style=3D"margin-top:0;margin-bottom:0"></p>
<p style=3D"margin-top:0;margin-bottom:0">Good morning ZmnSCPxj, it must be=
 where you are,</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">I suppose that we are each missin=
g each other&#39;s point some.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">I understand that nodes would not=
 be expected to agree on the transaction pool and do not propose validating=
 that the correct transactions are included in a block. I speak of probabil=
ity and likelihood of a transaction
 being included in a block, implying a random element. I do not propose rej=
ecting blocks on the basis that the next block size is stated too large or =
too small for the transaction pool, only that the block received conforms t=
o the next block size given on the
 previous block. Yes, it could be cheated. Also, various nodes may have at =
times wildly different amounts of transactions waiting in the transaction p=
ool compared to each other and there could be a great disparity between the=
m. It would not be possible in any
 case I can think of to validate the next block size is correct for the cur=
rent transaction pool. Even as it is now, nodes may include transactions in=
 a block that no other nodes have even heard of, nodes have no way to valid=
ate that either. If the block is
 built on sufficiently, it is the blockchain.<br>
</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">I will post back the revised prop=
osal to the list. I have fleshed parts of it out more, given more explanati=
on and, tried this time not to recycle terminology.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p></p>
<p style=3D"margin-top:0;margin-bottom:0">Regards,</p>
<p style=3D"margin-top:0;margin-bottom:0">Damian Williamson<br>
</p>
</div>
<hr style=3D"display:inline-block;width:98%">
<div id=3D"m_594504094707906846x_divRplyFwdMsg" dir=3D"ltr"><font face=3D"C=
alibri, sans-serif" color=3D"#000000" style=3D"font-size:11pt"><b>From:</b>=
 ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank">=
ZmnSCPxj@protonmail.com</a>&gt;<br>
<b>Sent:</b> Thursday, 7 December 2017 5:46:08 PM<br>
<b>To:</b> Damian Williamson<br>
<b>Cc:</b> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<b>Subject:</b> Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction =
Weight For Ordering Transactions In Blocks</font>
<div>=C2=A0</div>
</div>
<div>
<div>Good morning Damian,<br>
</div>
<div><br>
</div>
<div>&gt;As I understand it, each node would be aware independently of x tr=
ansactions waiting for confirmation, the transaction pool.<br>
</div>
<div><br>
</div>
<div>Each long-running node would have a view that is roughly the same as t=
he view of every other long-running node.<br>
</div>
<div><br>
</div>
<div>However, suppose a node, Sleeping Beauty, was temporarily stopped for =
a day (for various reasons) then is started again.=C2=A0 That node cannot v=
erify what the &quot;consensus&quot; transaction pool was during the time i=
t was stopped -- it has no view of that.=C2=A0 It can
 only trust that the longest chain is valid -- but that means it is SPV for=
 this particular rule.<br>
</div>
<div><br>
</div>
<div>&gt;If next blocksize is broadcast with the completed block it would b=
e a simple matter to back confirm that.<br>
</div>
<div><br>
</div>
<div>It would not. Suppose Sleeping Beauty slept at block height 500,000.=
=C2=A0 On awakening, some node provides some purported block at height 500,=
001.=C2=A0 This block indicates some &quot;next blocksize&quot; for the blo=
ck at height 500,002.=C2=A0 How does Sleeping Beauty know that
 the transaction pool at block 500,001 was of the correct size to provide t=
he given &quot;next blocksize&quot;?=C2=A0 The only way, would be to look i=
f there is some other chain with greater height that includes or does not i=
nclude that block: that is, SPV confirmation.<br>
</div>
<div><br>
</div>
<div>How does Sleeping Beauty know it has caught up, and that its transacti=
on pool is similar to that of its neighbors (who might be lying to it, for =
that matter), and that it should therefore stop using SPV confirmation and =
switch to strict fullnode rejection
 of blocks that indicate a &quot;next blocksize&quot; that is too large or =
too small according to your equation?=C2=A0 OR will it simply follow the lo=
ngest chain always, in which case, it trusts miners to be honest about how =
loaded (or unloaded) the transaction pool is?<br>
</div>
<div><br>
</div>
<div>-------<br>
</div>
<div><br>
</div>
<div>As a general rule, consensus rules should restrict themselves to:<br>
</div>
<div><br>
</div>
<div>1.=C2=A0 The characteristics of the block.<br>
</div>
<div>2.=C2=A0 The characteristics of the transactions within the block.<br>
</div>
<div><br>
</div>
<div>The transaction pool is specifically those transaction that are NOT in=
 any block, and thus, are not safe to depend on for any consensus rules.<br=
>
</div>
<div><br>
</div>
<div>Regards,<br>
</div>
<div>ZmnSCPxj<br>
</div>
<div><br>
</div>
</div>
</div>
</div></div></div>

<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--94eb2c1b6438c2f8c9055fc6e891--