From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 16CCC892 for ; Thu, 7 Dec 2017 08:13:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255084.outbound.protection.outlook.com [40.92.255.84]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 71E5D79 for ; Thu, 7 Dec 2017 08:13:17 +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=K6rIiGbs5/TrXLgl7ObHk1akcQHGbAN0vNsDF5I0Uq0=; b=L4LG4vIYhjWrJJZlVls9biFz837SALl+Tzc9m/67pDWDsHSa/bAxe34OIszD2KLkW8OFA4Ad1H3O2RfpKap/p1qslS8Z1hEpX7XnP/z1d19X/sGvJ0EqLrblT8oOgvEcXmtjtRCduMjPv7twuixOdG4lMfvSeNJ18TMjlr9uVf0Qo2pV8y97QuwXGAa0WK7ATIEHyf2e7CYFazKkQvFQEfwdi9Q1vpaRkcX7HI1qkEMlqnC8XqPjJVAtLfvnNYDVhU65Ukn7nXH95KT/be+TKpY2oSFWtWMZqus1c5VCWSfzXM/aGfbKRSmB6qv+XCIL/krsmcnV3IhRjO6W/mZYbQ== Received: from PU1APC01FT015.eop-APC01.prod.protection.outlook.com (10.152.252.54) by PU1APC01HT177.eop-APC01.prod.protection.outlook.com (10.152.253.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Thu, 7 Dec 2017 08:13:15 +0000 Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.57) by PU1APC01FT015.mail.protection.outlook.com (10.152.252.227) 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 08:13:15 +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 08:13:15 +0000 From: Damian Williamson To: ZmnSCPxj Thread-Topic: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks Thread-Index: AQHTa+TfjIfbrac6DkW4WL8VVZ5YaaM102mAgAA9mEaAAWVUAIAAFHP0 Date: Thu, 7 Dec 2017 08:13:14 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:EE340025652C1522AFED52182E871BB62A9733517887786402E9C604D17B4BB0; UpperCasedChecksum:02F276195DCFFB54FD7FA9F413FBE7D42B8851ADC374FEF2D04773B061201E9E; SizeAsReceived:7612; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [ZcUw2IgsezeYkad86EUpz5spG1mO5mAf] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT177; 6:pgl9pXaqbWgLDX/07hdyWVocz+FVdVUnsE1P7HWAg4H7FzNFlT2XwFV855+h77YGgeLn4OVdijsHHlVLx9ZF6TbVNUYAsgf42vJ5Qc3egZsgMSKWvaCkbuTv9KV6j4wuMEjdvQg5C5b6WUxIt5Bf28jtQrsMyjJME4DQa2fpaz9Dor/nl+uE9Es7NiLPtKfBXyJZQfYpIu1v5TiBdeaIr1Nl40dLR2Ab+0yWI7ehiSXEeZa13mjpcCsTqRDdZfuNnpVvyu6ppPCP3pKYJm9iXuguP4oFmjQWKC7oaoI8g+5jYt4jERTW0AmGiIT4QvUozLF6Mvi3aJa8rsLwmCEPP4rgGRWDkEqX1LhuYoypA1U=; 5:dMjewmddtAyOR+cx+U46gVpxlZITyThGSW+bgApan5/jjrMMbw2jB+zRDRZysanPCKyXdupL0GGTsho88LQgkUECAzxjiV3uiaqpKwdq5wkNywtAcm05F5FEZcOyJxuQ6K4ZBlX/ET5U89WYdq/3MGhiInFQOeHqweuFEJr4Tmc=; 24:1tv2xxmWicZ6r7DdsYva2tZjahKJaPE7WZz1Axj1bMToCrnIaKDFmmFTisC8ycMqeyz4LJBctWE1IpI7p0aUqQ4VB6amZpyHbnU262t0EQY=; 7:pwNeRUUdkPSWVQ5Zo/IysWh2TNbtwL6ouKTMI3qgMeQXiNNgxuatSPV3z0LVBg1o3ehW9uOWKHmEBdPCl6Sma7HI+okBifUOIAUocyNI37UyQxSXYRu/R7WAAciA9mTyL2DU9tl0uJn5A+tL8BtzS46THHm/kSwZSSTsti7iJqN0qd1jvHUbXwyd+E2J2C+6i9k2ABIMmgG8eJknSG4nCS0HGVla3lvv+PruOo6kSH/nrcECk89rWpGxVff7+JSG 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:PU1APC01HT177; x-ms-traffictypediagnostic: PU1APC01HT177: x-ms-office365-filtering-correlation-id: 39b3b5c7-65f9-4ba6-63a6-08d53d4a5d9b x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT177; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:PU1APC01HT177; x-forefront-prvs: 05143A8241 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT177; H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_PS2P216MB0179DD143E0558194295ADCC9D330PS2P216MB0179KORP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 39b3b5c7-65f9-4ba6-63a6-08d53d4a5d9b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2017 08:13:14.9507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT177 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 13:49:33 +0000 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 08:13:19 -0000 --_000_PS2P216MB0179DD143E0558194295ADCC9D330PS2P216MB0179KORP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 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_PS2P216MB0179DD143E0558194295ADCC9D330PS2P216MB0179KORP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good morning ZmnSCPxj, it must be= where you are,


I suppose that we are each missin= g 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 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.


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.


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

Each long-running node would have a view that is roughly the same as t= he 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 v= erify what the "consensus" transaction pool was during the time i= t 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 b= e a simple matter to back confirm that.

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.  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 t= he given "next blocksize"?  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.

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 "next blocksize" that is too large or = too small according to your equation?  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?

-------

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_PS2P216MB0179DD143E0558194295ADCC9D330PS2P216MB0179KORP_--