Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 05973BC8 for ; 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 ; Thu, 7 Dec 2017 21:39:58 +0000 (UTC) Received: by mail-wr0-f181.google.com with SMTP id x49so8927923wrb.13 for ; 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: References: From: Erik Aronesty Date: Thu, 7 Dec 2017 16:39:56 -0500 X-Google-Sender-Auth: S962zdWu_jhICd9Q9wFuChQK6ao Message-ID: To: Damian Williamson , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > *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 > *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
You can feel free to write this version and try to get min= ers to use it.=C2=A0 =C2=A0That's the nice thing about Bitcoin.

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

Good morning ZmnSCPxj,


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.


As it is now, I presume, a = miner could include exactly one transaction in a block and pad?


Regards,

Damian Williamson

From: D= amian 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
=C2=A0

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
=C2=A0
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.=C2=A0 That node cannot v= erify what the "consensus" 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.

>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.= =C2=A0 On awakening, some node provides some purported block at height 500,= 001.=C2=A0 This block indicates some "next blocksize" 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 "next blocksize"?=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.

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?=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?

-------

As a general rule, consensus rules should restrict themselves to:

1.=C2=A0 The characteristics of the block.
2.=C2=A0 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--