path: root/c8/7be39e580efc119bdf77421296de0510435475

Return-Path: <willtech@live.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F0CBDC88
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  7 Dec 2017 20:49:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-SG2-obe.outbound.protection.outlook.com
	(mail-oln040092253070.outbound.protection.outlook.com [40.92.253.70])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EAC1479
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  7 Dec 2017 20:49:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; 
	h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
	bh=4JnXJv3bY8ZOJx85YWaywPWVeDkGR+3+j5onfHMgrAk=;
	b=P63lM+STczwCRddRcufOQ6v/LBu/Rm5xegNZUa5tkbVwkr8E6JdXi1v0JMjtS3jeI90FKgc7vVJFcXCGiuBIIBGH58Vz3cw00iMEdSsrAN4/bgeE769YQXhnlTfSFUeh0gOqAzCCw/G2YWQrCI9Bo38yCNFb8HAAszK38ey/XRRMPXgiQJabIq66h2Lt1D6KOEnL/H0iLCJvcod8kxnWfc7gWHL9vHQM1mU0BpzXwWKVwmJf2dCxgAEbxHQyc+VbEp48ncEfJrXBo+CpGxm5C6kpYq2WiBhx1a3hU7prJ5YaR3C814umwbuUDkiQ7ILMJ1NSR/adJkrL3eMhSO9P6Q==
Received: from SG2APC01FT010.eop-APC01.prod.protection.outlook.com
	(10.152.250.57) by SG2APC01HT159.eop-APC01.prod.protection.outlook.com
	(10.152.251.23) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.282.5;
	Thu, 7 Dec 2017 20:49:42 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.250.51) by
	SG2APC01FT010.mail.protection.outlook.com (10.152.250.134) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.282.5 via
	Frontend Transport; Thu, 7 Dec 2017 20:49:42 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) by
	PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) with mapi id
	15.20.0282.007; Thu, 7 Dec 2017 20:49:42 +0000
From: Damian Williamson <willtech@live.com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Thread-Topic: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight
	For Ordering Transactions In Blocks
Thread-Index: AQHTa+TfjIfbrac6DkW4WL8VVZ5YaaM102mAgAA9mEaAAWVUAIAAFHP0gADWnTw=
Date: Thu, 7 Dec 2017 20:49:41 +0000
Message-ID: <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>
In-Reply-To: <PS2P216MB0179DD143E0558194295ADCC9D330@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:D2B2CDA19658FA06A23EFE530561AA590E3F24DED3C5AFEA7C627F6E7111EF1E;
	UpperCasedChecksum:FD8C41270C307C18258179EE7E81D2CAE2934AE12B1E0C580D5DEE7DF613EAC6;
	SizeAsReceived:7671; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [NiE+ucM3/7K4Y/QVgj7bcD3pctCwhX3w]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SG2APC01HT159;
	6:QKMnS4fBap3/+6ICVkn6MBvueLvO6lx0JDUM5zt5Rr8ZjD7kvph8X0ZPWeCmNV7p8RfHh8CzPrcYI5op0D9cCjQkceq95M0k4ygnw9Q4X9Kj3TWpfQs4/iU5gaMMiNZdbwjH6Ix/ITQQrdKRLYyQtwWI7ojT3dmTU9EwGZdoaDvcNjsb8v9hazj7VeVR6Pk8U12OUmcxXeljiDFauYfhHgKhRZZncSD6F8+meBk/LRsyjofUoTCRiXl4RsE3ukoXyNQz6m8JzKqhqkusLnSfquUA38pYH20TZ273pV3tuE62eQAJUn8ws7bCBkKtZc4B2lUvgBEzUxGlnR9VLpPe1Xh5Djm3CDbSpidAvEGVSVo=;
	5:CN+iug7WIEJO2dOnnjnQbpB/YBJSo4TNmdx5cSJjgIZ+b4p8s4wVWpcZNnhe0niScgDtckEWB5hSFxh8u02f6JzTd/cDfZ7K5+j9COBtP7wJSrlwwMdpcgk7z5VuCMSGoI614gqiLftkoE2o09u+nXebAIKUC10Yk2nQ6Yk60eM=;
	24:HTqlWeX7M2JzMc0p42wlSrHan+8u5Jv5BgIUXT60DMTEq7yu+Z4Bs7g2aanWF7rVnyl0UaqBPh8mM/7IzuFfIaiqsO/IkblvKyhGO56VNRM=;
	7:MymVYieHbrf4WusbjmzUbVeGQ9g8Q1nnzgaZ3G5OWl0f9EWVD4hOg3Pl1TFCgwx6hwaILpLe+8NNFqATLBfbS4FvxTpnCgXddkUQzF9ECkeKt25pyKNsnlh6/Pq/0uc9XnwzZsoIQKnzEC22DLwbv9G6E7yZcYv150bIcSeZnqi7sLZ2ktqyfTqVoAoXMmikZicge1AV/ltZ2uFPBPnlgYIEHuYHkAnAeBghOLZwH79B/bXtEd091vwF+sQuRQHA
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045);
	SRVR:SG2APC01HT159; 
x-ms-traffictypediagnostic: SG2APC01HT159:
x-ms-office365-filtering-correlation-id: 249525e9-6c91-42ad-3f2e-08d53db40a74
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:SG2APC01HT159; BCL:0; PCL:0;
	RULEID:(100000803101)(100110400095); SRVR:SG2APC01HT159; 
x-forefront-prvs: 05143A8241
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT;
	SFP:1901; SCL:1; SRVR:SG2APC01HT159;
	H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB0179E4F0C7612263A59A20339D330PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 249525e9-6c91-42ad-3f2e-08d53db40a74
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2017 20:49:41.8778 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT159
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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 21:02:44 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
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 20:49:47 -0000

--_000_PS2P216MB0179E4F0C7612263A59A20339D330PS2P216MB0179KORP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Good morning ZmnSCPxj,


Actually, there is no incentive to cheat target block size by providing a n=
ext 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 si=
ze just defers collecting transaction fees, while a high next block size sh=
rinks the transaction pool and thereby lowers fees. It seems like a standof=
f. 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 =3D 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 transact=
ions would be included first if the pool size is growing through incorrectl=
y 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 p=
ool and do not propose validating that the correct transactions are include=
d 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 sma=
ll for the transaction pool, only that the block received conforms to the n=
ext block size given on the previous block. Yes, it could be cheated. Also,=
 various nodes may have at times wildly different amounts of transactions w=
aiting 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 th=
ink of to validate the next block size is correct for the current transacti=
on 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 eithe=
r. 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 ter=
minology.


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 transactio=
ns waiting for confirmation, the transaction pool.

Each long-running node would have a view that is roughly the same as the vi=
ew 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 simp=
le matter to back confirm that.

It would not. Suppose Sleeping Beauty slept at block height 500,000.  On aw=
akening, some node provides some purported block at height 500,001.  This b=
lock 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, wou=
ld be to look if there is some other chain with greater height that include=
s or does not include that block: that is, SPV confirmation.

How does Sleeping Beauty know it has caught up, and that its transaction po=
ol 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 switc=
h to strict fullnode rejection of blocks that indicate a "next blocksize" t=
hat is too large or too small according to your equation?  OR will it simpl=
y follow the longest chain always, in which case, it trusts miners to be ho=
nest 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


--_000_PS2P216MB0179E4F0C7612263A59A20339D330PS2P216MB0179KORP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;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%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Damian Williamson &lt=
;willtech@live.com.au&gt;<br>
<b>Sent:</b> Thursday, 7 December 2017 7:13:14 PM<br>
<b>To:</b> ZmnSCPxj<br>
<b>Cc:</b> bitcoin-dev@lists.linuxfoundation.org<br>
<b>Subject:</b> Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction =
Weight For Ordering Transactions In Blocks</font>
<div>&nbsp;</div>
</div>
<style type=3D"text/css" style=3D"display:none">
<!--
p
	{margin-top:0;
	margin-bottom:0}
-->
</style>
<div dir=3D"ltr">
<div id=3D"x_divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; col=
or:#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 b=
e 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 missi=
ng each other'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 no=
t be expected to agree on the transaction pool and do not propose validatin=
g that the correct transactions are included in a block. I speak of probabi=
lity 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 pro=
posal to the list. I have fleshed parts of it out more, given more explanat=
ion 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 tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"x_divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" =
color=3D"#000000" style=3D"font-size:11pt"><b>From:</b> ZmnSCPxj &lt;ZmnSCP=
xj@protonmail.com&gt;<br>
<b>Sent:</b> Thursday, 7 December 2017 5:46:08 PM<br>
<b>To:</b> Damian Williamson<br>
<b>Cc:</b> bitcoin-dev@lists.linuxfoundation.org<br>
<b>Subject:</b> Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction =
Weight For Ordering Transactions In Blocks</font>
<div>&nbsp;</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.&nbsp; 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.&nbsp; 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.&n=
bsp; On awakening, some node provides some purported block at height 500,00=
1.&nbsp; This block indicates some &quot;next blocksize&quot; for the block=
 at height 500,002.&nbsp; 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;?&nbsp; 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?&nbsp; 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.&nbsp; The characteristics of the block.<br>
</div>
<div>2.&nbsp; 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>
</body>
</html>

--_000_PS2P216MB0179E4F0C7612263A59A20339D330PS2P216MB0179KORP_--