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 9B5B498C for ; Wed, 27 Dec 2017 12:29:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254032.outbound.protection.outlook.com [40.92.254.32]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5DF4E411 for ; Wed, 27 Dec 2017 12:29: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=TYuGjalYdfjSYgEi6ZdvUqSb2EiXU20aqTIVHiwe5Uo=; b=nK9ETXABTyghoCo8CNZbqJfUA/eHLJ8Z5QEgBRTmiqMHGqr5Ra1sOQp1a98Mo1bHzwFtmQoyeSPlDIudv0tNeyOwoYI7cB7fzQBlit/MGTxYzdc1n8w+Xjxw6MESwwHZyrzv2YplNnkA/jc/d/xB4j2n8l0/EwSkqQPh1I5UN/3NpYIluu5YL2PhrsTeSNgNdxYRuW6y+dkgkOHKtgemCqccN8sxGu/1r6RufSW4fWCDh7JqnYzaqYGuVlUoZW8t+rdo8SeE4wba4+vidSDxI0bzqUBHYLt2OwZjDdlOvQizSCThQ85Cjci3XpjJWYvv4UsVq3JIow59FSfEiQDrMg== Received: from HK2APC01FT032.eop-APC01.prod.protection.outlook.com (10.152.248.55) by HK2APC01HT217.eop-APC01.prod.protection.outlook.com (10.152.249.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.302.6; Wed, 27 Dec 2017 12:29:42 +0000 Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.248.51) by HK2APC01FT032.mail.protection.outlook.com (10.152.248.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.302.6 via Frontend Transport; Wed, 27 Dec 2017 12:29:41 +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.0345.017; Wed, 27 Dec 2017 12:29:41 +0000 From: Damian Williamson To: ZmnSCPxj Thread-Topic: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks Thread-Index: AQHTfghff7TDaA+xpUy7nXNeJMBNLKNWkRGAgACMCXc= Date: Wed, 27 Dec 2017 12:29:41 +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:72F92507A4DA71665496ED823AC2551F3E2AE422AF026C695DFC7645F5EBF7F0; UpperCasedChecksum:1F3843C345CA56F60822C57B441EC093ACC6EAEBB1A261E7571E94A39B921550; SizeAsReceived:7444; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [ybGpK/HtJNk2ob3T+TnQcO8r5ZlrFoGa] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK2APC01HT217; 6:Pn89zOr2QW3HnhJquyF4Fcm0pWQ9OQprRai6zmwYjfb+J8FFy13qWkCvGHuqnT+QaFpPmCu+rg8ZQDFAwns1xaw/YRBVAon6EA5wVfEw7/waHTaASub4G3hgoxeZrikMQdi2Z/uOKj4lGe03cMKL9HqHuUwr9Y1BDBIcyU/rV9EvZFnA5hIbhx/+Yn7JR4x6iTyPNnQNnYjLNprJuirSWeKOrdClSX2TuqvkLWwHgPgYPNxkSWiM594LLbKv+gs8pmev878u7kP0bgx1cnUKMr5ltizllSJaGeX1q0YHh0h1bvv3mZGW6WwypG1ft8YRHGsZHprMd4YbrmsN+WoMEHtjyCtny47G+T7tcg6UeZc=; 5:VLvFUql8700RfrDXCIMIwN6+P4mLtw8hLalqW/x3htnesPdwSZeJ3W6KEdCYhtjM+zpTsqFGBAp2Vlt4EizFkNPLj4m/ymWZR92gselLcyJHoxLY8jYbw9EPbBEgjYrnrEjyx7FVa76OErTlVfHFplGw9sGxRziD5g0iRqG92Yc=; 24:sKN3bOZWsuoUwDD/1m+O4cbVwarm3L0Hy/R+OWoN86eI9uIJeYjizYLmu2PEURvrcXksbQigkq+iQ78HQCO6vstXiYm+B7h5fNhIDo2FWgQ=; 7:U+D7IpkWWnZMqVoUSMwrGZGJJfgujmMO9yxe02uNWUFo3S0mjFKv91MR4lEqgobX8UMa+dno/49KoX0swx7FyWcrnBMFbp1qMKWeUABL8m6U509iShIKa4Ka+Jm/KUmvwzToaz7TfawhR4Ot+EWd0x3KWpyMfdreymhN1EGcbdVUc45iP/gtfy1k9TFSJqRUNPRFJYf/cF0XpX0nSLcdz18jpuH9MkRxK2ZG8oldjv+uIoqP7T7FtsBUzBwRxH/T 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:HK2APC01HT217; x-ms-traffictypediagnostic: HK2APC01HT217: x-ms-office365-filtering-correlation-id: 70a3bf36-0a13-461b-4773-08d54d2580de x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HK2APC01HT217; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HK2APC01HT217; x-forefront-prvs: 0534947130 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT217; H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_PS2P216MB0179B1A36650D63AA04566029D070PS2P216MB0179KORP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70a3bf36-0a13-461b-4773-08d54d2580de X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2017 12:29:41.1160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT217 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: Fri, 29 Dec 2017 01:31:20 +0000 Cc: "bitcoin-dev@lists.linuxfoundation.org" Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority 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: Wed, 27 Dec 2017 12:29:46 -0000 --_000_PS2P216MB0179B1A36650D63AA04566029D070PS2P216MB0179KORP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good evening ZmnSCPxj, That you for your considered discussion. Am I wrong to think that any fullnode can validate blocks conform to a prob= ability distribution? In my understanding after adoption of the proposal, a= ny full node could validate all properties that a block has that they now v= alidate, apart from block size, and additionally that the block conforms to= a probability distribution. It seems a yes-no result. Let us assume that s= uch a probability distribution exists since the input is a probability. Before or after the proposal, miners could falsify transactions if there is= a feasible way for them to do this. The introduction of the proposal does = not change that fact. At the moment the incentive to falsify transactions i= s to fill blocks so that real transactions must pay the highest possible fe= es in the auction for limited transaction bandwidth resulting in a net gain= for miners. Simply making bigger blocks serves no economic purpose in itse= lf, since the miners we presume must pay the fees for their falsified trans= actions, there is no net gain, the fee will be distributed through the pool= . Unless, by miners, I may presume we mostly mean mining pools and collusio= n. Still, where is the gain? It is only the blocks that will be larger with= no economic advantage. In a fee for priority service auction, there is always limited space in eac= h new block since it represents only a small fraction of the size of the me= mpool. Presenting fraudulent transactions at the bottom end of the scale ha= s limited effect on the cost of being near the front of the queue, at prior= ity. As the fraudulent transactions age they would be included in blocks pr= esuming the fee is above dust level, but the block size would grow to accom= modate them since the valid mempool is larger. The auction for priority sti= ll continues uninterrupted at the top of the priority curve. There is nothi= ng stopping a motivated individual now from writing a script to create a mi= llion pointless dust transactions per day, flooding the mempool. Even if th= e fee is above dust level the proposal does not change this but, ensures tr= ansactional reliability for valid transactions. In an idealist world, all nodes could agree on the state of the mempool. I = agree, there is no feasible way currently to hold the mempool to consensus = without a network of dedicated mempool servers. As it is, it has been sugge= sted that all long-running nodes will have approximately a similar view of = the mempool. Sweeping the entire mempool contents per block would achieve w= hat is required if there was a mempool consensus but since it will just be = one node's view of the mempool that will not be the result. My speculation is that as a result of the proposal, through increased adopt= ion of Bitcoin over time there would, in fact, be more transactions and gre= ater net fees paid per day. An increased value of BTC that we suppose would= follow from increased usage would augment this fee value increase. It sure= ly follows that a more stable and reliable service will have greater consum= er and business acceptance, and there it follows that this is in miners fin= ancial interest. I have not considered a maxblocksize since I consider that the mempool can = eventually grow infinitely in size just in valid transactions, without even= any fraudulent transactions. I suppose that in time it will become necessa= ry to start all new nodes in pruned mode by default due to the onerous stor= age requirements of the full blockchain. I do not think that the proposed c= hanges alter this. I am sure that there is much more to write. Regards, Damian Williamson ________________________________ From: ZmnSCPxj Sent: Wednesday, 27 December 2017 2:55 PM To: Damian Williamson Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transactio= n Priority For Ordering Transactions In Blocks Good morning Damian, I see you have modified your proposal to be purely driven by miners, with f= ullnodes not actually being able to create a strict "yes-or-no" answer as t= o block validity under your rules. This implies that your rules cannot be = enforced and that rational miners will ignore your proposal unless it bring= s in more money for them. The fact that your proposal provides some mechan= ism to increase block size means that miners will be incentivized to falsif= y data (by making up their own transactions just above your fixed "dust siz= e" threshhold whatever that threshhold may be -- and remember, miners get a= t least 12.5 BTC per block, so they can make a lot of little falsified tran= sactions to justify every block size increase) until the block size increas= e per block is the maximum possible block size increase. -- Let me then explain proof-of-work and the arrow of time in Physics. It may= seem a digression, but please, bear with me. Proof-of-work proves that work was performed, and (crucially) that this wor= k was done in the past. This is important because of the arrow of time. In principle, every physical interaction is reversible. Visualize a video = of two indivisible particles. The two particles move towards each other, c= ollide, and because of the collision, fly apart. If you ran this video in r= everse, or in forward, it would not be distinguishable to you, as an outsid= e observer, whether the video was running in reverse or not. It seems at s= ome level, time does not exist. And yet time exists. Consider another video, that of a vase being dropped on a hard surface. Th= e vase hits the surface and shatters. Played in reverse, we can judge it a= s nonsensical: scattered pieces of ceramic spontaneously forming a vase and= then flying upwards. This orients our arrow of time: the arrow of time po= ints from states of the universe where lesser entropy exists (the vase is w= hole) to where greater entropy exists (the vase is in many pieces). Indeed, all measures of time are, directly or indirectly, measures of incre= ases in entropy. Consider a simple hourglass: you place it into a state of= low entropy and high energy with most of the sand is in the upper part of = the hourglass. As sand falls, and more of that energy is lost into entropy= , you judge that time passes. Consider a proof-of-work algorithm: you place electrons into a state of low= entropy and high energy. As electrons go through the mining hardware, pro= ducing hashes that pass the difficulty requirement, the energy in those ele= ctrons is lost into entropy (heat), and from the hashes produced (which pro= ves not only that work was done, but in particular, that entropy increased = due to work being done), you judge that time passes. -- Thus, the blockchain itself is already a service that provides a measure of= time. When a block commits to a transaction, then that transaction is kno= wn to have existed at that block height, at the latest. Thus one idea, is to have each block commit to some view of the mempool. I= f a transaction exists in this mempool-view, then you know that the transac= tion is at least that old, and can judge the age from this and use this to = compute the "transaction priority". Unfortunately, transferring the data to prove that the mempool-view is vali= d, is equivalent to always sweeping the entire mempool contents per block. = In that case you might as well not have a block size limit. In addition, miners may still commit to a falsely-empty mempool and deny th= at your transaction is old and therefore priority and therefore will simply= fill their blocks with transactions that have high feerates rather than hi= gh priority. Thus feerate will still be the ultimate measure. Rather than attempt this, perhaps developers should be encouraged to make u= se of existing mechanisms, RBF and CPFP, to allow transactions to be sped u= p by directly manipulating feerates, as priority (by your measure) is not p= ractically computable. Regards, ZmnSCPxj --_000_PS2P216MB0179B1A36650D63AA04566029D070PS2P216MB0179KORP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Good evening ZmnSCPxj,


That you for your considered disc= ussion.


Am I wrong to think that any fullnode can validate blocks conform to a= probability distribution? In my understanding after adoption of the propos= al, any full node could validate all properties that a block has that they = now validate, apart from block size, and additionally that the block conforms to a probability distribution. It= seems a yes-no result. Let us assume that such a probability distribution = exists since the input is a probability.

Before or after the proposal, miners could falsify transactions if there is= a feasible way for them to do this. The introduction of the proposal does = not change that fact. At the moment the incentive to falsify transactions i= s to fill blocks so that real transactions must pay the highest possible fees in the auction for limited transaction = bandwidth resulting in a net gain for miners. Simply making bigger blocks s= erves no economic purpose in itself, since the miners we presume must pay t= he fees for their falsified transactions, there is no net gain, the fee will be distributed through the pool. Unless= , by miners, I may presume we mostly mean mining pools and collusion. Still= , where is the gain? It is only the blocks that will be larger with no econ= omic advantage.

In a fee for priority service auction, there is always limited space in eac= h new block since it represents only a small fraction of the size of the me= mpool. Presenting fraudulent transactions at the bottom end of the scale ha= s limited effect on the cost of being near the front of the queue, at priority. As the fraudulent transact= ions age they would be included in blocks presuming the fee is above dust l= evel, but the block size would grow to accommodate them since the valid mem= pool is larger. The auction for priority still continues uninterrupted at the top of the priority curve. T= here is nothing stopping a motivated individual now from writing a script t= o create a million pointless dust transactions per day, flooding the mempoo= l. Even if the fee is above dust level the proposal does not change this but, ensures transactional reliabi= lity for valid transactions.

In an idealist world, all nodes could agree on the state of the mempool. I = agree, there is no feasible way currently to hold the mempool to consensus = without a network of dedicated mempool servers. As it is, it has been sugge= sted that all long-running nodes will have approximately a similar view of the mempool. Sweeping the entire= mempool contents per block would achieve what is required if there was a m= empool consensus but since it will just be one node's view of the mempool t= hat will not be the result.

My speculation is that as a result of the proposal, through increased adopt= ion of Bitcoin over time there would, in fact, be more transactions and gre= ater net fees paid per day. An increased value of BTC that we suppose would= follow from increased usage would augment this fee value increase. It surely follows that a more stable and = reliable service will have greater consumer and business acceptance, and th= ere it follows that this is in miners financial interest.

I have not considered a maxblocksize since I consider that the mempool can = eventually grow infinitely in size just in valid transactions, without even= any fraudulent transactions. I suppose that in time it will become necessa= ry to start all new nodes in pruned mode by default due to the onerous storage requirements of the full blockc= hain. I do not think that the proposed changes alter this.

I am sure that there is much more to write.

Regards,
Damian Williamson



From: ZmnSCPxj <ZmnSCP= xj@protonmail.com>
Sent: Wednesday, 27 December 2017 2:55 PM
To: Damian Williamson
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Tra= nsaction Priority For Ordering Transactions In Blocks
 
Good morning Damian,

I see you have modified your proposal to be purely driven by miners, w= ith fullnodes not actually being able to create a strict "yes-or-no&qu= ot; answer as to block validity under your rules.  This implies that y= our rules cannot be enforced and that rational miners will ignore your proposal unless it brings in more money for them.&= nbsp; The fact that your proposal provides some mechanism to increase block= size means that miners will be incentivized to falsify data (by making up = their own transactions just above your fixed "dust size" threshhold whatever that threshhold may be -- = and remember, miners get at least 12.5 BTC per block, so they can make a lo= t of little falsified transactions to justify every block size increase) un= til the block size increase per block is the maximum possible block size increase.



--

Let me then explain proof-of-work and the arrow of time in Physics.&nb= sp; It may seem a digression, but please, bear with me.

Proof-of-work proves that work was performed, and (crucially) that thi= s work was done in the past.

This is important because of the arrow of time.

In principle, every physical interaction is reversible.  Visualiz= e a video of two indivisible particles.  The two particles move toward= s each other, collide, and because of the collision, fly apart. If you ran = this video in reverse, or in forward, it would not be distinguishable to you, as an outside observer, whether the video w= as running in reverse or not.  It seems at some level, time does not e= xist.

And yet time exists.

Consider another video, that of a vase being dropped on a hard surface= .  The vase hits the surface and shatters.  Played in reverse, we= can judge it as nonsensical: scattered pieces of ceramic spontaneously for= ming a vase and then flying upwards.  This orients our arrow of time: the arrow of time points from states of the uni= verse where lesser entropy exists (the vase is whole) to where greater entr= opy exists (the vase is in many pieces).

Indeed, all measures of time are, directly or indirectly, measures of = increases in entropy.  Consider a simple hourglass: you place it into = a state of low entropy and high energy with most of the sand is in the uppe= r part of the hourglass.  As sand falls, and more of that energy is lost into entropy, you judge that time passes.<= br>

Consider a proof-of-work algorithm: you place electrons into a state o= f low entropy and high energy.  As electrons go through the mining har= dware, producing hashes that pass the difficulty requirement, the energy in= those electrons is lost into entropy (heat), and from the hashes produced (which proves not only that work was = done, but in particular, that entropy increased due to work being done), yo= u judge that time passes.

--

Thus, the blockchain itself is already a service that provides a measu= re of time.  When a block commits to a transaction, then that transact= ion is known to have existed at that block height, at the latest.

Thus one idea, is to have each block commit to some view of the mempoo= l.  If a transaction exists in this mempool-view, then you know that t= he transaction is at least that old, and can judge the age from this and us= e this to compute the "transaction priority".

Unfortunately, transferring the data to prove that the mempool-view is= valid, is equivalent to always sweeping the entire mempool contents per bl= ock.  In that case you might as well not have a block size limit.

In addition, miners may still commit to a falsely-empty mempool and de= ny that your transaction is old and therefore priority and therefore will s= imply fill their blocks with transactions that have high feerates rather th= an high priority.  Thus feerate will still be the ultimate measure.

Rather than attempt this, perhaps developers should be encouraged to m= ake use of existing mechanisms, RBF and CPFP, to allow transactions to be s= ped up by directly manipulating feerates, as priority (by your measure) is = not practically computable.

Regards,
ZmnSCPxj
--_000_PS2P216MB0179B1A36650D63AA04566029D070PS2P216MB0179KORP_--