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 DC136130B for ; Wed, 6 Dec 2017 05:18:09 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [69.252.207.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1E74CF4 for ; Wed, 6 Dec 2017 05:18:08 +0000 (UTC) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id MS5necdm7WQ3xMS5weppcL; Wed, 06 Dec 2017 05:18:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1512537488; bh=4ABqbPNdNdk3qrWfPsHkOeasYrUzuNQSbGs4PdyIwVM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kxPrFrqLmHbJKKdfhouoJ8HUQDnbQAZo6sg/CQJUcFX2qMl+siSxPIZOSTXPbXnlj 31+4PD5qzxFPmvoelzxcVeIXAfoeU7JAFd6GsQp1kmOvSuPCeN4iGgE+qSK3Vm9ciM url74wYZE/hFF06/agvBMNj9kAGbftUzZ6K+ZSdABGS/fKX/LHZtmA5Usuog3nUuqu 6kr19VV1kchJzgktcKO4braaxgCAMl3kKwyc05Z40R8A5jWfrJFGpG2tH8F4RwUrdK ZHaDbMFJP7azUeCM2PVSzutf8xOvdNdpUHAvoqShXDCH37XjlgTXx5eVL/CJqOmCDO d0mOvkEddFmsw== Received: from [192.168.1.50] ([67.167.116.239]) by resomta-ch2-17v.sys.comcast.net with SMTP id MS5veN63nRomNMS5vewHwK; Wed, 06 Dec 2017 05:18:08 +0000 To: bitcoin-dev@lists.linuxfoundation.org References: From: Jim Renkel Message-ID: <52700305-585d-4239-134e-ac8c5b6c4165@comcast.net> Date: Tue, 5 Dec 2017 23:18:11 -0600 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C5DAE4AB670F179367B42B7E" Content-Language: en-US X-CMAE-Envelope: MS4wfJAJOoG/0PnNo/ciJURBtL/4S4KSOdQHVsj8ZSxs+TM9nGVS41bsm/gZF6UpVvB18/HodWgr3C4wR5ted/m5mi9V5K908fD2oEDjLivEOSg5+LwgK/u9 KCSsk74jItTK54CNyXMmt8GsHGd4ChSPjJAgiFDfG59bJr0pgmxzFigTAJivemH7qX0kyft7ajDtToTkYajfjd22whPyHcncC+KMmsNIzx/Gs//2Rmc5RDbU X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, T_RP_MATCHES_RCVD 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: Wed, 06 Dec 2017 14:51:30 +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: Wed, 06 Dec 2017 05:18:10 -0000 This is a multi-part message in MIME format. --------------C5DAE4AB670F179367B42B7E Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit As i understand it, the transactions to be included in a block are entirely up to the miner of that block. What prevents a miner from implementing the proposal on their own? If this is adopted as some kind of "policy", what forces a miner to follow it? Jim Renkel On 12/2/2017 10:07 PM, Damian Williamson via bitcoin-dev wrote: > > # BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering > Transactions In Blocks > > > I admit, with my limited experience in the operation of the protocol, > the section entitled 'Solution operation' may not be entirely correct > but you will get the idea. If I have it wrong, please correct it back > to the list. > > ## The problem: > > > Everybody wants value. Miners want to maximize revenue from fees. > Consumers want transaction reliability and, (we presume) low fees. > > > Current transaction bandwidth limit is a limiting factor for both. > > ## Solution summary: > > > Provide each transaction with a transaction weight, being a function > of the fee paid (on a curve), and the time waiting in the transaction > pool (also on a curve) out to n days (n=30 ?); the transaction weight > serving as the likelihood of a transaction being included in the > current block, and then use a target block size. > > > Protocol enforcement to prevent high or low blocksize cheating to be > handled by having the protocol determine the target size for the > current block using; current transaction pool size x ( 1 / (144 x n > days ) ) = transactions to be included in the current block. > > The curves used for the weight of transactions would have to be > appropriate. > > ## Pros: > > > * Maximizes transaction reliability. > * Maximizes possibility for consumer and business uptake. > * Maximizes total fees paid per block without reducing reliability; > because of reliability, confidence and uptake are greater; therefore, > more transactions and more transactions total at priority fees. > * Market determines fee paid for transaction priority. > > * Fee recommendations work all the way out to 30 days or greater. > > * Provides additional block entropy and greater security since there > is less probability of predicting the next block. > > ## Cons: > > > * ? > * Must be first be programmed. > * Anything else? > > ## Solution operation: > > > As I have said, my simplistic view of the operation. If I have this > wrong, please correct it back to the list. > > > 1. The protocol determines the target block size. > > 2. Assign each transaction in the pool a transaction weight based on > fee and time waiting in the transaction pool. > > 3. Begin selecting transactions to include in the current block using > transaction weight as the likelihood of inclusion until target block > size is met. > > 4. Solve block. > > Regards, > > Damian Williamson > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------C5DAE4AB670F179367B42B7E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

As i understand it, the transactions to be included in a block are entirely up to the miner of that block.


What prevents a miner from implementing the proposal on their own?


If this is adopted as some kind of "policy", what forces a miner to follow it?

Jim Renkel
On 12/2/2017 10:07 PM, Damian Williamson via bitcoin-dev wrote:

# BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks


I admit, with my limited experience in the operation of the protocol, the section entitled 'Solution operation' may not be entirely correct but you will get the idea. If I have it wrong, please correct it back to the list.

## The problem:


Everybody wants value. Miners want to maximize revenue from fees. Consumers want transaction reliability and, (we presume) low fees.


Current transaction bandwidth limit is a limiting factor for both.

## Solution summary:


Provide each transaction with a transaction weight, being a function of the fee paid (on a curve), and the time waiting in the transaction pool (also on a curve) out to n days (n=30 ?); the transaction weight serving as the likelihood of a transaction being included in the current block, and then use a target block size.


Protocol enforcement to prevent high or low blocksize cheating to be handled by having the protocol determine the target size for the current block using; current transaction pool size x ( 1 / (144 x n days ) ) = transactions to be included in the current block.

The curves used for the weight of transactions would have to be appropriate.

## Pros:


* Maximizes transaction reliability.
* Maximizes possibility for consumer and business uptake.
* Maximizes total fees paid per block without reducing reliability; because of reliability, confidence and uptake are greater; therefore, more transactions and more transactions total at priority fees.
* Market determines fee paid for transaction priority.

* Fee recommendations work all the way out to 30 days or greater.

* Provides additional block entropy and greater security since there is less probability of predicting the next block.

## Cons:


* ?
* Must be first be programmed.
* Anything else?

## Solution operation:


As I have said, my simplistic view of the operation. If I have this wrong, please correct it back to the list.


1. The protocol determines the target block size.

2. Assign each transaction in the pool a transaction weight based on fee and time waiting in the transaction pool.

3. Begin selecting transactions to include in the current block using transaction weight as the likelihood of inclusion until target block size is met.

4. Solve block.

Regards,

Damian Williamson



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------C5DAE4AB670F179367B42B7E--